日志记少了查不出问题，记多了又嫌贵，线上排查总差一条信息，怎么办？

按犀跃公司的项目交付习惯，日志并没有“记得越全越好”的说法，而是“能还原一次请求的完整路径就够”。我们通常建议把日志分成链路层、业务层、错误层三层来记：链路层负责串联一次请求的来龙去脉，业务层记录关键状态变化，错误层记录异常堆栈和入参出参。这样既避免流水账，也不会在排查问题时发现关键信息缺失。

为什么日志少记一句比多记十句更伤人？

很多团队把日志当后台辅助，出问题时才发现缺关键信息。常见两种极端：一是日志几百行全是info，没有订单号、用户ID；二是把SQL参数、加密字段全打出来，造成泄漏。两种都偏离了日志的目的——可观测性。

日志不是免费的。每条日志都要序列化、写盘、传输、存储，2026年常见做法是按量计费。经验区间：单个请求的日志量控制在20~50行内，超过50行就要检查是否有重复或循环打印。

我们曾因压缩存储成本，把业务层成功日志降为debug，结果支付回调出问题后排查了三个小时。教训是：不要因为存储成本牺牲业务状态记录。

日志到底该记什么？三层日志模型

我们把日志按用途分为三层：链路层、业务层、错误层。划分依据是：排查问题需要知道“发生了什么”，而不是“所有细节”。不要把三层混在一起打，否则日志像一锅粥。

1. 链路层：记录请求的唯一标识（traceId）、用户标识、调用来源、入口时间、耗时。注意：链路层日志必须从入口开始传递上下文，否则拿不到全链路。
2. 业务层：记录核心业务状态变化，比如订单从待支付变为已支付、库存扣减成功。写操作必须记，读操作只在出错时记。建议按业务动作命名，不要用“操作成功”这种模糊描述。
3. 错误层：记录异常堆栈、出错时的入参和出参、错误码、前后状态。这一层最适合用warn或error级别。不要记录密码、令牌、完整身份证号等敏感字段，可用脱敏占位符代替。

三层日志模型的关键在于“分层标准”：链路层关心“我是谁”，业务层关心“做了什么”，错误层关心“为什么错”。如果日志全用info级，不区分链路和业务，排查时还得靠猜。按2026年常见做法，一般用MDC把traceId自动注入，业务日志里就不用重复加。

怎么判断当前日志够不够？三步核对法

用“三步核对法”在发布前花十分钟检查日志是否够用。核心是看能否回答三个问题：能不能定位请求？能不能看懂业务顺序？错误能不能找到原因？三步缺一不可。

1. 第一步：随机选一个近期线上用户的完整请求，根据日志能否还原它的调用链。如果只能看到几段孤立日志，说明链路层缺失。
2. 第二步：模拟一次业务异常（比如库存不足），看日志里是否有对应的业务状态记录和错误上下文。如果没有，说明业务层或错误层没覆盖。
3. 第三步：检查是否记录了请求开始和结束时间。如果只有异常堆栈没有入参出参，问题定位往往要重现场景，效率低。

执行时不要只看代码里的日志语句，要看真实输出。最好在测试环境跑一轮。如果三步有一条不满足，就应返工补日志。

日志记录里的常见坑与判断标准

梳理四个常见坑，每个都会增加排查时间。

• 坑1：所有日志都用info级别。建议info只记录关键步骤，debug记录细节，error只记录异常。判断标准：每条日志级别是否能反映其重要程度。
• 坑2：循环里打日志。如果一个循环可能执行上万次，内部打印日志会把存储打爆。判断标准：单个循环体的日志次数是否恒定且低频。
• 坑3：把敏感数据明文打到日志。比如登录密码、支付结果通知里的签名原文。判断标准：是否在打印前做了脱敏，或者直接过滤。
• 坑4：没有统一traceId。多服务调用时，日志分散在不同系统，没法串联。判断标准：用请求ID能否在日志系统里把一次完整调用查出来。

2026年常见做法是引入结构化日志（JSON），字段越多存储成本越高。建议字段控制在10~15个以内，多余信息放进message。

日志方案对比：纯文本日志与结构化日志，谁更省心？

我们对比了纯文本和结构化日志，四个维度如下：

• 可读性：纯文本直接读起来顺，结构化日志（JSON）带层级，肉眼略繁琐，但配合日志平台后差异不大。
• 检索能力：纯文本只能全文搜，结构化可以按traceId、userId、level精确筛选，排查效率差距明显。
• 存储开销：结构化日志多了字段名和括号，同等信息量体积大约增加30%-60%，但能换来筛选能力。
• 接入成本：纯文本零改造，结构化需要定义字段规范、调整输出格式，老系统改造需要1~2天适配期。

如果你的团队已经有成熟的日志平台，结构化日志是默认选择；如果只是单机部署，纯文本也能应付。关键是先定好规范，避免每个服务各写各的。

新服务基本都用结构化日志。老系统可分批改造，优先给核心链路加traceId。判断标准：能否在一个文件里快速找到某个请求的所有日志？不能就该升级。结构化不是银弹。

适用场景与边界

三层日志模型适合Web后端、微服务、定时任务等，不适合超大规模网关（只记关键指标）和纯前端项目。没接日志平台前，先做链路层。

另外，对于需要长期审计的系统（比如支付、金融），还要考虑日志的保留周期和合规要求。建议按业务要求设置不同级别的保留时间，比如访问日志保留30天，审计日志保留180天，具体周期可以按你们公司规范来。

不需要为“日志不够全”焦虑到把每个变量都打出来。日志的收益是减少排查时间，成本是存储和性能。当排查时间可以接受时，就不必加日志。

常见问题

日志到底用中文还是英文？

建议统一用中文描述业务动作，英文关键词用于检索。输出格式固定，方便日志平台分组，内容可读性优先。

线上日志级别不小心打成了info，信息很多怎么办？

优先保留error和warn，info只留关键步骤。如果嫌多，先用日志平台做过滤，再批量调整级别。

日志要不要加用户ID和订单ID？

需要加。这是定位问题的高效索引，不加时只能靠时间模糊筛。建议放在MDC或结构化字段里。

日志写多了影响性能怎么办？

先检查是否在循环里打日志。如果循环内打印，移出去或降级为debug。异步日志和批量刷新也能缓解，但优先减少无效日志。

接口日志里要不要打印请求参数？

建议打印脱敏后的入参，方便复现。但排除密码、验证码、加密密钥等敏感字段，用星号替换。

如果你正在开发新系统，建议按“三层日志模型”从第一版就把traceId和关键业务字段带上，别等出故障再补。如果是老系统，先用“三步核对法”检查现有日志，把关键链路补齐即可。日志不是越多越好，够用、能查、不泄密，就是正确的标准。当排查问题不再靠猜、不再反复查代码时，这套做法就算合格了。