4. 断点与篡改：请求/响应断点设置、动态修改请求参数、模拟后端错误响应（500/403/超时）、重放攻击测试
断点与篡改，说白了就是让流量在客户端和服务端之间「停一下」，然后你动手脚。我刚开始用抓包工具时，觉得能看看请求响应已经很牛了。直到有一次线上出了个诡异的Bug，前端死活不弹错误提示，我抓了半天包才发现——问题不在请求发没发，而在后端返回了一个我完全没预料到的状态码。
从那以后，我就养成了一个习惯：不光要看，还要改，还要模拟各种极端情况。这一章，我就把断点、篡改、模拟错误和重放测试这几个硬核技能，一次性讲透。
核心能力：断点不是让你看数据的，是让你「介入」数据的。篡改不是让你搞破坏的，是让你验证系统健壮性的。
4.1 请求/响应断点设置
断点分两种：请求断点和响应断点。请求断点是在数据发出前拦截，响应断点是在数据回来前拦截。你想想看，这两种场景分别对应什么需求？
- 请求断点：你想修改发送的参数、Header、Cookie，或者干脆阻止这个请求发出去。
- 响应断点：你想修改后端返回的数据、状态码、响应头，看看前端怎么处理异常情况。
以我常用的工具为例，设置断点通常有两种方式：
- 全局断点：拦截所有请求/响应。适合调试初期，但流量大时会疯掉。
- 条件断点：只拦截匹配特定URL、参数或Header的请求。我强烈建议你用这种方式。
我的习惯：先设一个宽松的条件，比如只拦截某个域名下的所有请求。等定位到具体接口后，再缩小范围到精确的URL+方法。这样不会漏掉，也不会被刷屏。
设置断点后，工具会暂停在拦截点。这时候你可以：
- 查看完整的请求/响应数据
- 修改任意字段
- 选择「放行」、「丢弃」或「继续编辑」
4.2 动态修改请求参数
这是断点最常用的场景。我遇到过很多次，前端写死了某些参数，或者参数加密了，你想测一个边界值却改不了代码。这时候断点修改就是救命稻草。
常见的修改场景包括：
| 参数类型 | 修改示例 | 测试目的 |
|---|---|---|
| URL参数 | ?page=1 → ?page=-1 |
测试后端参数校验 |
| 请求体 | {"id": 100} → {"id": "abc"} |
测试类型转换异常 |
| Header | Authorization: Bearer xxx → 删除 |
测试鉴权缺失处理 |
| Cookie | session_id=valid → session_id=expired |
测试会话过期逻辑 |
操作步骤其实很简单：
- 在拦截到的请求上，找到你要修改的字段
- 直接编辑文本内容（有些工具支持可视化编辑）
- 点击「执行」或「放行」，让修改后的请求发出去
我曾经踩过的坑：有一次我修改了请求体里的JSON，但忘了检查JSON格式是否合法。结果放行后，后端直接返回了500，我排查了半天才发现是自己多打了一个逗号。所以，修改后务必看一眼格式对不对，尤其是JSON和XML。
4.3 模拟后端错误响应
前端开发最怕什么？怕后端不按文档返回。但你不能总指望后端配合你测试。这时候，断点篡改响应就派上用场了。
我一般会模拟这几种错误：
- 500 Internal Server Error：测试前端是否显示「服务器繁忙」之类的提示，而不是白屏或崩溃。
- 403 Forbidden：测试权限不足时的跳转或提示逻辑。
- 超时：模拟网络延迟或后端无响应，测试前端的超时重试机制。
具体怎么做？以模拟500为例：
- 在响应断点中拦截目标请求的响应
- 修改状态码：
200→500 - 修改响应体：可以保留原结构但改状态字段，或者直接返回一个空对象
- 放行，观察前端行为
注意：模拟超时稍微麻烦一点。有些工具支持「延迟响应」功能，你可以设置一个很大的延迟值（比如30秒），然后看前端在多少秒后触发超时回调。如果工具不支持，你可以直接丢弃请求，模拟「永远不返回」的场景。
我个人的经验是，模拟错误响应时，一定要同时修改状态码和响应体。只改状态码不改响应体，前端可能会因为解析失败而报另一个错误，干扰你的判断。
4.4 重放攻击测试
重放攻击，就是把之前抓到的请求原封不动（或稍加修改）再发一次。这听起来简单，但能测出很多安全问题。
常见的测试场景：
- 幂等性测试：同一个请求发两次，会不会创建两条重复的订单？
- Token复用测试：过期的Token还能不能成功请求？
- 防重放机制测试：系统有没有校验时间戳或Nonce（一次性随机数）？
操作流程：
- 抓取一个你感兴趣的请求（比如支付接口）
- 在工具的历史记录中找到它，选择「重放」
- 可以原样重放，也可以修改参数后再重放
- 观察服务端的响应和业务状态变化
我的建议：重放测试最好在测试环境做，别在生产环境乱来。我曾经见过有人在生产环境重放了下单接口，结果生成了几十个重复订单，运维差点没疯掉。
另外，重放攻击测试还有一个进阶玩法：并发重放。有些工具支持同时发送多个重放请求，用来测试系统的并发处理能力和锁机制。比如，同一个优惠券码，能不能被两个人同时使用？这种场景用并发重放一测便知。
这张图把整个流程串起来了。你从客户端发起请求，先经过请求断点（你可以改），再到服务端处理，然后响应回来经过响应断点（你又能改），最后回到客户端。说白了，你在两个关键节点上都有「动手脚」的机会。
总结一下：断点与篡改不是花架子，是检验系统健壮性的利器。你模拟的每一个错误，修改的每一个参数，都是在帮你的系统「排雷」。别等到线上出了事故才后悔——那时候你连抓包的机会都没有。