日志打到哪，本身就是个技术问题

一、先分清三种日志

业务日志。 用户做了什么：下单、支付、导出。作用是复现问题、追溯操作链路。

运行日志。 程序跑了什么：启动了、处理了第几个请求、哪里慢。作用是排查故障。

审计日志。 谁在什么时候动了什么数据。作用是追责和合规，要求不可篡改、长期留存。

很多项目把这三种混在一个文件里，结果出问题时谁也查不动——业务日志刷掉了关键上下文，审计日志里全是无意义的调试输出。

二、日志打在哪，决定了它有没有用

打在本地文件。 最简单，重启机器或磁盘写满就没了。适合个人开发，不适合线上。

打在标准输出。 容器环境里最常见。日志往 stdout 一写，交给运行环境收集。好处是应用完全不需要关心存在哪，容器滚动更新时日志也跟着走。

打在集中式的日志服务。 服务端查一次就够，不用登机器翻文件。代价是多一个组件和一个可能的故障点——日志服务挂了，业务要不要跟着挂？一般不要，异步发，失败丢弃。

三、必须带上的四个字段

不管打在哪，这几个字段缺一个都会让排查变难：

一、时间。 精确到毫秒，带时区。多个服务器对时不一致时，这一项能直接决定结论对错。

二、级别。 至少区分 error、warn、info。级别混乱的日志等于没有级别——全是 info 出问题时筛不出重点，全是 error 正常业务也天天报错。

三、这条日志属于哪个请求。 一个请求会产生多条日志，没有关联标识就只能靠时间猜。前端传进来的 trace id 或者网关生成的那个都行，关键是全链路透传。

四、关键的业务标识。 用户 id、订单号。出了线上问题，你不可能拿着 trace id 去问业务方"这是谁的订单"。

四、两个真实踩过的点

一、日志本身影响性能。 大量 debug 级别的日志会把磁盘写满、把接口拖慢。更麻烦的是它和出问题的时刻高度重合——出故障时正好是日志量最大的时候。写日志要分级控制，异常高峰时才放开 debug。

二、敏感信息不能进日志。 密码、token、身份证、完整手机号，进了日志就等于进了第三方系统。日志平台的权限往往比业务库宽松得多，而且日志会被复制到多个索引。打印用户信息时做脱敏，保留前后几位就够定位。

五、怎么定一条合理的基线

不用一开始就上复杂的链路追踪，从这四条开始就能覆盖绝大部分场景：

每条日志 = 时间 + 级别 + traceId + 一句话描述
错误日志额外 = 错误类型 + 关键参数（脱敏后）+ 可复现的输入

跑一段时间之后回头看，问自己两个问题：上次故障我是靠哪条日志定位的？如果答不上来，说明缺关键字段；如果每次都去翻某个特定文件，说明有内容没按约定打出来。