日志输出不应该有与不应该少的两组反直觉原则

好日志的标准不是”多与少”（行数），而是”恰当”（内容）——不该有的不要 有，该有的不要少。四类不该有的内容：敏感信息（密码/银行账号/身份证一旦 流入索引存储归档，清理起来极其麻烦，但用户ID这类非敏感标识应该保留， 可用MDC自动打印）；慢操作（日志应该只打上下文中已有的数据，如果要专门 调远程服务或查数据库才能拿到，就该先想清楚是否真有必要）；追踪诊断 信息（不要打方法入参、返回值、执行时长——这条是反直觉的，不少公司甚至 把它当最佳实践提倡，但作者坚持归为反模式，因为”敏感信息泄漏”和”引用慢 操作”这两个问题的主要源头恰恰就是这类调试用途的日志，比如把User对象 序列化打日志会连带暴露Password字段，把生产环境的大Map全量打印就是在 引用慢操作；调试诊断应该交给专门的追踪系统或BTrace/Arthas这类On-The-Fly 工具去做）；误导性内容（明明已经妥善处理了的异常，习惯性地调一句 printStackTrace()打到日志里，会让日后排错的人盯着这段堆栈瞎找线索）。 三类不该少的内容：TraceID（请求没带就自动生成，贯穿整条调用链，并 随响应返回客户端，方便用户报障时快速定位，单体系统里同样有用）；关键 事件（该记录的操作、异常、警告、定时任务，性能问题应由运维调整日志级别 解决而非干脆不打）；启动时的配置信息（因为初始化逻辑通常只执行一次， 不便于诊断时复现，所以哪怕平时觉得没用，也应该在启动时打出来）。