HAR 文件怎么分析？失败请求、瀑布耗时、重复资源与安全脱敏指南

网页打开慢、接口偶发 500、图片重复下载或登录状态异常时，截图往往不够。HAR（HTTP Archive）会记录一次浏览器会话中的请求 URL、方法、状态码、请求头、响应头、体积和阶段耗时，适合把“感觉慢”变成可以排序和复核的请求清单。

可以使用 HAR 网络请求分析器 在浏览器本地读取 .har 文件，筛选失败、慢请求、大文件、重复 URL 和疑似敏感字段，查看请求详情，并导出脱敏副本。文件不会为了分析而上传服务器。

HAR 里通常记录什么

HAR 1.2 说明把数据组织在 log.entries 中。每条 entry 常见字段包括：

• startedDateTime：请求开始时间。
• time：总耗时，通常以毫秒计。
• request：方法、URL、Header、Cookie、查询参数和正文。
• response：状态码、Header、Cookie、正文元数据和内容。
• timings：blocked、dns、connect、ssl、send、wait、receive 等阶段。
• 浏览器扩展字段：_resourceType、_transferSize 等。

不同浏览器、版本和导出选项不一定填满所有字段。分析器只能按现有字段计算，不能把缺失的缓存、压缩体积或服务端内部耗时凭空补出来。

怎样正确导出可复现的 HAR

在浏览器 DevTools 的 Network 面板中，建议先清空旧请求，再根据问题决定是否启用 Preserve log 和 Disable cache。然后完整复现一次操作，等待页面稳定，最后导出 HAR。

排查性能时可以分别保存“正常”和“异常”样本；排查登录或支付时应使用测试账号和最小数据。不要为了方便把长时间浏览产生的全部请求一起发出，这既增加噪声，也提高泄露隐私的风险。

导出前记录这些上下文：

• 发生时间和时区。
• 浏览器版本、设备和网络环境。
• 是否禁用缓存、是否经过 VPN 或代理。
• 操作步骤、预期结果和实际结果。
• 对应的后端 request ID、trace ID 或日志时间段。

HAR 只描述浏览器侧现象，这些上下文能帮助服务端团队把请求与日志对上。

先看失败请求还是先看最慢请求

建议先按影响分类：

1. 状态 0、4xx、5xx 和取消请求。
2. 主文档、关键 API、CSS、JavaScript 等阻塞资源。
3. 超过阈值的慢请求。
4. 超过 1 MB 的大文件。
5. 同一方法与 URL 的重复记录。

状态 0 不一定是服务器返回错误，也可能是 CORS、证书、DNS、连接中断、扩展拦截或用户取消。应结合 Console、浏览器错误文案和服务端是否收到请求判断。

4xx 通常与请求参数、权限和资源状态有关，5xx 则表示网关或服务端处理失败。只看状态码不够，还要检查响应 Content-Type 和正文：有些代理会返回 HTML 错误页，前端却按 JSON 解析，最后表现成另一个 JavaScript 异常。

瀑布时间怎样读

瀑布图把请求相对页面起点的位置和持续时间画在同一时间轴上。它适合观察：

• 多个关键请求是否串行等待。
• 大量资源是否同时争用连接和带宽。
• 某个 API 的 wait 时间是否异常长。
• 大文件的 receive 阶段是否占主要时间。
• 请求是否直到主线程工作后才开始。

timings 字段并不等于完整性能诊断。DNS、connect 和 SSL 可能因为连接复用而是 0 或 -1；wait 接近服务端响应等待，但也包含网络往返；blocked 可能与队列、连接池或浏览器调度有关。

页面跨度是最早请求开始到最晚请求结束的区间，不等于 Largest Contentful Paint，也不代表用户已经可以交互。Core Web Vitals 应通过 Performance、Lighthouse 或真实用户监控检查。

传输体积为什么会对不上

HAR 可能同时提供 _transferSize、headersSize、bodySize 和 content.size。压缩、缓存、HTTP/2、Service Worker 和浏览器实现都会让这些值含义不同。

本工具优先使用 _transferSize，缺失时尝试 Header 与 Body 之和，再回退到 content size。结果适合比较和排序，不应当作精确计费流量。DevTools 显示的“资源大小”和“传输大小”也可能分别代表解压后与网络实际字节。

优化大文件时，要先判断类型：

• 图片检查尺寸、格式、响应式 srcset 和缓存。
• JavaScript 检查按路由拆分、第三方脚本和 sourcemap 是否误上线。
• JSON 检查字段裁剪、分页和重复数据。
• 字体检查字符集、字重数量、预加载和跨域缓存。

重复 URL 是否一定要删除

按“方法 + 完整 URL”重复只能作为线索。合理情况包括轮询、重试、缓存验证、分页参数相同但 Header 不同，以及多个组件确实需要同一数据。不合理情况可能来自重复 useEffect、组件重复挂载、错误重试循环或缓存键不一致。

复核重复请求时，应比较开始时间、发起方、Request Header、响应状态和正文。若并发重复请求可以共享结果，可使用请求去重、客户端缓存或服务端聚合；若是轮询，应设置明确间隔、页面隐藏暂停和错误退避。

为什么 HAR 分享前必须脱敏

HAR 可能包含：

• Authorization 和 API Key。
• Cookie、Set-Cookie 与 session ID。
• URL 中的 token、邮箱、订单号和搜索词。
• 登录、表单、支付和 GraphQL 请求体。
• 响应正文中的客户资料和内部配置。
• 内网域名、IP、服务版本与调试 Header。

脱敏工具会替换常见凭证字段，并可删除请求和响应正文。但字段名可能是业务自定义的，令牌也可能藏在普通文本、路径或编码内容里。下载副本后，应再次用文本编辑器搜索真实账号、域名、token 前缀和客户标识。

如果真实凭证已经发送给无权访问的人，删除附件不等于风险消失。应立即吊销令牌、结束 session、轮换密钥，并检查访问日志。

一套实用的 HAR 排查流程

1. 用最短步骤分别录制正常和异常 HAR。
2. 先按失败筛选，确认关键文档和 API 的状态。
3. 按耗时排序，检查关键路径是否串行或 wait 异常。
4. 按体积排序，查找图片、脚本和 JSON 大户。
5. 查看重复 URL，结合开始时间判断轮询、重试还是重复挂载。
6. 用 request ID 对照 CDN、网关和服务端日志。
7. 修复后用相同网络、缓存条件和步骤重录对比。
8. 分享前导出脱敏副本，并由第二个人抽查敏感信息。

HAR 最有价值的地方不是生成一张漂亮瀑布图，而是把浏览器侧请求变成可过滤、可排序、可与服务端日志关联的证据。它应当和 Performance Trace、APM、服务器日志及真实用户监控一起使用，而不是独立得出全部结论。