本文作者：牧毅，转自知乎，原文链接
背景
写代码是很舒服的一件事情，但是作为一个前端开发，通常还是会有很多的时间会去调试一些代码。
对于一些小型的项目，它们的环境很容易搭建，本地搭个环境跑起来，基本也就足够用了。然而，对于一些大型的项目，就没有那么方便了，基本别指望在本地能把整个项目跑起来。
这时候如果我们改了其中一个 js, 那么该怎么调试呢？
很容易能想到一个方法：我们要是把这个 js 的请求重定向到我们本地修改的那个就好了，这样我们就能直接在线上调试了，本地只要跑个构建脚本就行了。
没错！现在有不少工具可以来做这个事情：
- Chrome DevTools 就可以做这个事情;
- 有不少插件可以更方便地做这个事情，如： Resource Override 插件 和 ReRes 插件;
- Windows 下还可以用 Fiddler — 良心之作，笔者之前一直都用这个，这么好用居然还是免费的！
- MacOS 下不差钱的可以用 Charles.
最近呢，笔者换工作了，公司配的是 MBP, 这就尴尬了，没有 Fiddler 用了 o╥﹏╥)o
插一句，有木有想换 MBP 的童鞋，欢迎来投简历：阿里南京 2019 秋招季/社招，诚邀加入~
Chrome DevTools 还是功能有点弱。Charles 是用不惯的。Resource Overrides 这种扩展虽好，但是它是通过 30X 重定向来搞的，所以呢 HTTPS 的资源重定向到 HTTP 的时候结果会报错……
Whistle 的功能和原理
终于，今天的主角 Whistle 登场了~
Whistle 的定位就是一个 『跨平台web调试代理工具』，可以用来查看、修改HTTP、HTTPS、Websocket的请求、响应。
它的原理其实很简单，不是像 wireshark 一样直接在网卡上抓包，而是像 Fiddler 的代理模式 :
- Whistle 自己会启动一个代理服务器;
- 我们自己需要配置下浏览器的代理走它的代理服务器;
- 然后 Whistle 就在代理的同时把 HTTP/HTTPS 的报文都给顺道截获了，当然像 Resource Override 一样顺手改改报文也不在话下了。
有人问 HTTPS 不是加密了吗？怎么也能截获？
这个问题问得好，原则上来说，HTTPS 的密文在代理服务器上是不能解密的；但是，有一种方法叫『中间人攻击』，通过这种方式，Whistle 就能将 HTTPS 的密文解密掉。
当然，这里澄清下，这种方式虽然是叫『中间人攻击』，但是也是要我们配合下 Whistle 才能行得通。Whistle 本身并不是恶意软件。
安装 Whistle
有木有想要迫不及待地想来试用下 Whistle 了呢？别着急，先安装下。
Whistle 是用 node.js 开发的，所以包是在 npm 上，可以用 npm 来安装：
> npm install -g whistle
当然，国内的话，建议使用淘宝的镜像：
> npm install whistle -g --registry=https://registry.npm.taobao.org
安装完后，会有两个可执行文件：whistle 和简写 w2.
可以看看其基本命令：
> w2 help
Usage: w2 <command> [options]
Commands:
status Show the running status of whistle
use/add [filepath] Set rules from a specified js file .whistle.js by default)
run Start a front service
start Start a background service
stop Stop current background service
restart Restart current background service
help Display help information
Options:
...
启动 Whistle
启动命令如上面的 help 所展示的，有两个：
- w2 run 是前台运行;
- w2 start 是作为一个后台服务来运行。
比如说，我们先来前台运行吧：
这提示得相当详细了，我们就按照提示打开 http://127.0.0.1:8899/ 即可看到 Whistle 的操作界面。
不同于 Fiddler 和 Charles 这种原生的界面, Whistle 采用了 Web 页面的方式来做 UI, 这也是我喜欢它的原因之一，简洁，省了 UI 的开销。
配置 HTTPS
现在很多应用都 HTTPS 化了，如果要调试这些应用，免不了就要对 HTTPS 的资源进行处理。而在上面也提到了，Whistle 是利用『中间人攻击』的原理来抓 HTTPS 的报文的。所以呢，这里我们需要来信任下我们的中间人（Whistle）的根证书。
根证书在哪儿呢？在刚才打开的 http://127.0.0.1:8899/ 的页面顶部，有个 HTTPS 按钮，点一下，会出来弹出框。
弹出框如下图，点击 “Download RootCA” 即可下载。Whistle 还贴心地准备了一个二维码方便在手机上下载这个根证书。
然后，就是把这个证书设置成信任的就行了。
具体设置的方法，可以直接参考这个：安装跟证书
到这里安全意识强的童鞋脑子里忍不住有个问题：怎么可以就这么轻易地信任了这个根证书？
对于这个问题，其实主要在于两点：
- 这个根证书怎么来的？
- 谁能拿到这个根证书？
对于第一个问题，通过查看 Whistle 源代码，我们可以发现其实就是在 lib/https/ca.js 的 createRootCA) 函数中创建的。具体而言，是通过 node-forge 这个 HTTPS 的库创建的。
创建后根证书会默认存储到 ~/.WhistleAppData/.whistle/certs 目录下：
第二次启动 Whistle 的时候，根证书默认就取存储的根证书 — 当然，如果你觉得这个根证书不安全了（比如被泄露出去了），那你可以把这里的根证书删掉，Whistle 在启动的时候会自动再创建。
对于第二个问题，笔者目前没有发现 Whistle 有上传根证书的行为，但是，这个根证书默认的位置是固定的，所以所有有访问这个存储目录权限的用户/程序都可能拿到这个根证书。
安全提示：
建议启动 Whistle 时通过 -z 或 –certDir 参数来更换证书的存储目录，或者使用单独的账号来启动 Whistle ，并限制证书的存储目录的访问权限。
此外，建议定期更换证书 — 删掉这里的证书，然后重启 Whistle.
配置资源重载
打开 http://127.0.0.1:8899/#rules，首先来配置一条最简单的规则：
这代表把 https://example.com/ 的应答直接替换成 https://www.baidu.com/ 的。
点击【保存】来保存下这个配置，然后配置 Chrome （当然其他浏览器也一样） 的代理是 127.0.0.1:8899
接着，用 Chrome 打开 https://example.com/，O∩_∩)O哈哈，百度出现了~
同理，要替换 js 也是类似的操作。
比如一个常见的场景，线上 React 报错了 “Uncaught Error: Minified React error…”, 怎么办？这时我们可以把线上的这个 React 替换成 development 的同版本的 React:
https://xxx.com/js/react-v16.5.min.js https://unpkg.com/react@16.5.2/umd/react.development.js
这样，我们就能看到 React 具体报的啥错啦。
当然，Whistle 不光可以把 HTTPS 资源重载成另一个 HTTPS 资源，事实上 HTTP -> HTTPS, HTTPS -> HTTP 都是支持的。甚至本地文件也是支持的 — 使用 file:///path/to/your/file.js 即可。所有支持的替换方式可以参考下这里的协议列表:
更厉害的是，如果配置的规则两边都只是域名，比如
aaa.com bbb.com
那么 http://aaa.com 域名下的所有的请求都将替换成 http://bbb.com 的请求 — 有木有种感觉像是 nginx 的反向代理。
后记
Whistle 的功能真的好强大，用起来很方便，还有好些个功能笔者精力有限这里就不一一介绍了…… 敬请探索。