我第一次认真用抓包工具的拦截器功能，并不是想篡改接口，而是想确认一件事：
这个请求，客户端到底有没有按我理解的方式处理返回结果？
当日志和代码都无法完全解释行为时，拦截器反而成了最快的验证手段。
拦截器在整个抓包流程中的位置
在 iOS / Web 调试里，我一般会把工具分成几层：
- 代理抓包：看请求是否发出、参数是否正确
- 拦截器：在不改代码的情况下验证客户端逻辑
- 日志和断点：最终定位问题
拦截器并不是每次都用，但一旦用上，往往能快速缩小问题范围。
进入抓包大师的拦截器入口
在使用拦截器之前，需要先处在代理抓包模式下。
在抓包大师的代理抓包界面右侧，有一个类似插头形状的图标。
双击这个图标，会打开拦截器日志界面。
这个界面主要用来做三件事：
- 打开或关闭拦截器
- 查看拦截过程中输出的日志
- 进入拦截器代码编辑界面
打开拦截器编辑界面
在拦截器日志界面中，点击“编辑拦截器”，就可以进入代码编辑界面。
拦截器里面有一段默认的代码，是演示拦截器的整体框架的例子，需要根据自己的需要进行修改。
有一个非常重要的约束：
- 函数名不能改
- 函数参数不能改
- 只能修改函数内部逻辑
拦截器的最小可运行结构
拦截器至少包含下面这个代码，这个是一个空的拦截器，什么都不拦截，什么都不做。
1function handleRequest(request) {
2 return request
3}
4
5function handleResponse(response) {
6 return response
7}
8
9function filterUrl() {
10 return []
11}
如果缺少其中任何一个，拦截器都无法正常工作。
filterUrl 决定了“拦谁”
在实际使用中，我会优先从 filterUrl 下手。
这里返回的是一个 URL 列表，支持通配符。
只有命中这些地址的请求，才会进入 handleRequest 和 handleResponse。
例如，只拦截 Google 的请求：
1function filterUrl() {
2 return ["https://www.google.com/*"]
3}
如果这里没写对，后面的逻辑写得再复杂，也不会生效。
在 handleRequest 里验证“请求阶段”的判断
handleRequest 拿到的是即将发往服务器的请求。
我常用它来做几件事：
- 打印请求是否真的发出
- 临时修改请求参数，验证客户端分支
- 重定向请求地址
例如，只打印请求 URL：
1function handleRequest(request) {
2 console.log("准备发送请求：" + request.URL);
3 return request
4}
如果日志出现了，但服务端行为没变，说明请求确实发出了。
request 对象里真正常用的字段
在实际调试中，我最常用的是这几个属性：
URL：可以直接修改来做重定向Header：对象形式，适合加或删头Body：请求体内容IsBase64Body：判断是否是二进制数据
一个容易踩的坑是：
修改 Body 时，必须保证 IsBase64Body 的状态是匹配的。
handleResponse 更适合验证“客户端反应”
handleResponse 拿到的是服务器返回、即将交给客户端的数据。
这里特别适合做验证型修改，比如：
- 改一个字段，看 UI 是否变化
- 模拟异常返回
- 强制返回某种状态码
1function handleResponse(response) {
2 console.log("收到响应：" + response.URL);
3 return response
4}
很多时候，不用真的改数据，只打印日志，就已经能确认执行路径。
response 比 request 多了一个关键字段
response 对象比 request 多了一个：
StatusCode：HTTP 状态码
这在验证错误处理逻辑时非常有用。
拦截器的开关
在拦截器日志界面里，有一个明显的拦截开关。
我习惯在以下时刻关闭拦截器：
- 已经验证完假设
- 需要抓“真实请求”
- 不希望影响后续分析
否则很容易忘记拦截器还在生效，导致误判。
拦截器不是用来“长期修改”的
在我的使用经验里，拦截器更像一个临时实验工具。
它最适合的场景是：
- 验证猜测
- 复现异常
- 辅助定位
一旦结论明确，就应该回到代码层解决问题。
多工具组合下，拦截器的真实价值
在完整流程中，我更倾向于这样用：
- 代理抓包：确认请求结构
- 拦截器：验证客户端行为
- 数据流或日志：补充证据
参考教程：https://www.sniffmaster.net/tutorial/zh/6/6.html