缺陷截图和日志里的账号、手机号、内部地址怎么脱敏

2026年11月13日

缺陷附件来自生产环境时，截图和日志往往同时包含可复现问题的关键线索和真实用户数据。脱敏的核心判断是：保留时间、报错、请求路径结构等能支撑定位的信息，遮蔽或替换账号、手机号、内网地址等能指向具体人或具体内网位置的内容。下面按识别、截图处理、日志处理、分工复核、示例和完成检查六个环节说明具体做法。

Table of Contents

要点总览（TL;DR）

脱敏前先列清单：账号类、个人标识类、内部地址类、令牌类四类对象逐项比对截图与日志，日志用关键词加正则检索，截图逐屏检查。
截图用不透明色块覆盖敏感内容，先截全图再遮蔽，保留报错文案、按钮状态、时间等复现要素，多图保持统一口径。
日志按行替换为统一占位符（如 [账号]、[手机号]、[内网IP]），截取错误时间段与堆栈，专门检查请求头、URL参数和异常信息。
提交人负责识别与遮蔽，复核人按同一清单抽查，脱敏说明写入缺陷描述；发现遗漏退回补正并重新复核。
提交前按完成检查表逐项确认：四类对象全部处理、截图不可还原、占位符统一、复现信息保留、脱敏说明已记录。

先列清单：截图和日志里哪些内容必须脱敏

动手遮蔽之前，先把要找的对象列成清单，再拿清单去比对附件。清单按四类组织，覆盖缺陷附件中最常见的敏感信息。

类别	具体对象	常见出现位置
账号类	登录名、用户ID、邮箱前缀、工号	页面右上角、个人中心、操作日志、请求参数
个人标识类	手机号、身份证号、银行卡号、收货地址	表单回显、订单详情、接口返回体
内部地址类	内网IP、主机名、内部域名、接口路径中的内部服务名	浏览器地址栏、报错堆栈、网关日志、配置项
令牌类	Cookie、Session ID、Token、密钥、签名串	请求头、URL参数、前端存储截图

识别时把人工检查和检索结合起来。日志文件用关键词加正则做全文检索：搜“token”“session”“cookie”“password”等字段名，用手机号号段规则和IP地址格式做正则匹配，再按账号清单逐个搜已知的登录名和工号。截图无法检索，需要逐屏检查，重点看页面顶部账号区、表单回显区、地址栏和弹窗提示。检索和逐屏检查各做一遍，两类附件都过一遍清单，才算完成识别。

截图怎么遮蔽：保留复现信息的最小改动

截图脱敏的目标是让看图的人能理解问题现象，同时无法从图中还原出具体身份和内网位置。操作顺序如下。

先截全图，包含页面标题、操作区域、报错提示和按钮状态，再进入遮蔽环节。先裁图再遮蔽容易把判断问题所需的上下文一起裁掉。
用不透明色块覆盖敏感内容。半透明蒙层和模糊处理在特定条件下可能被还原或辨认，不透明色块更稳妥。
逐处覆盖账号、手机号、内网地址，覆盖范围略大于文字本身，检查色块边缘是否露出字符笔画。
保留报错文案、按钮状态、操作时间、页面布局等复现要素，这些内容不涉及身份，不需要处理。
同一缺陷有多张截图时，统一遮蔽口径：同一账号在多张图中用同一种色块，避免一张遮一张不遮。

如果页面中账号和业务数据混排，可以只覆盖账号部分，保留业务数据的结构和量级，例如订单号可以保留格式、替换其中几位，让看图人仍能判断数据形态。

日志怎么处理：替换、截取与结构化清理

日志附件的处理分三步：替换敏感值、截取相关片段、检查容易遗漏的字段。

替换时按行检索账号、手机号、IP，统一替换为带类型标识的占位符，例如 [账号]、[手机号]、[内网IP]、[Token]。占位符写法全篇一致，阅读日志的人能直接看出被替换内容的类型，也便于判断是否还有遗漏。同一用户在日志中出现多次时，可以替换为 [账号A]、[账号B] 区分不同对象，保留多用户场景下的排查线索。

截取时保留出错时间段前后若干行和完整错误堆栈，删掉与问题无关的大段正常日志。请求头、URL参数、异常信息中的敏感字段容易被忽略，替换完成后专门检查这三处。时间戳、错误码、调用链结构和请求路径的服务层级关系需要保留，它们是定位问题的依据。

角色分工与提交前复核

脱敏由提交缺陷的人执行，复核由另一人完成，两个角色分开可以降低遗漏概率。分工和交付物如下表。

