对接一个没有文档的接口，流程大概是这样的：抓包看到一条请求，照着手抄 URL、一个个敲请求头、猜参数含义，再在 Postman 里拼一遍，跑起来发现签名不对、少带了个头，又回去对。接口一多，光整理这些就耗掉大半天。这篇讲的是把这步省掉——抓到的真实请求直接转成能跑的代码，一整段会话自动归并成一份 OpenAPI 接口文档，不用手抄也不用手写。前置条件很简单：装好老鹰抓包 TraceEagle，抓到请求、列表里有数据即可。

抓完之后，能直接产出三样东西

在动手前先把目标说清楚，三类产物对应三种交付场景：

• 代码：单条请求转成 cURL / Python / JavaScript / Go / OkHttp，复现到脚本或工程，或者一条 cURL 发给同事。
• OpenAPI 文档：一段会话自动识别出接口、归并成标准 OpenAPI 3.0，交付、给后端补文档、给测试造用例。
• HAR：整段抓包导出成通用交换格式，归档或转给别的工具；反过来，别人抓的 HAR / pcap 也能导进来接着看。

下面按操作顺序逐个过。

第一步：一条请求转成能跑的代码

在请求列表里选中想复现的那条， 右键 →「生成代码…」。弹出的面板顶部可以切换语言，共五种：cURL、Python、JavaScript、Go、OkHttp（Java / Kotlin）。切一次语言即时重新生成，点「复制」粘出去就行。如果你是在请求构造器里调通了一个请求，也能直接点「生成代码」，导出方式一样。

这里有个容易被忽略但实际很关键的点： 生成的代码保留了全部请求头，而且是原顺序、允许重复的。很多工具生成代码时会把请求头按字母重排、把重复的头去重——看着干净，复现时就出问题。为什么？一类后端的签名是把请求头按 发送顺序拼进去算 HMAC 的，顺序一变签名就对不上；还有些接口会故意发两个同名头，去重之后语义就变了。老鹰抓包这里默认原样保留，所以贴进终端跑出来的结果和真实请求一致，不用自己回去补头、调顺序。

验证也直接：把生成的 cURL 贴进终端能跑通、返回和抓到的一致，就说明请求头、请求体都完整带上了。

第二步：一段会话反推成 OpenAPI 文档

单条是代码，整段就是文档。抓完一段接口流量后，打开 导出接口文档（OpenAPI），它的逻辑是"先分析、再导出"：

1. 先从当前会话自动识别出接口，列成一张清单。清单里每个接口直接标着 方法、路径、出现次数、见过的状态码，接口全貌一眼看清。
2. 你 勾选要的接口——只导勾中的，会话里的噪声流量（埋点、静态资源、第三方 SDK 的请求）不选就不会进文档。
3. 工具自动做两件事： 归并路径，把带具体 ID 的 /users/123、 /users/456 模板化成 /users/{id}，同一接口的多次请求合并成一条； 推断结构，合并请求和响应的 JSON 结构、按状态码归类响应、把路径里的变量整理成参数。
4. 右侧实时预览产出的 OpenAPI 3.0 文档，确认后复制或下载。

拿到的是标准 OpenAPI 3.0，可以直接导进 Swagger UI、Apifox、Postman 这些认 OpenAPI 的工具接着用。这一步的价值在于：路径模板化和结构推断是从 真实流量里归并出来的，而不是靠人读代码猜字段——对接第三方、给一个年久失修的老系统补文档时，这份"从实际请求反推的文档"比一份早就和实现对不上的手写文档更贴近现状。

顺手完成 HAR 导出和导入外部会话

接口文档之外还有两个互通口子。 导出 HAR：整段抓包一键存成标准 HAR 1.2 文件，用于交付、归档或转给别的工具。 导入会话：手上有别人、线上、或其它工具抓的会话文件——HAR 1.2、 .pcap / .pcapng 以及常见抓包工具导出的格式——都能拉进来，导入后请求照常出现在列表里，可以用这里的解码、主机档案、请求对比接着分析，分析完一样能再导成代码或 OpenAPI。

一个实用组合，让同事用任意工具抓一段线上流量导出 HAR 发你，你导入后反推成 OpenAPI，等于不用自己复现环境就拿到了线上接口的真实文档。

几个实际问题

生成的代码跑出来和真实请求不一致？ 多半是中途手动改过请求头顺序或漏带了某个头。对原始请求重新「生成代码」即可，这里默认原样保留顺序和重复项，不用手动补。

OpenAPI 清单里混进了不相关的接口？ 会话里有噪声流量。在"先分析、再导出"的清单里只勾你要的接口，不选的不会导出。

同一个接口被拆成了好几条？ 路径里带了具体 ID 没被归并。归并会把 /users/123 这类模板化成 /users/{id}；如果还是分散，确认这几条的方法和路径结构确实一致。

想要的语言不在那五种里？ 目前是 cURL / Python / JavaScript / Go / OkHttp。先导出最接近的（一般是 cURL），再按需转写到你的语言。

想分析线上或同事抓的包？ 数据不在本机会话里，用「导入会话」把 HAR 1.2 / .pcap / .pcapng 拉进来，导入后照常查看、对比、再导出。

和 Postman、Charles 对比

同样是"抓包 + 整理接口"，几种常见做法各有侧重：

• Postman：接口调试和协作的主场，但它的 collection 多半要手动建、手动填，或者导入一份现成的 OpenAPI/HAR——它不负责从原始抓包流量里自动归并出接口结构。
• Charles / Fiddler：抓 HTTP(S) 很成熟，也能导出 HAR，但导出的是一条条原始请求，要变成模板化、结构化的 OpenAPI 文档还得另找工具或手工整理。
• Swagger / 手写 OpenAPI：最规范，前提是有人持续维护；对接别人的接口、或者文档早就和实现对不上时，这条路走不通。
• 老鹰抓包 TraceEagle：补的正是"真实流量 → 模板化接口文档 / 可运行代码"这一段——抓到就能直出，再配合它的导入会话，别人抓的包也能拿来反推文档。

落到用法上：日常调接口、团队共享用例，Postman 顺手；只要把抓到的流量变成能跑的代码或一份可以交付的接口文档，TraceEagle 这条"直出"路径省掉的就是中间手抄和复现的工夫。

对接无文档接口的问题，单条请求右键生成代码、请求头原样保留保证复现一致；整段会话先分析再勾选、自动归并路径和推断结构导出 OpenAPI 3.0；配合 HAR 导入导出和别的工具两头互通。抓到的流量能直接变成产物。