LightProxy是 IFE 团队开发的一款基于 Electron 和 whistle 的开源桌面代理软'LightProxy(阿里抓包工具)，抓包，包括无线场景抓包按规则转发资源LightProxy依赖于后端日常接口进行调试的前端对这点应该深有体会，自己的问题还没解决，环境就时常带来新的问题。有些场景下的修改一次简单的修改就要经过长时间的等待，例如依赖上游修改接口的返回内容，需要修改后端的页面结构然后重新部署，需要走一遍完整的发布流程来测试某个修改在真实的线上页面会产生的影响等等。这种情况也往往导致 Bug 非常难以被定位，最后逼着开发者退化到在线上环境低效的进行 debug。这种非确定性不但提高了开发者心智负担，而且也会导致 Bug 难以定位。欢迎来合众软件园下载体验。
LightProxy软件特点
1.按规则转发资源
2.好的开发环境首先应该是稳定可用的，不应该在开发测试的过程中频繁挂掉或者频繁发生改变。
3.修改代码能够在尽可能短的时间内得到验证也是一个基本诉求，这也是为什么大部分前端构建都会关注 Hot reload 和更高级的 HMR 。
4.修改请求和响应内容，例如在页面中插入 script ，修改返回头等
LightProxy软件功能
1.这种情况也往往导致 Bug 非常难以被定位，最后逼着开发者退化到在线上环境低效的进行 debug。
2.有些情况下我们利用 hosts 切换工具来进行联调，但在切完 hosts 后却又不得不来回确认自己的切换是否生效，清楚 Chrome 的 DNS Cache，清楚 Socket 之类的。
3.开发者对于当前的环境应该是有确切认知的，而不是一直不停的怀疑自己的配置到底有没有生效，命中的是不是又是缓存等等。
4.很多项目的线上环境极为复杂，为了解决日常开发中的问题，也会有一个线下的 DEMO 页面，最后开发完再搬到线上。
5.和线上的一致性
LightProxy软件特色
1.有些场景下的修改一次简单的修改就要经过长时间的等待，例如依赖上游修改接口的返回内容，需要修改后端的页面结构然后重新部署，需要走一遍完整的发布流程来测试某个修改在真实的线上页面会产生的影响等等。
2.这种方式相对来说较为稳定且能快速验证，但比较凸显的问题在于和线上并不一致。开发中会存在很多 ifelse 的逻辑，例如最常见的：
3.抓包，包括无线场景抓包
4.mock 接口，页面等
5.开发者对于当前的环境应该是有确切认知的，而不是一直不停的怀疑自己的配置到底有没有生效，命中的是不是又是缓存等等。
6.这种非确定性不但提高了开发者心智负担，而且也会导致 Bug 难以定位。
7.依赖于后端日常接口进行调试的前端对这点应该深有体会，自己的问题还没解决，环境就时常带来新的问题。
8.const API_BASE = utils。 isDaily ? 'http://localhost:70,': 'https://xxxx/'
LightProxy更新日志
已知bug修复与体验优化
优化系统性能，体验更顺畅
其他问题修复和体验优化
