结构化字段有的写 user_id 有的写 userId 检索命中率一半

同一条业务日志在三个服务里分别写成 user_id、userId、uid，按 user_id 检索只能命中三分之一，排查时以为另外两个服务没打日志。碰到这种情况，我一般先确认改动有没有真的生效。

原因不复杂，各服务自己定字段名 没有公共 schema。采集端也没有做字段映射 原样写进索引。

「结构化字段命名」这类改动最怕改一半，回滚脚本先准备好，再动生产。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。

processors:
  - rename:
      fields:
        - {from: "userId", to: "user_id"}
        - {from: "uid", to: "user_id"}

权限不要一口气开到最大，先加到够用再往上试，范围小才好收。把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。

改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。

具体做法是，定一份字段命名规范 统一用下划线；在采集端加字段重命名 兼容存量写法；日志 SDK 里封装固定字段 业务只填值；用同一批请求验证三个服务的检索结果一致。

最后用这个标准收尾，按 user_id 检索能命中三个服务的全部日志。