Fiddler代理本地文件来简化查错机制

通常软件不会简单的部署在一两个几乎相同的环境下，开发完直接上生产。通常都会经历开发环境（SDE）-->测试环境（SIT）-->用户体验测试环境（UAT）-->最后才是生产环境。通常随着环境不断接近生产环境，出现的问题和缺陷将越来越难排查和修复。那么前端工程师在面临一个UAT环境或者生产环境出现的问题时该如何调试程序呢？有两种方法：代理服务器替换文件和程序自适应环境。后者（简单介绍：指在各个环境部署不同的代码，程序通过一定方法自动判断如何加载不同的代码，从而达到代码可调）需要在应用建设初期就设计好部署结构，因此大部分情况下对并不适应于真实环境。本文主要介绍前者：代理服务器。

当一个前端应用通过开发环境、测试环境成功进入UAT环境后，此时突然出现一个bug，这个bug可能是因为UAT环境与之前环境配置不同而引起的，也可能是因为前后数据量差异引起，也极有可能是因为别的模块修改引入的，最后有可能是本身程序缺陷引起（毕竟通过了测试环境，因此这种情况可能性最低）。这样一个bug出现在开发环境对很多开发人员都不是一个好调的问题，更别说这个bug出现在了UAT环境甚至生产环境。这个时候我们把应用一开，断点一打，才发现无从下手：在UAT环境部署的前端代码往往是经过压缩后的代码，根本无法阅读；即使不是压缩后的代码，我们也不能像在生产环境一样对本地代码的任何修改马上就能体现到UAT环境上。此时就出现了代理服务器这种工具。Fiddler就是其中使用较多的一个。

探究代理服务器的原理的话其实也很简单：当我们的浏览器连接上一个代理服务器后，则该浏览器发出的所有请求都会经过这个代理服务器（浏览器会认为代理服务器就是目的服务器）。然后我们就可以在代理服务器当中进行一些过滤或者拦截，从而影响浏览器发出的请求或接收到的请求返回。对应到前文的场景中：我们可以将问题应用通过代理服务器访问，在代理服务器将相关代码文件（通常是js文件）的下载路径由原来的UAT服务器或生产服务器地址改为我们开发环境的地址或者直接改成我们电脑的本地地址，这样，相应文件就会从我们修改后的路径读取并加载，这样我们才能够调试相关问题。说的极端一点，如果把每个请求全部转发到本地，那么就相当于把UAT环境改成了本地环境。

下文具体描述如何通过Fiddler代理手机浏览器的请求：

流程步骤：

（1）手机连上Fiddler VPN

（2）手机清缓存

（3）Fiddler:Rules->Performance->DisableCaching

（4）将js文件拖至AutoResponder，配置相应替换规则（见后图）

（5）勾选Enable rules，Unmatched requests passthrough选项

（6）刷新手机即可连至本机环境

（7）背景色为青色就是被拦截的请求

部分流程图：

1.单个文件匹配：

 

2.被拦截请求有青色条背景色：

 

3.缓存文件会用灰色头像表示：

有了这样的工具和方法，相信大家就能简化一些复杂的问题场景了。

更多内容：http://blog.csdn.net/ohmygirl/article/details/17846199

 

熬夜不易，请作者喝杯酒！