需求：更改前端的某個ajax網絡請求的負載(payload)並測試保證功能正常
假如此次的修改改動較大，或者原本的構建 payload 的邏輯比較複雜，我們可能需要反覆地修改和測試。
如果這個 ajax request發送後對後端資源造成的影響很小的話 —— 比如 創建一本書籍記錄，更新一篇文章的標籤，其實我們也不需要考慮太多，直接一邊修改一邊測試就可以了。
因爲這些不痛不癢的資源即使在測試過程中被創建或者修改了，測試結束後也可以輕鬆地刪掉，不會造成大影響。
但是，假如這個ajax request 在後端會觸發比較重的操作 —— 比如創建某個服務集羣，重新部署某個服務節點，我們就得謹慎考慮了。
這類比較重的操作一方面會花費比較長的時間，另一方面會真實地修改或消耗線上資源，隨意且頻繁地測試並不合適。
這種情形要求我們除了最後的一兩次驗收，其餘的測試都不該真的發請求到後端.
那應該怎麼做呢？
方案一：修改並註釋請求發送的代碼
假如以下是原本的代碼
getFormData = （）=> {
// construct the payload from form data
}
onSubmit = () => {
const payload = getFormData();
httpClient.postRequest(payload);
};測試時期的代碼
getFormData = （）=> {
// construct the payload from form data - updated some code and logic
}
onSubmit = () => {
const payload = getFormData();
console.log(payload);
//httpClient.postRequest(payload);
};我們把 httpClient.postRequest(payload); 這行代碼註釋掉，並增加 console.log(payload); 把payload 打到 console 裏查看。確認修改後的payload完全正確後（這個過程可能會反覆多次），再去掉註釋代碼。
這種方案的確避免了真正的網絡請求的發起，代碼邏輯也清晰簡單。
但這種方案的缺點也很明顯，我們修改了原本能工作的代碼——即註釋了httpClient.postRequest(payload); 在開發結束後，假如我們忘記了去掉這行註釋，把代碼推到線上，就會導致這個表單功能失效。
方案二：在表單提交的代碼設置斷點
同樣用上面的代碼爲例
getFormData = （）=> {
// construct the payload from form data
}
onSubmit = () => {
const payload = getFormData();
httpClient.postRequest(payload); // set breakpoint here
};我們需要在 httpClient.postRequest(payload); 這行打斷點
具體怎麼做呢？
打開Chrome 開發者工具，然後看下圖（注意各個箭頭）
觸發網絡請求前，代碼會被斷點攔截，此時我們就能在右邊欄裏看到ajax request的payload了。
由於斷點阻斷了代碼的執行，這個ajax request不會發送到服務器。
假如發現payload不對，繼續修改代碼後，只需要刷新頁面就可以重置當前頁面的js代碼運行狀態（脫離斷點）。
這種方案解決了方案一的問題 —— 不修改任何原本能正常工作的代碼
但是這種方案的缺陷也很明顯：假如打斷點的js文件正是正在被修改的代碼文件，一旦增加或減少代碼行數，斷點的位置卻仍然打在原本的那行上（或最靠近的可執行代碼上）。
舉個例子：上面截圖的23行代碼現在是 httpClient.postRequest(payload) 但是這個文件的其他地方增加或減少了代碼，導致 httpClient.postRequest(payload) 現在在 27行，而斷點偏移到了 25 行上（因爲 23行不可執行）
爲了避免這種情況，我們可以在 httpClient.postRequest(payload); 前加 debugger —— 可以起到一樣的斷點效果 （前提是打開 Chrome 開發工具欄）且不會隨意偏移，代碼如下：
getFormData = （）=> {
// construct the payload from form data
}
onSubmit = () => {
const payload = getFormData();
debugger；
httpClient.postRequest(payload);
}但使用 debugger 會帶來類似方案一的缺點 —— 在開發完成後，記得清理 debugger 這行代碼。
另一個避免斷點偏移的方案是把斷點打到非修改的js文件上 ，但這種方案有前提條件——上述的 httpClient代碼 是在另一個js 文件內。
總之，方案二使用 Chrome 開發者工具打斷點 或者 加入 debbuger 仍然有侷限性，有些情況下不是非常方便。
方案三：巧用Chrome開發者工具使網頁離線
阻止請求發送到後端的最快辦法是什麼——拔網線斷網！
當然，有了chrome開發者工具幫助，我們不用拔網線也能使網頁離線，具體做法如下圖(注意箭頭）
點擊第三個箭頭所指可以看到 request 的 payload 和其他信息
雖然網頁離線了，但是ajax request的所有信息都能看到。
這種方案既不會像方案一那樣影響其他代碼，也不會像方案二那樣因爲js文件的修改產生影響。
現代前端框架如 React 或者 vue 都可以熱部署——修改完代碼，界面就會自動刷新，但其實熱部署的底層原理藉助了網絡請求，因此網頁離線會導致熱部署失敗。所以，一旦修改完代碼，記得重新打開網絡讓頁面刷新，測試之前再離線。
這就是方案三的缺點——得重複地打開或關閉網絡，操作略繁瑣。
前端小技巧之debug與測試網絡請求負載到此就介紹完了，三種方案各有利弊，你最喜歡哪個方案？
拓展：
本文其實只是拋磚引玉，Chrome 開發者工具是所有前端開發者日常開發的好幫手，推薦大家找時間認真閱讀官方文檔，學習更詳細的使用技巧
https://developers.google.com/web/tools/chrome-devtoolsdevelopers.google.com