日志脱敏的"度"到底卡在哪：全量打码 vs 默认脱敏按需还原，你们怎么平衡「合规」和「还能排查」？

【背景】 做了 8 年安全加固，最近在帮一个电商团队做日志治理，卡在日志脱敏上，想听听大家线上怎么取舍。背景：

• 日增日志 200GB+，链路 Filebeat → Elasticsearch；
• 日志里混着手机号、身份证号、银行卡号、收货地址、订单号；
• 合规要求：手机号 / 身份证 / 银行卡必须脱敏（个保法 + 等保三级）；
• 但客服 / 运维排查时经常要"看一眼原文"才能定位。

矛盾很实在：脱敏打太狠，排查时连"是哪条记录"都定位不到；打太松，合规审计一查就穿。

【常见分歧 / 几种做法】 我见过四派：

1. 全量打码派：所有 PII 字段一律 ***。合规最稳，但排查基本靠猜；
2. 部分打码派：手机号留前 3 后 4（138****1234）、身份证只留后 4。兼顾定位和合规，但"保留几位"各家标准不一；
3. 动态脱敏派：明文落盘、查询层按需脱敏 + 权限控制。排查体验最好，但明文已经落盘，合规风险最大；
4. 应用层 SDK 派：序列化阶段统一脱敏，下游采集 / 存储全干净。侵入业务代码，改造成本高、易漏。

【我的倾向与理由】 我倾向「默认脱敏 + 按需还原 + 全程留痕」的混合方案：

• 合规底线是"明文不能长期落盘"，所以明文落盘那条路我基本不选；
• 但全量打码会把排查能力打没，所以保留可逆定位字段：traceId、订单号、手机号前 3 后 4；
• 需要看原文时走"审批 + 临时授权 + 操作审计"，而不是放开明文；
• 脱敏逻辑收敛到应用层 SDK（统一出口），别散落在各服务的 logback 配置里——后者一定会漏。

一句话：脱敏不是"打几个星号"，而是"在哪个环节、对谁、保留多少、留不留痕"的一组策略。

【想听大家在什么场景下怎么选】

1. 你们线上 PII 日志是「落盘前脱敏」还是「查询时脱敏」？
2. 「保留前 3 后 4」这种部分打码，内部有统一标准吗，还是各服务各打各的？
3. 动态脱敏（明文落盘 + 权限控制）你们敢用吗？合规 / 审计怎么过的？
4. 脱敏逻辑放应用层 SDK、logback 配置还是采集 agent，踩过哪些坑？
5. 有没有"脱敏后又想还原、但还原成本太高最后直接放弃脱敏"的真实案例？

欢迎拍砖，尤其踩过坑的。