在发送那份 HAR 文件之前，先读一读它里面有什么
“您能发一份 HAR 文件给我们吗？”是一个合理的要求——也是日常支持工作中最不经意的危险文件交接之一。HAR 文件是浏览器会话的完整录制：每一个请求和响应，带有使它们工作的 Cookie、授权标头、令牌和表单内容。它正是支持工程师重现你的问题所需要的，也正是攻击者重放你的会话所想要的。本文解释 HAR 文件是什么、如何在 Chrome、Edge 或 Firefox 中抓取一份、它会泄露什么，以及如何在它去任何地方之前检查并脱敏它。
HAR 文件是什么
HAR——HTTP 存档——是一种记录 HTTP 流量的 JSON 格式，由 HAR 1.2 规范标准化，被每个主流浏览器的开发者工具以及 mitmproxy 等调试代理导出。该文件含有一个带 entries 数组的 log 对象：每个请求一条记录，每条都带有方法与完整 URL、请求与响应标头、双向的 Cookie、拆解为参数的查询字符串、任何 POST 正文、响应的状态、大小和内容类型，以及按阶段细分的用时——DNS、连接、TLS、发送、等待、接收。
换句话说，它不是问题的截图；它就是问题本身，可以重放。任何处理 HTTP 流量的工具都使用这一格式——浏览器工具、性能分析器、支持工程师，以及越来越多的智能体：AI 智能体能逆向工程你的应用吗？ 中介绍的 REA 技术栈原生读取 HAR 抓取，因为对许多应用来说，API 流量比代码更能说明问题。正是这种有用性，让该文件在值得发送之前先值得阅读。
为什么支持团队和厂商索要它
因为它终结争论。“页面很慢”变成了带命名请求和用时的瀑布图。“API 失败了”变成了那条返回 500 的确切请求，带有确切的负载和确切的标头。“在我的机器上是好的”不再重要，因为录制来自你的机器、你的网络、你的账户，就在它出问题的那一刻。一位好的支持工程师用一份诚实的 HAR 文件能做到的，比一周的截图和回忆还多。
这也是为什么这个要求如此常被不假思索地转发。工单说“附上一份 HAR”，用户三十秒就导出一份，而这份文件——在他登录着、做着真实工作时录制的——开始旅行：进入工单系统、邮件线程，有时是公开论坛或共享驱动器，在每一跳积累副本。这条链上没有谁称得上粗心；只是这种格式隐藏了它包含的内容。一个 .har 文件看起来像惰性的诊断数据。它其实更接近一串钥匙。
如何在 Chrome、Edge 或 Firefox 中抓取一份
在 Chrome 或 Edge 中：打开页面，按 F12 打开开发者工具，进入网络面板（Chrome DevTools 网络参考记录了每个控件）。确保红色录制按钮已开启，如果问题跨越页面导航则勾选保留日志。从头到尾复现一次问题。然后在列表中右键任何请求，选择将所有内容另存为 HAR（含内容）（Edge 的说法是保存网络日志）。在 Firefox 中流程形状相同：开发者工具 → 网络，复现，右键 → 全部另存为 HAR。
两个抓取习惯比任何设置都重要。第一，录制能显示问题的最短会话：多浏览的每一分钟都是文件里多余的流量——和多余的秘密，包括其他标签页和后台请求当时在做的事情。第二，如果可以，在一个全新的浏览器配置文件或隐私窗口中复现问题，只登录出问题的那一个服务。来自干净配置文件的抓取只包含那一个会话，别无其他：没有银行标签页，没有网页邮箱，没有其他应用的令牌混在其中。
它会泄露什么
首先是你的会话。Cookie 和 Set-Cookie 标头以及 Cookie 列表携带着你的会话标识符，而大多数会话 Cookie 以最直白的意义就是持有者凭据：出示它的人在它过期或被撤销之前都会被当作你。Authorization 标头还加上持有者令牌，有时还有 Basic 凭据。这种格式不会把这些标记为特殊内容；它们只是标头，被忠实地记录下来。
然后是没人会当作标头的东西。令牌一直在 URL 里搭车——API 密钥、密码重置和邮箱验证链接、签名下载 URL、OAuth 回调——而 HAR 记录完整 URL，还把查询字符串拆出来方便阅读。POST 正文携带着表单携带的一切：你在抓取期间登录时用的密码、资料编辑、消息、个人数据。响应正文能带回同一类数据。一次真实会话的 HAR 文件实际上是你账户的部分实录——这就是为什么在线路上读取网络流量的工具如 PCAP Analyzer、以及在浏览器中读取它的工具如本页，都被造成明明白白地展示凭据，好让你看清自己拿着什么。
在发送之前检查并脱敏它
所以：在任何其他人之前打开这个文件。这正是本站 HAR File Analyzer 的用途——把 .har 拖入页面，它在本地、你的设备上解析，永不上传，敏感值默认打码：Authorization、Cookie 和 Set-Cookie 标头、每个 Cookie 值，以及任何名称像令牌、密钥、秘密、会话或密码的标头、查询参数、表单字段或 JSON 键。浏览摘要和最慢、最大的请求；检查出现了哪些主机——一份抓取有时含有你根本没在看的网站的流量——并且只在你自己的屏幕上使用“显示值”开关，如果你需要确认里面到底有什么的话。
然后下载脱敏版 .har，改为发送那一份。脱敏保留支持工程师需要的结构——同样的条目、标头、作为形态的 URL、状态和用时——并将凭据值替换为字面文本 REDACTED，在标头、Cookie、查询字符串、表单数据和 JSON 正文中一视同仁。一个限制印在工具上、这里再重复一遍：既不是 JSON 也不是普通表单数据的 POST 正文无法被安全解析，因此会原样保留——如果你的抓取含有这样的正文，在文件出行之前自己读一读它。打码的 CSV 摘要出于同样的原因存在：当工程师要求“只要请求的列表”时，它就是你要附加的文件。
脱敏做不到什么
脱敏移除了钥匙；它没有移除地图。脱敏后的 HAR 仍然显示你的主机和端点、你的参数名、响应的形态和大小、调用的顺序和用时——一张你的应用 API 的工作草图，这本身可能就是你不发布的信息。它也无法召回副本：一旦原始文件进入了工单系统或收件箱，脱敏你的副本并不能改变他们的副本。通过厂商给你的私密渠道分享脱敏文件——工单本身，而不是公开帖子或公开文件链接——并在工单中请求在案件关闭时删除该文件。有信誉的支持机构通常都会这样做；开口问一句不花什么。
而如果一份原始的、未脱敏的 HAR 已经流出——发到了错误的地址、附在了公开问题上、留在了共享文件夹里——就把该会话当作已暴露，因为它确实暴露了：退出该服务（这通常会使会话在服务器端失效），重新登录，并轮换其中出现过的任何 API 密钥。这与任何泄露的凭据适用同一规则，也是本站其他文件工具上的小字完全相同的原因——Binary File Inspector 在本地读取可执行文件，与本页在本地读取抓取出于同一原因：最需要检查的文件，恰恰是不应该上传去检查的文件。