一条抓到的请求想交给同事复现，最省事的做法是丢一段能直接跑的代码——不用解释环境、不用描述参数，粘贴回车就行。右键把请求生成出来，长这样：
curl -X POST 'https://api.example.com/v2/orders' \
-H 'Content-Type: application/json' \
-H 'X-Sign: 3f8a...' \
-H 'X-Timestamp: 1757...' \
-d '{"sku":"A1024","count":2}'
这段不是手写的，是从抓包记录里直接导出的：方法、URL、全部请求头、请求体一个不少，粘进终端就能跑。注意那几个自定义头——签名、时间戳这类字段也在里面，导出时请求什么样，代码里就是什么样。
把抓包变成产物的路其实有三条：单条请求生成代码（五种语言）、一段会话导出接口文档（OpenAPI）、整段流量导出交换文件（HAR）。下面把三条路的入口、产物和适用场景过一遍。
五种语言，什么场景用哪个
在 TraceEagle 里，入口就在抓包列表：右键任意一条请求「生成代码…」。也可以在请求构造器里把一个请求调通之后再点生成，两条路出来的是同一种产物——调接口调到一半，把调顺的请求直接生成代码贴进工程，比照着抓包手写一遍 HTTP 客户端省事。
五种形式各有落点：
| 生成的语言 | 典型场景 |
|---|---|
| cURL | 贴进终端验证，或丢给同事/群里直接复现 |
| Python | 改造成自动化脚本，接批量任务 |
| JavaScript | Node 服务或前端调试环境里直接跑 |
| Go | 落到后端服务或工具类工程里 |
| OkHttp | 进 Android / Java 工程，顺着现有代码写 |
切换语言是即时重新生成，选好点复制，粘到哪都能用。这里有个容易被忽略的差别：生成的请求头保持原顺序、允许重复——有些抓包工具导出代码时会顺手把请求头重排、去重，遇到服务端校验头顺序或重复头的接口，跑出来的结果和真实请求对不上，排查半天又绕回原点。原样保留省掉的就是这类"代码明明生成了却复现不了"的坑。
验证也简单：把生成的 cURL 贴进终端，返回的响应和抓到时的一致，就说明方法、头、体都完整带上了。
一段会话怎么变成接口文档
第二个场景不一样：不是复现某一条，是把手头这段接口流量整理成一份能交付的文档。
用法是从会话直接导出：TraceEagle 会先把当前会话里的接口识别出来，列成一张清单——每个接口的方法、路径、出现次数、见过的状态码都标出来。比如把一次登录流程抓下来，清单里能直接看到 login、profile、orders 这几个接口各自出现几次、哪些请求见过 500。勾选你要导的（不勾的不会进文档，噪声流量在这一步滤掉），右侧实时预览生成的文档，确认没问题就复制或下载——预览跟着勾选实时变，不会导出一份不可控的东西再回头删。
归并是自动做的：带具体 ID 的路径会被模板化，/users/123 和 /users/456 合并成 /users/{id} 一条；请求和响应的 JSON 结构合并推断，响应按状态码归类，路径里的变量整理成参数。产出是标准的 OpenAPI 3.0，导进任何支持 OpenAPI 的接口工具都能继续用。
这套流程适合的场景挺集中：对接第三方接口时先抓一轮真实调用，直接出文档底稿，比翻着文档猜字段快；给历史项目补接口文档；或者给测试同事造用例时提供一份准确的结构。一个小提醒：如果同个接口被拆成好几条散在清单里，确认它们的方法和路径结构是一致的，归并没有遗漏。
导出 HAR：交给下一个环节
第三条路是整段会话一键导出标准 HAR 1.2 文件——交付、归档，或者转给别的工具接着分析。这一条和之前写过的"别人发来的抓包文件怎么导进来"正好是反方向：同一套交换格式，导入导出打通两头，你导出的 HAR 对方能直接用，对方抓的 pcap 拉进来也能继续解码、对比、再导出。
三个产物之间还有一条顺手的链路：导出的 HAR 给对方，对方导进自己的工具看；或者抓完一轮真实调用，直接生成 OpenAPI 底稿交给后端，文档和实际流量对得上，省掉来回确认字段的回合。归档场景也用得上：把关键版本的 HAR 存下来，日后"这个字段是什么时候改的"这类问题，翻当年的抓包文件就能对上，比翻聊天记录靠谱。
和手头的工具怎么配合
生成出来的代码不是为了替换谁：cURL 是通用货币，Postman 的导入框直接粘就能用，请求头顺序和重复项都保留；Python 产物接进现有的脚本仓库；OkHttp 贴回 Android 工程。接口文档同理，OpenAPI 3.0 是各家接口工具都认的格式，往 Apifox、Postman、Swagger 系工具里一导就能接着协作，接口用例、Mock 数据这些下游工作都能基于它展开。TraceEagle 在这里的角色是"上游"——把真实流量翻译成这些工具能吃的输入，后面的活还是各工具擅长的事。
顺带一提，这几种产物第一次用的时候，建议从一个具体需求倒着试：要同事复现一个报错，先试生成代码；要交付接口结构，先试导出 OpenAPI——每样跑通一次，之后就知道什么场合该出什么产物了。
从抓到产物的顺序也简单：定位要复现的请求 → 生成代码挑语言 → 一段流量抓完走 OpenAPI 清单 → 交付归档走 HAR。搭好这条链之后，调试时抓到的流量不再是"用一次就扔"的临时数据——需要复现时就地出代码，需要交付时直接出文档，价值比单纯"看过"高得多。
