主流日志库选型与核心配置技巧
选对日志库是做好日志分级的第一步。Go生态里日志库五花八门，但真正经得起生产环境考验的其实就那几个。我用过最顺手的是zap和logrus，各有各的优势，你可以根据项目情况选。
先说说zap，这是Uber开源的库，最大的特点就是“快”。我之前在一个电商项目里试过，同样是每秒写10万条日志，用logrus的时候日志写入会阻塞业务线程，换成zap之后几乎感觉不到延迟。它的设计理念就是“零分配”，尽量减少内存开销，特别适合高并发场景。不过zap的API稍微有点“重”，刚开始用可能觉得不如logrus直观，但习惯了之后会发现它的结构化日志设计非常清晰。
配置zap的时候，有几个点你一定要注意。首先是日志级别初始化，开发环境和生产环境必须分开。我见过有团队图省事，线上环境居然开着Debug级别，结果日志量比业务数据还大，把磁盘都写满了。正确的做法是通过环境变量控制，比如在配置文件里加个LOG_LEVEL字段，开发环境设成Debug，生产环境默认Info，出问题时临时改成Warn或Error。其次是输出格式，开发时用zap.NewDevelopment()生成的文本格式，带颜色、换行，看起来舒服；生产环境一定要用zap.NewProduction()的JSON格式，方便ELK这些日志系统解析，你想想，线上出问题了，用Kibana搜关键词总比翻文本文件快吧？
再说说logrus，它的优势是“灵活”。如果你需要把日志同时输出到文件、控制台、甚至发送到消息队列，logrus的钩子（Hook）机制特别好用。我之前帮一个朋友的项目做日志改造，他们需要把Error日志实时推到企业微信告警群，用logrus的Hook不到20行代码就实现了——当日志级别是Error时，自动触发钩子函数，调用企业微信API发消息。不过logrus有个小缺点，性能比zap稍弱，如果你项目并发量不是特别高（比如每秒日志量小于1万条），用它完全没问题，开发效率反而更高。
配置logrus的时候，除了和zap一样要区分环境级别，还要注意字段扩展。比如每个请求的traceID、用户ID，这些上下文信息一定要跟着日志打出来。我之前排查一个用户支付失败的问题，日志里只写了“支付失败”，没有用户ID和订单号，最后只能去数据库一条条查，折腾了两个小时。后来在logrus里加了WithFields方法，把关键信息都带上，再出问题直接搜traceID，一分钟就定位到了原因。
可能你会问，那到底选zap还是logrus？我 了一个简单的判断标准：如果你的服务是高并发核心业务（比如交易、直播），优先选zap；如果需要灵活的日志分发（比如多端输出、自定义告警），或者团队更熟悉简单API，logrus更合适。 不管选哪个，核心都是把“分级”这个基础打牢。
日志分级策略与避坑指南
选好库之后，最重要的就是搞清楚“什么时候该用什么级别”。很多人日志分级做不好，不是技术问题，而是策略问题——要么“一刀切”全用Info，要么随便打Error，最后日志系统变成“鸡肋”。
先明确四个常用级别的定位：Debug、Info、Warn、Error。别小看这四个词，用对了能让你的日志“会说话”，用错了还不如不分级。我整理了一个表格，你可以对着看看自己平时有没有用对：
| 日志级别 | 核心作用 | 适用场景 | 环境 |
|---|---|---|---|
| Debug | 开发调试 | 变量值、函数调用栈、临时调试信息 | 仅本地/测试环境开启 |
| Info | 业务流程记录 | 用户请求开始/结束、任务执行成功 | 所有环境开启，控制频率（如每秒不超过10条） |
| Warn | 异常但不影响主流程 | 缓存失效、重试成功、非核心依赖超时 | 所有环境开启，可用于监控预警 |
| Error | 功能失败需关注 | 支付失败、数据库写入错误、核心API调用失败 | 所有环境开启，必须触发告警 |
（表：Go日志分级核心场景对比， 保存到你的开发手册里）
光知道级别定义还不够，实际用的时候很容易踩坑。最常见的就是Error级别滥用，我之前接手一个项目，代码里到处都是log.Error("xxx")，连用户输入格式错误这种问题都打Error，结果监控告警每天响200多次，真正的“支付回调失败”这种严重错误反而被忽略了。后来我们定了个规矩：只有“当前功能不可用”才用Error，比如订单创建失败、退款接口超时；像用户输错手机号这种“用户行为异常”，最多打Warn，然后在Info里记录详细上下文。改完之后，告警数量降到每天不到10次，团队对真正的错误响应速度快了好几倍。
另一个坑是“上下文缺失”。你可能觉得“这个日志信息已经很清楚了”，但实际排查问题时，少一个traceID或者用户ID，就可能让你多花几小时。我记得有次线上出了个“偶发500错误”，日志里写“数据库查询失败”，但没带用户ID和SQL语句，只能去查慢查询日志，又去翻代码，最后发现是某个用户的特殊字符导致SQL注入拦截——如果日志里带上用户ID和SQL，5分钟就能定位。所以不管用哪个库，打日志时一定要问自己：“如果我是三天后的自己，看到这条日志，能还原当时的场景吗？”
还有个细节是日志轮转配置，这个虽然不直接算“分级”，但和分级效果息息相关。我见过最夸张的一次，有个团队日志没配轮转，一个月下来单个日志文件100多G，服务器磁盘直接占满，服务挂了。正确的做法是按“大小+时间”双维度切割：比如单个文件最大100MB，保留最近7天的日志，超过自动删除。zap可以用lumberjack库实现，logrus直接调rotatelogs包，配置起来都不复杂，花5分钟配好，能避免很多运维麻烦。
最后想跟你分享一个小技巧：定期“审计”日志。每周花10分钟看看生产日志，检查有没有不该出现的Debug日志，Error级别是不是真的需要告警，Info日志是不是太频繁。我之前就是通过审计发现，有个定时任务每30秒执行一次，每次都打3条Info日志，一天下来就是1000多条无用日志，优化之后不仅磁盘占用少了，日志查询速度也快了不少。
按照这些方法把你的日志系统搭起来，下次线上出问题，你会发现排查效率至少提升一倍。比如现在让你找昨天下午3点用户A的支付失败原因，你只需要打开日志系统，搜用户A的ID+Error级别，30秒就能看到详细的错误堆栈和上下文——这才是日志分级真正的价值：让日志从“杂乱的记事本”变成“精准的故障导航仪”。如果你已经开始动手优化了，或者遇到了其他问题，欢迎在评论区告诉我你的进展，咱们一起把日志这个“开发必备技能”练得更扎实。
选zap还是logrus，其实主要看你的项目场景，我给你举两个实际例子你就明白了。要是你做的是高并发核心业务，比如电商的交易系统、直播平台的弹幕服务，那我更推荐你用zap。我之前在一个秒杀项目里试过，当时系统每秒要处理3万多订单，日志量跟着飙升到每秒10万+条，最开始用的logrus，结果日志写入居然开始阻塞下单流程，用户付款时偶尔会卡住1-2秒。后来换成zap，同样的日志量，业务线程几乎没受影响，后台看监控，日志写入延迟从几百毫秒降到了个位数——这就是zap“零分配”设计的好处，尽量少用内存，写日志跟业务线程几乎不抢资源，高并发下优势特别明显。
要是你的项目没那么高的并发，或者需要折腾各种日志分发，那logrus可能更顺手。比如你想把普通日志写文件，Error日志实时推到企业微信告警群，甚至还要存一份到Elasticsearch，logrus的钩子（Hook）机制简直是为这个场景量身定做的。我去年帮朋友的项目搭日志系统，他们需要当出现Error日志时，自动@技术负责人，用logrus的Hook写了不到20行代码就搞定了：先定义一个Hook结构体，实现Fire和Levels方法，Levels里指定只处理Error级别，Fire方法里调用企业微信API发消息，跑起来之后告警又快又准。而且logrus的API设计更像“原生日志”，上手简单，中小项目或者内部管理系统用它，开发效率能高不少——你想啊，要是做个员工打卡系统，每天日志量撑死几千条，用zap反而显得“杀鸡用牛刀”，logrus几行代码就能配好，多省事儿。
另外还有个小细节你可以参考：要是你们团队新人多，或者代码风格偏简单直接，logrus的“开箱即用”更友好，比如logrus.WithFields(logrus.Fields{"user_id": 123}).Info("登录成功")，一看就知道啥意思；zap虽然性能好，但初始化配置稍微麻烦点，得定义encoder、writeSyncer这些，刚开始用可能会觉得“有点重”。不过习惯之后你会发现，zap的结构化日志设计其实更规范，每个字段该放什么、怎么命名，都帮你捋得清清楚楚，后期维护反而省心。所以 高并发核心业务优先zap，灵活分发或中小项目选logrus，准没错。
开发环境和生产环境的日志级别应该怎么设置？
通过环境变量（如LOG_LEVEL）动态控制：开发环境优先设为Debug，方便查看详细调试信息（比如变量值、函数调用栈）；生产环境默认用Info，仅记录关键业务流程（如用户请求、任务执行结果），出问题时可临时改为Warn或Error减少日志量。避免线上开Debug级，否则可能因日志过多占满磁盘或影响性能。
zap和logrus怎么选？哪个更适合我的项目？
高并发核心业务（如交易、直播）优先选zap，它的“零分配”设计能减少内存开销，实测每秒10万+日志场景下性能优势明显；若需要灵活的日志分发（如同时输出到文件、企业微信告警），或团队更习惯简单API，logrus的钩子（Hook）机制更方便，比如用20行代码就能实现Error日志推送到告警群。中小项目或非高并发场景，logrus开发效率更高。
为什么生产环境推荐用JSON格式的结构化日志？
JSON格式日志包含明确的键值对（如”level”:”error”,”trace_id”:”xxx”,”message”:”支付失败”），方便ELK、Kibana等日志系统解析和搜索。比如线上排查问题时，直接用trace_id或user_id在Kibana筛选，1分钟就能定位异常上下文；而文本格式日志需手动 grep，效率低且易漏关键信息。生产环境用JSON，开发环境用带颜色的文本格式，兼顾效率和可读性。
日志轮转怎么配置？需要注意哪些参数？
推荐按“大小+时间”双维度切割：单个文件最大100MB（避免过大难解析），保留最近7天日志（节省磁盘空间）。zap可搭配lumberjack库，配置MaxSize: 100（MB）、MaxAge: 7（天）；logrus用rotatelogs包，设置WithMaxAge(724time.Hour)和WithRotationSize(10010241024)（100MB）。关键是避免不配置轮转，曾见过项目因日志文件达100G导致磁盘占满、服务宕机，5分钟配好轮转能省很多运维麻烦。
Error和Warn级别怎么区分？什么情况该用哪个？
核心区别在“是否影响主流程”：Error仅用于“当前功能不可用”的场景，比如订单创建失败、支付回调超时、数据库写入错误，必须触发告警；Warn用于“异常但不阻断主流程”的场景，比如缓存失效（可降级查数据库）、重试后成功的接口调用、用户输入格式错误，这类日志可记录但无需实时告警。避免把“用户输错手机号”这种问题打Error，曾有项目 导致日均200+无效告警，优化后真正的错误响应速度提升3倍。
