日志脱敏增加耗时：慢的到底是什么

慢的往往不是“把一串数字换成星号”那一下。日志脱敏增加耗时，九成情况是脱敏被塞进了本来该最快的写日志链路上：原来一条日志落盘只走一趟，现在中间插进了正则匹配、字段解析、查表、甚至签名计算，每一步都要把整条日志扫一遍。单条日志的差别肉眼看不出来，可量一上来，比如高峰期每秒几百上千条，这点开销就叠成一座山，业务响应跟着抖。所以别急着加配置，先把慢在哪一段搞清楚。

日志脱敏增加耗时，先分清成本落在写还是查

同一个需求，做在写入端和做在查询端，性能账完全是两回事。写入端脱敏——应用进程里做，或者采集 agent 做——成本摊到每一条日志上，业务一起量就跟着抖；查询端脱敏，日志原样落盘，分析的时候再遮，线上基本不受影响，但查历史会慢，还得管住谁能查、查完能不能带走。不少人喊慢，追下去是位置选错了：白天高峰在跑全量正则，夜里跑批反倒闲着。这个顺序调过来，体感差别很明显。

正则写得贪，单核能被吃干净

脱敏规则十有八九是正则。写起来爽，坑也在里头：`.*` 后面接一堆分支、嵌套量词、开头不锚定，碰上一条长日志就回溯，CPU 直接拉满。一条日志几 KB，一天上百万条，再乘以十几条规则，账很难看。能改的地方不少——正则预编译一次就别在循环里反复编译；能靠字符类限定就别用点号；先按字段名定位再匹配值，别全文瞎扫；长度明显不对的行提前剪掉。还有个小坑：把几十条规则串成一条大 alternation，看着优雅，实际每次都要走完整条链，慢得很均匀。

为了脱敏先解析，这步常被漏算

JSON 日志得先 parse 才能按字段脱敏，而解析本身就不便宜，尤其带堆栈、带转义、字段嵌套深的。在写日志的线程里做一次完整反序列化，等于把一条本来只是字符串拼接的路径，变成了一次小型对象构造。两个方向可以试：让应用按约定直接输出结构化字段，别让下游猜；或者把解析挪到采集端，用轻量方式取需要的字段，别在业务线程里折腾。半结构化、多行堆栈这类日志最明显，格式不统一的时候更糟。

同步还是异步，差的是业务响应

不少人是在应用进程里同步脱敏的，日志组件一慢，请求就跟着等，尤其那种每次写都 flush 的 logger。这种慢不该算在“日志”头上，是业务被日志拖住了。常见做法是日志先进内存队列或本地文件，脱敏交给后面的 agent 或者旁路进程。代价得认：日志有秒级延迟，进程被 kill 可能丢掉最后一小段。能不能接受这个延迟，看业务本身，不是所有场景都适合异步。

加密和哈希，贵是应该的

掩码替换便宜，本质上就是字符串操作。要做 HMAC 或者可逆加密，那就贵，每条日志每个字段算一遍，CPU 蹭蹭往上涨。这里有个偷懒但合理的办法：同一个主体（用户 ID、手机号）在一次任务里算一次，结果缓存起来复用，别每条日志重复计算。另外别把两种需求混在一起，“看不见”和“能还原”是两码事，能掩码就别上加密，能丢字段就别留原值。

慢的不一定是 CPU，磁盘和索引也在算账

脱敏会改日志的形态：字段被换成长度不一的内容、有的一行被切开、保留字段忽多忽少。写入量、压缩率、检索字段的索引都跟着变。见过脱敏之后写入没慢多少、查询慢一大截的情况，问题在索引和 mapping 上。还有一条常见浪费：应用做一遍脱敏，采集端再做一遍，两遍白干，各自还加了一份开销。日志量涨的时候，脱敏线程池也会被打满，排队时间比处理时间还长。

规则表越长越慢，可砍规则得有人点头

规则多一条，链路就多扫一遍。但脱敏规则不是纯技术决策，砍哪条得看合规要求：哪些字段属于个人信息、哪些必须留原值便于排障，这些往往有内部文档或者外部要求。技术上能做的是收敛，不是删——把黑名单式的全文匹配尽量换成按字段的白名单处理，只碰该处理的字段，别每条日志全文过一遍。至于具体字段清单和留存期限，以各自的服务商说明和合规口径为准，别照抄别人家的规则表。

怎么量：先分段，再动手

别拍脑袋改。把链路切成段：日志产生、进队列、落盘、采集、脱敏、入库，每段单独计时，看 P99 而不是平均值——平均值会把尖峰抹平，用户感知到的恰恰是尖峰。压测拿真实日志样本，带堆栈、带长字段那种，别用干净的测试串。再拿 profiler 抓一下热点函数，多半会落在正则或者序列化上。量完再改，改一处复测一次，别一口气全换。

几个立刻能试的改动

顺序大概是这样：先把脱敏挪出业务线程；再给正则做预编译和收敛，砍掉确实没必要的规则；然后统一脱敏位置，别上下游各做一遍；接着给重复计算的字段加缓存；最后才考虑加机器或者换更快的存储。顺序反了，钱花了效果不一定出来。小站小流量的话，前三步做完基本就够用了。

回到标题那个问题：慢的到底是什么。多数时候不是脱敏这个动作，而是它待错了地方、带着一堆没收敛的正则、还在业务最忙的时候同步跑。真要动手，先花半天把链路分段量一遍，比直接升级配置靠谱得多。剩下的字段怎么定、日志留多久，那是另一本账，按自己的实际情况来。