生产日志里密钥/PII 泄漏，如何系统性定位"哪条代码路径打出来的"而不只靠人肉 grep？

【背景】 我做安全加固复盘时发现一个反复出现的现象：安全基线里写了"密钥不落明文日志"，可审计时几乎总能在历史日志里翻到 AccessKey 片段、JWT 或用户手机号。它不像 CVE 有明确编号，而是散落在几十个服务的滚动日志里，靠人肉 grep 根本追不全，追全了也不知道是哪段代码、哪个字段、哪次请求触发的。

【现象】

• 泄漏源不止一处：有的是业务代码手动 logger.info 打了整个 request body，有的是框架序列化对象时把 @JsonIgnore 漏配，有的是第三方 SDK 自带的 debug 日志；
• 同一个服务不同环境表现不一致（测试环境有、生产没抓到，因为日志级别不同）；
• 事后想"堵源头"，但不知道历史数据里到底有多少条、哪些字段、能不能定位到调用栈。

【已尝试的排查】

1. 用正则对日志做扫描，命中一大堆，但误报高（把测试账号、示例数据也抓进来了），无法区分"真泄漏"和"噪声"；
2. 静态扫代码找 logger 调用，只能定位"可能打日志的位置"，定位不到"实际打出敏感字段"的那一行；
3. 想上 DLP/日志脱敏网关，但担心对高 QPS 服务有性能影响，还没敢全量上。

【期望得到的答案形态】 希望有人给一套可复现的定位 + 封堵方法论，最好包含：

1. 如何在"不重启业务"的前提下，先确认哪些服务、哪些字段真的在打敏感信息（而不是猜）；
2. 一条从"日志命中"倒推到"具体代码行 / 字段"的链路（工具 + 配置示例，比如 log 采样、结构化日志、traceId 关联）；
3. 脱敏网关 vs 应用层脱敏的取舍，以及对性能的实际影响量级；
4. 已经沉淀下来的"防再犯"手段（CI 卡点、日志规范、自动化回归）。 能贴命令、配置片段、阈值的，最欢迎。