日志不是写给程序看的，是写给排障时的人看的。线上出问题时，最痛苦的不是没有日志，而是日志很多却搜不到关键链路：不知道哪个用户、哪个请求、哪个订单、哪个外部依赖出了问题。
先固定链路字段
每条关键日志都应该尽量带上 traceId、requestId、用户标识、业务主键、接口路径和环境信息。字段名要稳定，不要今天叫 uid，明天叫 userId，后天又混进中文描述里。
链路字段要服务检索。排障时能用一个 ID 找到从入口到数据库、缓存、消息队列、第三方接口的完整路径，日志才算真正可用。
业务事件要写清状态
一条好日志至少回答四个问题：发生了什么、对象是谁、当前状态是什么、下一步结果是什么。比如订单支付、任务执行、文章发布、文件上传，都应该记录关键状态流转。
不要只写“处理成功”“处理失败”。成功要说明影响范围，失败要说明错误码、外部响应摘要和是否会重试。涉及敏感值时，公共日志不要输出真实 token、私钥或 Cookie。
错误日志要保留上下文
异常堆栈很重要，但只有堆栈不够。还要带上入参摘要、业务主键、远程接口名、耗时和重试次数。这样才能判断是参数问题、依赖问题、权限问题还是系统问题。
同时要控制噪音。可预期的用户输入错误不应该刷满 error 日志；真正需要报警的是服务不可用、数据不一致、重试耗尽和安全边界异常。
日志要和指标配合
日志适合定位单个事件，指标适合观察趋势。错误率、耗时、队列积压、连接池使用率这些应该进入监控，而不是靠人肉翻日志。
日志字段设计的目标很朴素：出事时能搜到，复盘时能串起来，平时不制造噪音。做到这三点，排障效率会明显提高。
正文完
