调一个接口，账户余额这个字段跟实际对不上。可能不是代码问题，你大概怀疑是后端返回的数据有问题，可这会儿后端同事也在查，谁都不确定啊。这时候最快的做法不是加日志、重新打包、等下一次请求，而是 在请求出去的那一刻把它停住，亲眼看一眼它到底带了什么、回来又是什么。

断点拦截干的就是这件事：让流量在发出前或者返回前停下来，等你改完再放行。几种典型的场合：

• 想验证"如果这个参数换成 X，接口会返回什么"——不用改代码，当场改
• 想看清楚登录请求里到底带了哪些字段——停住它，慢慢看
• 某个接口一调就报错，想让它返回一个正常的响应，看后面的流程还对不对
• 偶发问题复现不了，想在一次请求上多试几种改法

为什么要在半路停一下？

规则改写是"提前写好、之后自动执行"——你把条件写死，它按条件办。但这套东西有个前提： 你得事先知道要改什么。我自己的经验是，调试现场很多判断都是临时做出的：看到这个值才想起来换一个试试，发现少了那个头才补上一个。

断点补的就是这个缺口。它把决定权从"事先"挪到"当场"——流量停下来，你看清楚了，再决定改不改、怎么改。代价是慢：每条命中的流量都得有人处理一下。所以它适合"少量、精细、需要判断"的场合，不适合大批量。

自动化负责规模，断点负责现场判断，两者不是替代关系。

怎么拦下你想改的那条？

两种触发方式，TraceEagle 里都有，用哪种取决于你要拦的范围有多大。

全局拦截开关。 打开之后整个会话的流量都会被拦下来。范围太大？配一条 拦截过滤规则收窄——按域名、按方法、按阶段（请求还是响应）筛，只拦你关心的那部分。什么都不配的话就是全拦，适合临时看一眼所有请求长什么样。

规则触发。 更精准的做法是写一条规则，用 breakpoint://req|res|both 指定拦哪个阶段： req 只拦请求、 res 只拦响应、 both 两头都拦。规则本身的匹配条件可以用精确域名、通配子域、正则、端口这些，所以能精确到"只拦这个接口、而且只拦它的响应"。

两个选择的差别很实际：全局开关适合探索——你还不知道要拦谁，先都拦下来看看；规则触发适合你已经知道问题在哪、只想在那一条上停一下的时候。

有个坑要提前知道：全局拦截打开之后， 所有流量都会排队等你处理。如果在开着的状态下忘了放行，浏览器那边会一直转圈，看着像网络断了。这不是出了问题，是流量在队列里等着你呢。

停住之后能改哪些东西？

按阶段分，能改的东西不一样：

请求阶段：方法、URL、请求头、请求体。注意改 URL 的时候， 主机名会跟着变——想把一条请求转到另一个环境去，改这一处就够了。

响应阶段：状态码、响应头、响应体。常见的用法是把它临时改成成功码，看前端走不走正常分支；或者把响应体换成一份构造好的数据。

拦下来之后也可以不放，选 Abort 把这条请求或响应直接丢掉。客户端那边会收到一个网关错误。用它来验证"这个接口彻底失败的时候前端表现怎么样"，最直接。

在 TraceEagle 里，拦下来的每一条都会弹出一个编辑框，改完点放行就行——不需要写规则，也不需要写脚本。

一次命中好几条怎么办？

这种情况在大会话里很常见：开了全局拦截，页面一刷新，十几个请求同时停下来排队。

工具那边做了两件事让这件事不至于失控：

一是 排队处理。命中的流量按顺序排好，你可以逐条放行（Resume）、逐条丢弃（Abort），也可以一键全部放行。看着不急的就慢慢来，急着恢复的一次放过。

二是 超时自动放行。一条流量停在那里长时间没人处理，它会自动按原样放出去。这一条其实挺关键——它防住了"忘了处理导致整个会话卡死"这种低级失误。

即便如此，还是建议 尽量用规则触发而不是全局开关。全局开着的状态下，你一旦离开键盘，会话基本就变成半停摆的样子，别人用你这台机器会一头雾水。

什么时候不该用断点？

断点是"手动档"，它有几件事天生做不好：

大批量改。 要改几百条请求的头，用规则或者脚本，断点会让你点到手软。

需要计算的值。 时间戳、签名这类每次都要算的东西，断点只能手动填——填完这条，下一条又不对了。

还有一种情况是无人值守：脚本、压测这类跑起来没人盯着的流程，断点会把流量卡在半路。

所以这里的分工很清楚嘛： 固定的用规则，算出来的用脚本，需要当场判断的用断点。 在 TraceEagle 里，这三层是按顺序执行的——规则和脚本先自动处理完，断点排在后面，只处理你特意标记要停下的那部分流量。

断点拦截的用法其实不复杂：想清楚要拦请求还是响应，用全局开关还是规则，然后拦下来改、或者直接丢弃。真正要习惯的是节奏——它慢，但慢得有价值，因为慢下来的那几秒，你才看得清那条请求到底是怎么回事。

下次遇到"我怀疑这个参数不对、但没法确认"的时候，别急着加日志。先把它停下来抓包看一眼。