上个礼拜陪一个朋友定位线上接口超时他把几十个logger.info从头翻到尾愣是看不到一次完整的调用链路——谁调的、带什么参数、中间走了哪些分支全都没有。最后我用一条带traceId的关键链路日志三分钟锁定问题。这事让我特别想聊聊日志打印它看起来是“print两行”的事可生产环境一抖动能救你命的只有日志。所谓“大厂也在执行的15个日志打印的建议”本质上是把“什么时候打、打什么内容、用什么级别、怎么打不拖垮系统”这些事沉淀成一套可执行的规范新人进来照着做老人排查时少骂街。今天这篇文章就把这15条建议逐一拆开结合我在真实项目里踩过的坑讲清楚每条背后的道理和落地时的注意细节。1. 为什么大厂对日志打印这件事这么较真1.1 日志不是“写给你自己看的”是“写给排障时的队友看的”我刚工作那会儿也干过这事为了方便调试随手System.out.println(进来了); 等到代码上线print打到控制台日志文件里什么都没有出了问题只能靠猜。后来带我的大哥说了句话我一直记着“日志不是写给你自己的是写给未来的你和今晚值班的同事的。你写的时候觉得‘反正我看得懂’你加班的时候就知道自己当年有多坑了。”大厂之所以愿意花精力去定日志规范根本原因是日志承担了三个不可替代的角色。第一它是生产环境里唯一的“现场回放”系统不会告诉你刚才发生了什么只能靠日志还原第二它是跨团队协作的共同语言接口调用方、下游服务、运维、SRE大家看到的都应该是同一套日志信息结构第三它是审计和监控的数据底座指标报警、链路追踪、业务分析全都建立在日志之上。你把它当成可有可无的print后面所有环节都会跟着难受。1.2 一套烂日志会让排查事故的时间成倍增长很多人觉得“打日志”是小事但一旦线上出故障日志质量直接决定平均修复时长MTTR。我见过一个真实例子支付回调接口报错代码里只打了“回调失败”既不打印参数也不打印异常堆栈。排查的人只能猜是签名错误、参数缺失还是网络抖动最后靠改代码加日志、再发布、再复现折腾了整整一个下午。而如果一开始就按规范打一条“收到回调订单号xxx参数xxx验签结果xxx”这类问题基本一眼就能定位。更隐蔽的成本是长期维护。日志里充斥着无意义的调试信息、格式不统一的内容、夹杂着用户隐私时间一长日志系统的存储成本直线上升检索效率却越来越低。这正是“大厂也在执行15个日志打印建议”的根本逻辑不是矫情不是流程繁琐而是这些规范能直接减少故障排查成本、降低存储开销、避免合规风险。说白了日志规范是拿制度换效率前期花点心思后面全是回报。2. 15条建议全景速览先搭好整体框架2.1 一张表把15条建议分类看清在逐条拆解之前我先把这15条建议分了个类方便你先搭框架再记细节。分类覆盖的建议核心目标打印时机入口出口、状态变更、异常分支让日志完整覆盖关键路径级别与格式级别选择、统一格式、ISO8601时间让日志可读、可过滤、可检索内容与上下文参数化打印、traceId、用户上下文、脱敏让日志能还原现场性能与资源避免循环打印、异步日志、合理序列化让日志不影响业务性能存储与监控轮转保留、ERROR告警、清理治理让日志可查、可告警、可持续2.2 这15条建议讲究“组合拳”单拎一条效果有限有一点值得提前说明这些建议单独看都不复杂难的是组合使用。比如你定了统一的日志格式却没有在拦截器里生成traceId那格式再漂亮也只是“看起来统一”查起来还是要靠肉眼对字段又比如你做了异步日志却把日志级别全设为INFO系统一上线流水量直接翻倍异步队列也跟着满了。我的经验是先定格式和级别再处理上下文和链路最后补性能和存储。这条顺序很重要因为格式决定你能看见什么级别决定你该看见什么上下文决定你能不能看明白而性能和存储决定这套方案能不能长期跑下去。后面的章节我会按这个顺序逐步把15条建议讲透。3. 建议细则一打印时机、日志级别与统一格式建议1-63.1 建议1-2入口出口必打状态变更必打第一条建议凡是能被外部触发的入口HTTP接口、MQ消费、定时任务入口进入时打印一条请求日志离开时打印一条结果日志。别小看这两条很多问题就是靠这对日志定位的请求进来了没处理说明中间有分支拖住了请求没进来说明前面的路由或网关就有问题。入口至少记录调用方IP、请求方法、关键参数出口至少记录执行耗时和结果码。第二条建议关键业务的状态变更一定要打日志。举个例子订单从“待支付”变成“已支付”是谁改的、哪个操作触发、变更前后各是什么状态这些信息必须落到日志里。业务系统出问题十有八九是状态流转出问题没有变更日志的支撑复盘时只能对着数据库发愣。记录的格式我一般这样写订单状态变更from待支付,to已支付,operatoruserId:12345,sourcepaymentCallback,changeReasonsuccess。3.2 建议3-4异常分支必须打日志级别不能一刀切第三条建议凡是捕获到异常的分支一定要打日志。这条听起来像废话但实际代码里catch块里什么都不写、或者只写一个e.printStackTrace()的情况比比皆是。异常日志至少要包括异常类型、具体的异常消息、完整的堆栈以及当时的上下文参数。我自己踩过一个坑某接口偶尔超时catch里只打了“timeout”没有打堆栈后来才知道是连接池获取不到连接而“timeout”这个词几乎是所有超时异常的共用词排查起来极为痛苦。第四条建议日志级别不能用一刀切。我见过有人为了让日志“全面”把所有logger都设成INFO结果海量流水淹没关键告警也有人把全部设成ERROR结果线上根本没有有效排障信息。我的建议是DEBUG给本地开发用INFO记录业务入口出口和关键状态变更WARN记录可能有隐患但不影响主流程的异常分支ERROR只留给确实需要人工关注的故障。级别选对了日志系统才有信噪比可言。3.3 建议5-6统一格式参数化打印而不是拼字符串第五条建议统一日志格式。没有统一格式日志系统就是垃圾场。我强烈建议至少包含以下字段时间、级别、线程名、类名、方法名、traceId、业务关键字段、消息正文。时间格式统一用ISO8601比如2025-01-12T10:30:00.12308:00一是国际化团队看起来一致二是Elasticsearch这类搜索引擎对ISO8601有原生支持按时间范围检索和聚合都非常方便。第六条建议打印日志时使用参数化方式而不是字符串拼接。比如你写logger.info(orderId orderId , userId userId)这个字符串拼接在你构造日志消息那一刻就执行了哪怕日志级别过滤掉这条消息拼接的代价也已经发生。而logger.info(orderId{}, userId{}, orderId, userId)这种参数化写法框架会先判断当前级别是否需要输出不需要就直接跳过省下来的性能在高并发场景下非常可观。4. 建议细则二上下文、链路追踪与性能优化建议7-114.1 建议7-8traceId贯穿全链路用户上下文用MDC第七条建议全链路要有一个traceId贯穿始终。大厂排查问题很少去看单条日志都是拿traceId把一次请求经过的所有服务、所有日志拉出来按时间排序复盘。实现上非常简单在网关或拦截器里生成一个UUID放入ThreadLocal或在日志框架的MDC里日志格式里带上traceId请求结束再清理。配合Logback自带的MDC功能你只需要在pattern里写%X{traceId}剩下的交给框架处理。第八条建议在合适的位置记录用户上下文。除了traceId我习惯把当前登录用户ID、操作来源、请求IP放到MDC里让每一条日志自动带上“谁在什么环境做了什么操作”的底衬。这样做的好处是审计和客服排查都特别方便你不必在业务代码里反复传userId。注意点也很简单MDC一定要记得在请求结束或线程归还线程池之前清理否则线程复用时上下文串了排查问题反而会南辕北辙。4.2 建议9-10循环内禁止打日志异步日志要配置好第九条建议循环里禁止打日志尤其是批量处理、大数据扫描这类场景。我曾经在某个批处理任务里写了一条logger.info进循环数据量两百万直接让接口响应时间翻了一倍。真要排查循环内的异常可以在特定次数时采样打印比如每1000条打一次进度异常时单独收集上下文再打。第十条建议日志打印不要阻塞业务线程采用异步方案。成熟的日志框架都支持异步输出Logback的AsyncAppender、Log4j2的AsyncLogger都是标配。异步的核心逻辑是业务线程把日志事件丢进内存队列后台线程负责写盘或发送到日志采集端。需要提醒的是用了异步不等于万事大吉队列满的时候策略要提前想好是丢弃还是阻塞建议选丢弃并配合告警最低限度保证业务线程不受日志拖累。4.3 建议11避免无意义的对象序列化与开销第十一条建议特别容易被忽略有些参数对象本身序列化代价很高打印日志时不加思考直接toString或JSON序列化性能会被悄悄拖垮。比如一个带有大字段、byte数组、嵌套集合的对象序列化一次可能耗时几毫秒在热点路径上连续打印几次积少成多就非常可观。我的习惯是给日志单独定义一个精简的DTO只放关键字段或者自定义日志转换方法在参数化日志里只打印业务需要的字段。宁可多写一点代码也别让日志成为系统瓶颈。5. 建议细则三安全脱敏、存储轮转与监控治理建议12-155.1 建议12-13敏感信息必须脱敏日志轮转和保留要提前规划第十二条建议日志里不能出现密码、Token、验证码、身份证、手机号、银行卡号这些敏感信息。这个问题不只是合规问题更是事故放大问题。我之前做过一次日志治理从旧日志里翻出来一堆明文密码吓出一身冷汗。脱敏的方式有很多打印前统一走一个脱敏工具类手机号只保留前3后4接口返回值过一层敏感字段过滤器。如果做不到完全避免至少在日志框架层面加一个全局的Key过滤把password、token、secret这些字段值替换成***。第十三条建议日志文件的轮转和保留策略要提前规划好。生产环境不可能把日志无限堆在磁盘上。我常用的方案是按大小加时间双轮转单个文件超过100MB就切分最多保留7天或固定数量。容器场景里还要注意日志驱动和Docker底层的输出限制这个我在下一章单独展开。5.2 建议14-15ERROR日志必须配告警日志治理要定期做第十四条建议ERROR级别的日志必须和监控告警联动。日志打出来的意义是被人看到“打到文件里没人看”等于没打。大厂的通用做法是日志采集端把ERROR日志实时汇入监控系统设置告警规则比如“某接口5分钟ERROR超过10次”就触发钉钉通知。这套机制能让你在用户反馈之前先发现问题是日志价值最大化的体现。第十五条建议定时做日志治理干掉无效日志。项目迭代半年之后总有大量“看起来有用其实没人看”的日志留着占存储、干扰检索。我一般每个迭代做一次日志评审搜索低频使用的日志关键字和开发确认后删除把重复打两次的地方合并把级别明显不对的修正过来。顺手看一下日志存储增长趋势提前扩容或调整保留天数。日志治理做得好日志系统才能一直保持“可用”状态。6. 实操落地VS调试日志与Docker容器日志的两种常见场景6.1 VS里让调试信息“同时写文件 打印显示”开发阶段很多人习惯在Visual Studio里靠调试输出窗口看日志但调试窗口的内容一关就没不好回顾。这里分享一下让调试信息既在输出窗口显示、又能保存到日志文档的做法。原理是通过TraceListener把Trace输出同时送到默认监听器和文本文件监听器写起来很轻量using System.Diagnostics; // 在应用入口初始化一次 Trace.Listeners.Add(new ConsoleTraceListener()); Trace.Listeners.Add(new TextWriterTraceListener(debug.log, fileListener)); Trace.AutoFlush true; Trace.WriteLine($用户登录成功, userId{userId}, timestamp{DateTime.Now:o});这样设置之后你在调试时用Trace.WriteLine打印的信息会同时出现在VS的“输出”窗口和debug.log文件里。如果只想在调试模式下生效可以包一层#if DEBUG。我自己的习惯是调试阶段保留详细输出构建Release时把Trace开关关掉避免把调试信息带上线。6.2 Docker场景应用日志写到标准输出docker logs统一查看如果你用Docker部署应用容器日志最佳实践是把日志写到标准输出stdout/stderr然后靠docker logs或日志采集组件统一处理。这样做的好处是所有容器日志的查看方式一致配合docker-compose或Kubernetes时日志采集不需要关心容器内文件路径。启动容器时我们可以通过--log-opt控制日志轮转避免docker日志文件无限膨胀docker run -d --name myapp \ --log-driver json-file \ --log-opt max-size10m \ --log-opt max-file3 \ myapp:latest这条命令的关键是max-size10m表示单个日志文件达到10MB就轮转max-file3表示最多保留3个文件。不加这些参数json-file驱动默认会把日志写成一个无限增长的文件时间一长直接把磁盘撑满。个人建议无论应用本身怎么落盘日志Docker层这个限制一定要加算是给磁盘上双保险。6.3 从开发到线上的日志方案衔接开发环境用调试窗口和本地文件测试环境用容器标准输出生产环境再加一套日志采集分析平台比如ELK或者云厂商的日志服务。这三层不是割裂的而是靠统一格式衔接起来的只要开发阶段就统一了时间格式、traceId、业务关键字段从docker logs到日志平台检索你的排查经验就能无缝迁移。我见过不少项目开发时一套格式上线后又换一套结果开发环境和生产环境互相对不上排查问题等于两套体系同时猜。7. 高频踩坑记录与排查思路速查7.1 日志问题速查表现象最常见原因解决思路日志文件暴涨循环内打印或级别太粗检查日志级别循环内采样打印配置轮转日志时间对不上时间格式不统一、时区问题统一ISO8601带时区日志框架里设置zoneId看不到异常堆栈catch里只打message参数化日志里至少带e.getMessage()和堆栈多服务日志连不起来没有traceId或traceId没透传在网关生成traceId服务间通过Header传递日志里有敏感信息字段未做脱敏统一脱敏工具类日志框架层面做字段过滤异步日志丢数据队列满了且策略是丢弃接受丢弃策略配合告警或适当增大队列7.2 日志打印本身成为新事故的三种场景第一种是循环里打日志这个前面说过了两百万条数据能打掉你一半的性能第二种是把大对象直接toString进日志序列化开销严重第三种是MDC没清理线程池复用时A用户请求的日志打到了B用户的上下文里这在中大型系统里非常隐蔽排查起来又很费劲。说白了一句话日志代码也是代码要像对待业务代码一样考虑它的性能和生命周期。7.3 我自己现在执行的一套日志检查清单最后分享一套我在代码评审时常用的日志检查清单不一定适合所有团队但可以参考每增加一个接口必查入口出口是否有日志每增加一个catch块必查是否打印了完整堆栈和上下文每写一道循环先问自己循环里有没有日志每次打印对象先问自己哪些字段能不打每次改动日志级别先问自己告警规则跟不跟得上。这些习惯坚持下来比记住多少条理论都管用。全文围绕“日志打印”四个字展开的所有建议说到底都是在回答一个问题当系统出问题时日志能不能在最短时间内帮你还原现场。你能把这件事做好就已经比大多数团队靠谱了。这算是我这几年写日志最真实的一点体会。