在调试网络问题时有一个明显的分界点只查看请求和响应主动修改请求和响应观察程序行为变化当调试目标落在第二种情况抓包工具是否支持请求 / 响应拦截器就成了决定效率的关键因素。确认拦截位置是在发送前还是返回后在动手写拦截逻辑之前我会先确认一个我要干预的是请求阶段还是响应阶段。举两个常见的调试目标请求发出前替换 Header、参数或 URL响应返回后修改字段、状态码或数据结构这一步会直接决定拦截器是否需要同时处理 request 和 response。代理型工具中的拦截能力在 Charles、Fiddler 这类代理工具中拦截通常以规则或断点形式存在。以代理断点为例设置 URL 匹配规则请求命中后暂停手动修改请求内容再继续发送这种方式适合临时验证接口行为但当需要批量、可复现的修改逻辑时手动断点的效率会迅速下降。脚本化拦截的必要性当调试需求变成每次请求都要自动改 Header特定接口返回值需要统一替换多个字段需要条件判断后再修改就需要使用脚本型拦截器。这类拦截器有几个明确特征请求与响应自动进入拦截逻辑修改过程可重复行为可通过日志验证在抓包大师中启用请求 / 响应拦截器在需要对 iOS App 网络数据做深度调试时我会使用抓包大师Sniff Master的拦截器功能。打开拦截器日志界面进入代理抓包界面双击右侧插件形状的拦截器图标打开拦截器日志窗口在这个界面中可以直接看到拦截功能是否启用当前拦截日志是否产生日志是否出现是判断拦截是否生效的直接依据。进入拦截器编辑器理解代码结构在拦截器日志界面中点击「编辑拦截器」会进入代码编辑窗口。拦截器使用 JavaScript 编写整体结构固定由三个函数组成function handleRequest(request) { return request } function handleResponse(response) { return response } function filterUrl() { return [] }这段代码本身不会拦截任何请求它的作用是提供一个完整但空行为的框架。拦截范围由 filterUrl 决定filterUrl()返回的是一个 URL 规则数组。例如function filterUrl() { return [https://api.example.com/*] }只有命中该规则的请求才会进入handleRequest和handleResponse。如果这里返回空数组拦截器不会对任何请求生效。在请求阶段修改数据handleRequest(request)接收到的是即将发送给服务器的数据。request 对象中可直接访问request.URLrequest.Headerrequest.Bodyrequest.IsBase64Body例如替换请求 Header 中的某个字段function handleRequest(request) { request.Header[token] debug-token return request }修改完成后返回 request对服务器而言这就是最终收到的请求。在响应阶段修改返回结果handleResponse(response)接收的是服务器返回的数据。response 中除了 URL、Header、Body还包含response.StatusCode例如修改响应内容以验证客户端逻辑function handleResponse(response) { response.Body {code:0,data:mock} return response }客户端接收到的就是被替换后的响应内容。拦截器是否生效用日志验证在调试过程中我会在拦截函数中加入日志输出console.log(拦截请求 request.URL);如果日志窗口中出现对应输出说明URL 匹配成功拦截逻辑被执行修改行为真实生效这是比“界面有没有变化”更可靠的判断方式。多工具协同的使用方式在实际工程中拦截器很少单独使用用 Wireshark 判断是否建立连接用代理工具确认请求路径用 抓包大师Sniff Master拦截并修改数据每个工具解决的都是不同层级的问题拦截器负责的是数据层面的验证和控制参考链接https://www.sniffmaster.net/tutorial/zh/6/6.html