调接口的时候应该都遇过这种场景：同一个接口，测试环境返回正常，线上就是报错；或者同一个操作，用户那边偶发失败，你这边怎么复现都成功。想找出差别，把两次请求的报文并排摆在一起，一行一行扫——两三百行的 JSON 响应，肉眼扫完眼睛先花，还容易漏；就算扫完，改动藏在第 87 行的某个字段里，也未必记得住两边原本该是什么样。抓包工具里的对比功能，就是为这个场景准备的：把两条请求或响应并排一放，差异自动逐行列出来，不用自己扫，也不用记住哪边该是什么值——对照窗口里，两边本来就摆在一起。
原理上就一句话：差异是在对照里暴露的，不靠记忆也不靠肉眼。单看一条成功请求，看不出哪里不对；和失败的那条并排，多出来的头、改过的参数、不一致的 body，一眼就现形。传统做法在同一个会话里翻来翻去，TraceEagle 的请求对比允许跨会话、跨来源比——只要界面上见过这两条流量，就能拿来对比，这比"同一会话内肉眼比对"实用得多。
第一步：抓两份流量
对比的前提是有两份素材。场景不同，抓法一样：测试环境正常的那次抓一份，线上报错的那次抓一份——两次抓包可以隔着时间、隔着环境，各自存着就行。偶发失败的目标，抓到失败记录后别急着清列表，把同接口的历史成功记录也留着，后面对比要用。流量来源不限：代理抓包、网卡抓包抓到的都行，手机、模拟器上的记录同样能进对比，请求构造器里发出的请求也算——素材越全，后面对比越有的放矢。
第二步：标记并触发对比
操作就两步。在 TraceEagle 的流量列表里，对第一条记录右键，选「标记为对比 A」；再到另一条记录上右键，选「与 A 对比」。对比窗口立刻弹出，两条记录并排，顶部各带标签——方法、主机、状态码，一眼知道在比哪两条。两条记录不在同一个会话也没关系，这正是跨会话对比的用法：线上那次抓的包存在另一天，翻出来一样能比。对比范围覆盖整条报文：起始行（请求行或响应行）、全部请求头/响应头、请求体/响应体，一处不漏。
第三步：读对比结果
窗口顶部的开关可以切"请求"或"响应"，两侧内容先自动美化再逐行比——JSON、XML、表单先格式化，真正变了的字段才露出来，换行、缩进这类格式噪声不会干扰判断。对比响应体时这个美化尤其有用：两段结构相同但缩进不同的 JSON，不格式化时整屏都是红的，格式化后差异只剩真正不同的那几行。差异用颜色标：新增、删除、改动分别高亮，A 侧红、B 侧绿，改动行两边并排对照，每行带行号方便定位。右上角有差异计数：新增几行、删除几行、改动几行，规模大小心里先有数。两边完全一致时界面会直接提示「一致」，不用自己逐行确认；某一侧没内容或还没解密，也会直说，不会让你对着空白干等。
提醒：比对的前提是两边都解出了明文——某侧还是密文时对比结果不可信，先把流量解出来再比。证书绑定的目标如果解不开，换应用层抓包把明文拿到手，再回到对比。
实际排查里的几个典型用法：成功 vs 失败，锁定偶发失败的差异字段，看是哪个头、哪个参数、哪段 body 不一样；改动前后各抓一次，验证服务端改动有没有生效、有没有误伤别的字段；手造的带签名请求和真实请求对比，核对签名算得对不对——构造器里调通一个请求后，和历史真实请求一比，签名参数、时间戳、头顺序哪里不一致立刻见分晓，不用对着算法逐行推。
请求对比的价值是两三百行的报文不用逐行扫，差异自动列出来——线上测试两样的接口，从"扫两小时"变成"看三行"。
顺带一提，对比还能当回归工具用：发版前后把同一接口的响应各抓一份存着，下个版本回归时直接对比，服务端行为变了哪些一目了然——抓包记录攒着不占地方，用的时候就是现成的对照样本。排查"环境不一致"是它最常用的场景，但用得多了你会发现，凡是"两次不一样"的疑问，它都能给答案：线上和测试、改动前后、真实和手造、成功和失败——先把两份流量抓到，剩下的交给并排窗口。