角色	动作	交付物
提交人	按清单识别截图与日志中的敏感信息，完成遮蔽和替换，在缺陷描述中写明已脱敏及遮蔽范围	脱敏后的附件、脱敏说明
复核人	按同一份清单抽查附件，重点看截图边缘、日志请求头和异常信息	复核结论，遗漏项清单
提交人（补正）	对复核发现的遗漏重新遮蔽或替换，更新附件并补充说明	补正后的附件

复核发现遗漏时，缺陷退回提交人补正，补正完成后重新复核，不复用上一次的复核结论。脱敏说明写入缺陷描述，内容包括处理了哪些类别、使用了什么占位符，方便后续阅读附件的人理解被替换的内容。

在缺陷提交与跟踪环节，ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。附件和描述随缺陷记录一起流转，提交人可以在描述中保留脱敏说明，复核人也能在同一条缺陷记录中完成抽查和退回补正。

一个完整示例：从原始附件到可提交缺陷

以下为演示情景，用于说明操作标准，不代表真实案例。

某功能在测试环境复现失败，提交人从生产环境截取了一张订单详情页截图和一段服务端错误日志。截图中包含登录名“zhangsan”、手机号“138****5678”的完整号码、地址栏中的内网IP“10.20.30.40”，以及报错弹窗“订单状态同步失败，错误码 E1024”。日志中包含请求头里的 Session ID、URL参数中的用户ID和一条指向内部服务“order-sync.internal”的堆栈信息。

识别阶段，提交人对照清单标出上述敏感点。遮蔽阶段，截图中的登录名、完整手机号、内网IP分别用不透明色块覆盖，报错弹窗、错误码和页面布局保留。日志中 Session ID 替换为 [Token]，用户ID替换为 [账号A]，内网IP替换为 [内网IP]，内部服务名替换为 [内部服务]，时间戳、错误码 E1024 和调用链层级保留。缺陷描述中写明“附件已脱敏：账号、手机号、内网IP、Token 已替换，报错信息和调用链保留”。

复核时，复核人发现日志异常信息末尾还有一处手机号未被替换，退回提交人补正。提交人替换后更新附件，复核通过，缺陷进入修复流程。

完成检查：提交前逐项确认

提交前按下面清单逐项确认，全部通过再提交。

清单内的账号、个人标识、内部地址、令牌四类对象是否全部处理。
截图遮蔽是否使用不透明色块，放大后是否无法辨认原字符。
多张截图的遮蔽口径是否一致，同一对象是否用同一种处理方式。
日志占位符是否统一，是否覆盖请求头、URL参数和异常信息。
时间戳、错误码、报错文案、调用链结构等复现信息是否保留充分。
脱敏说明是否写入缺陷描述，是否说明处理类别和占位符约定。
复核人是否已按清单抽查并给出结论，遗漏项是否完成补正。

这份清单同时可以作为团队缺陷提交规范的附件检查项，与缺陷分级、提交模板等规范配合使用。

常见问题

截图里的账号和业务数据混在一起，只遮账号会不会影响问题复现？

通常不会。复现问题依赖的是页面结构、报错文案、按钮状态和操作路径，账号本身只用于标识操作者。可以只覆盖账号部分，保留业务数据的结构和量级；订单号一类标识如果必须保留，可保留格式、替换其中几位，让看图人仍能判断数据形态。判断标准是：看图人能否理解问题现象，同时无法从图中还原出具体身份。

日志很长，全部替换工作量大，能不能只附出错的那几行？

可以截取，但要保留足够的上下文。建议保留出错时间段前后若干行和完整错误堆栈，删掉与问题无关的大段正常日志。截取后仍需对保留部分做替换，重点检查请求头、URL参数和异常信息这三处容易遗漏的位置。截取减少的是无关行，不能替代对保留内容的脱敏。

团队没有专职复核人，提交人自己检查一遍可以吗？

可以执行，但遗漏概率会上升。更稳妥的做法是让同组另一位成员按同一份清单抽查，重点看截图边缘、日志请求头和异常信息。如果确实只有提交人自己，建议在提交前隔一段时间再按完成检查表逐项过一遍，并借助缺陷记录中的描述写明脱敏范围，便于后续阅读附件的人发现异常时反馈。

脱敏后的附件在缺陷跟踪工具里怎么留痕，方便后续追溯？

把脱敏说明写入缺陷描述，注明处理了哪些类别、使用了什么占位符，附件随缺陷记录一起流转。在 ONES 中，ONES Project 支持一键提交 Bug 至对应项目或迭代并记录跟踪修复情况，ONES TestCase 支持未通过的用例快速创建缺陷任务，提交人可在描述中保留脱敏说明，复核人也能在同一条缺陷记录中完成抽查和退回补正。