日志平台按关键词搜索，输入 6b6579 能命中 1.4 万条记录，内容是 AESUtil 打印的 key 十六进制串，从半年前开始一直有。日志里能对上时间点，这种反而好排。
调试时加的 log.debug 没有删，日志级别在生产被调成 DEBUG 之后开始输出。密钥以 hex 形式打印，绕过了按明文关键词做的脱敏规则。日志平台权限比数据库还松。这一点先确认清楚，后面就不用反复试。
grep -rn 'log.debug.*key' src/main/java grep -c 'key=' /var/log/app/app.log
这次卡住的地方就在「密钥进日志」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。
处理上按这个顺序：删除打印密钥的日志语句 需要排查时只打密钥指纹的前 8 位；脱敏规则同时覆盖 hex 和 base64 形式；把日志级别固定为 INFO 并纳入配置审计；轮换已经进日志的那把密钥。
结果对不对很好判断，新日志里搜不到 key 的 hex 值 日志平台历史命中数不再增长。