客服让你发 HAR 日志？导出后先检查这几处

网页打不开，客服让你按 F12，导出一个 .har 文件。文件名像技术日志，看不懂，是否直接拖进聊天窗口就行？先别急：它可能比一张报错截图包含更多信息。

这篇按 Chrome 官方文档和 HAR 格式资料整理，解决“怎样少记录、先检查、再发送”这个问题。本文没有采集真实账号日志，配图也只是检查顺序，不是一次脱敏成功的实测证明。

先问清楚，是否真的需要整个文件

HAR 用于保存浏览器的网络请求信息。Cloudflare 的排障说明提醒，这类记录可能带有密码、付款资料等敏感内容。它不是只有错误码的一张纸。

如果只是报告“某页出现 403”，先提供出错时间及其时区、浏览器版本、操作步骤和脱敏截图。让对方说明需要哪一段请求、要确认什么，再决定是否录制。能用这些信息定位，就不必额外发送一整份网络记录。

确认收件人来自已经核对的官方工单或支持渠道。群里有人自称技术人员，不等于你需要把文件私发给他；也别为了看懂日志，先上传到不熟悉的在线解析器。

确实需要时，可以在单独窗口准备目标页面，再打开开发者工具的 Network（网络）面板。清空已有请求后，执行一次会触发问题的操作，出现问题就停止录制，不顺手继续查邮箱、订单或个人资料。

排查跳转过程时可能需要 Preserve log（保留日志）；它也会扩大留下的记录范围。按支持人员明确要求使用，不为了“资料齐全”长时间开着。关闭缓存会改变测试条件，也不是隐私保护步骤，不要顺手把所有开关都改一遍。

若问题在未登录状态也能复现，可先录制未登录过程。只有登录后才出现的故障，不能用未登录的正常页面冒充复现；先和客服商量较少暴露数据的复现方式。无痕窗口减少的是环境里的既有数据，不会让你随后输入的密码或加载的私人页面自动从记录里消失。

Chrome 的网络面板说明提供 Export HAR (sanitized)，也可在请求列表右键的 Copy 菜单中选择保存为 sanitized HAR。不同版本和语言的文字可能略有差异，先看清是否标有 sanitized，不要为了求助开启 with sensitive data。

官方列举的自动排除内容包括 Cookie、Set-Cookie、Authorization 请求或响应头。这不能作为整份文件已经没有个人信息的保证。 你要保护的内容不一定只在这三个头里。

例如，订阅凭据可能就在网址中；某个查询接口也可能返回你的邮箱。即使敏感头已经处理，仍需检查这些位置。这是根据记录结构作出的风险判断，不是声称所有浏览器、所有导出方式都会保留相同字段。

HAR发送前检查顺序：先确定是否需要完整日志，缩短记录范围，导出sanitized版本，再核对网址、正文和响应；看不懂时先不发送原文件，只走确认的支持渠道

保留原文件在自己电脑，另存一个用于检查的副本，用本地文本编辑器打开。HAR 历史格式草案描述了网址、查询参数、提交数据和响应内容等字段；实际导出有哪些，取决于浏览器及请求。

不要只搜 password。token、key、session 可以作为查找起点，但并不是完整检测器；字段名可能完全不同，正文还可能经过编码。搜不到熟悉关键词，不等于检查通过。

还有重复出现的情况：同一个参数可能同时出现在完整网址和参数列表里。只改其中一处，另一处仍可能暴露。若自行替换值，注意保持 JSON 结构可读，记录删改了哪些类别，并向客服说明这是处理过的副本；不要把删改后的内容当成服务器原始响应。

把 .har 改成 .txt，或者压缩成 ZIP，不会自动删掉内容。若无法确认其中有没有凭据，先别发原文件，让客服缩小所需字段，或请有权限处理这类资料的人协助。单位设备和业务数据还应遵守自己的数据处理规则。

发送前重新打开最终附件，确认选的是检查后的版本，而非旁边的原件。公开论坛优先发必要的错误摘要；完整日志即使经过处理，也只交给已确认、确有需要的支持渠道。

如果文件已经公开，删除消息只能减少继续传播，不能保证没人保存。按实际暴露内容撤销令牌、结束相关会话或联系服务方，不把“重置订阅”当成能解决所有泄露的统一动作。订阅链接本身的处理可参考这篇隐私说明。