分布式链路追踪中异常信息易泄露PII，需在框架拦截层、埋点增强层、采集过滤层协同脱敏，保留诊断价值的同时屏蔽手机号、身份证号等敏感字段，确保合规与可观测性平衡。
在分布式链路追踪中，异常信息天然携带大量上下文——比如堆栈中的方法参数、HTTP 请求体、数据库错误提示，甚至日志里打印的用户 ID、手机号、身份证号等敏感字段。这些内容一旦被完整采集进 Trace 数据（尤其是 Span 的 tags 或 logs 字段），就可能违反《个人信息保护法》或企业安全规范。脱敏不是简单地“不打日志”，而是有策略地保留诊断价值、剥离可识别身份的信息。
哪些异常变量容易泄露 PII？
常见高风险位置包括：
-
异常堆栈中的入参值：如
UserService.findById("186****1234")中的手机号字符串直接出现在 StackTraceElement.toString() 里 - HTTP 错误响应体：下游服务返回的 500 响应含原始 SQL 报错，暴露用户邮箱或订单号
-
自定义异常 message 字段：开发者习惯写
new IllegalArgumentException("用户 " + userId + " 余额不足")，userId 若为手机号或身份证号即成隐患 -
Span 的 tags 属性：手动注入
span.tag("user_id", "31011519900307****")未做掩码
脱敏的三层落地方式
不能只靠开发自觉，需在框架层、埋点层、采集层协同控制：
-
框架拦截层（推荐首选）：在全局异常处理器（如 Spring 的
@ControllerAdvice）中，对Throwable的 message 和 stack trace 做正则清洗。例如匹配中国手机号1[3-9]\d{9}、身份证前 6 后 4 位等模式，统一替换为1XX****XXX格式 -
埋点增强层：使用 Sleuth 或 Micrometer Tracing 的
TracingClientHttpRequestInterceptor拦截出站请求，在记录 error tag 前过滤 request body；对入参对象使用注解（如@Sensitive）标记字段，通过 AOP 在 Span 创建前自动脱敏 -
采集过滤层：在 Zipkin/SkyWalking 的 Collector 端配置字段白名单，禁止将含
phone、id_card、password等关键词的 tag 写入存储；或用 OpenTelemetry 的SpanProcessor在上报前移除敏感属性
关键细节：别让脱敏破坏排查能力
脱敏不是抹掉一切，而是保留“可定位、不可识别”：
- 保留异常类型（
NullPointerException）、发生位置（OrderService.createOrder:42）、耗时、状态码等非敏感元数据 - 用哈希替代明文：对用户 ID 脱敏时，可用 SHA-256 哈希后取前 8 位作为 trace-level 标识符，既防追溯又支持跨服务关联
- 区分环境：测试/预发环境可保留全量异常信息，生产环境强制开启脱敏策略，并通过配置中心动态开关
脱敏不是加一道 if 判断，而是把规则嵌进可观测性流水线的每个环节。真正健壮的链路追踪系统，应该让开发看到“哪里错了”，而不是“谁错了”。
