本文作者：牧毅，轉自知乎，原文鏈接

背景

寫代碼是很舒服的一件事情，但是作為一個前端開發，通常還是會有很多的時間會去調試一些代碼。

對于一些小型的項目，它們的環境很容易搭建，本地搭個環境跑起來，基本也就足夠用了。然而，對于一些大型的項目，就沒有那么方便了，基本別指望在本地能把整個項目跑起來。

這時候如果我們改了其中一個 js, 那么該怎么調試呢？

很容易能想到一個方法：我們要是把這個 js 的請求重定向到我們本地修改的那個就好了，這樣我們就能直接在線上調試了，本地只要跑個構建腳本就行了。

沒錯！現在有不少工具可以來做這個事情：

1. Chrome DevTools 就可以做這個事情;
2. 有不少插件可以更方便地做這個事情，如： Resource Override 插件 和 ReRes 插件;
3. Windows 下還可以用 Fiddler -- 良心之作，筆者之前一直都用這個，這么好用居然還是免費的！
4. 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 的代理模式 :

1. Whistle 自己會啟動一個代理服務器;
2. 我們自己需要配置下瀏覽器的代理走它的代理服務器;
3. 然后 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 還貼心地準備了一個二維碼方便在手機上下載這個根證書。

然后，就是把這個證書設置成信任的就行了。

具體設置的方法，可以直接參考這個：安裝跟證書

到這里安全意識強的童鞋腦子里忍不住有個問題：怎么可以就這么輕易地信任了這個根證書？

對于這個問題，其實主要在于兩點：

1. 這個根證書怎么來的？
2. 誰能拿到這個根證書？

對于第一個問題，通過查看 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 的功能真的好強大，用起來很方便，還有好些個功能筆者精力有限這里就不一一介紹了…… 敬請探索。

總結

以上是生活随笔為你收集整理的前端调试利器 Whistle安装使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。