合理规划日志级别
开发系统时，很多人一开始就把所有信息都打成 DEBUG 级别，等线上出问题翻日志才发现关键信息被淹没了。其实应该根据场景选择合适的日志级别：ERROR 用于异常中断，WARN 表示潜在问题但不影响运行，INFO 记录重要业务动作，DEBUG 留给排查细节用。比如用户登录失败可以记为 WARN，而数据库连接超时就得上 ERROR。
结构化日志更易处理
传统文本日志看着直观，但机器难解析。换成 JSON 格式的结构化日志，字段清晰，方便后续用 ELK 或其他工具分析。例如记录一次支付请求：
{"timestamp": "2025-04-05T10:30:22Z", "level": "INFO", "action": "payment_initiated", "user_id": 12345, "amount": 99.9, "currency": "CNY"}这样的格式查起来快，聚合统计也省事。
避免记录敏感信息
有次同事在日志里直接打印了用户密码，还好是测试环境发现得早。身份证号、手机号、密码、密钥这类数据绝对不能进日志。如果必须记录，至少做脱敏处理。比如手机号可以写成 138****1234，银行卡号只留后四位。
控制日志输出频率
某个循环里每处理一条数据就写一行日志，结果一天生成上百 GB 日志文件，磁盘爆了都不知道为啥。高频操作建议采样打印，或者只在出错时输出关键上下文。比如每处理 1000 条记录才打一次 INFO，异常时再补充详细信息。
统一日志格式与命名规范
团队里每人一套日志风格，有人喜欢英文，有人全中文，查问题时特别费劲。最好提前约定好通用字段，比如时间戳用 ISO8601 格式，服务名统一小写加中划线，trace_id 用来串联调用链。这样运维和开发都能快速定位。
配置独立的日志存储与轮转策略
别把日志和应用跑在同一块磁盘上。一旦日志暴涨，主服务可能因为磁盘满而崩溃。使用 logrotate 设置每日切割，保留最近7天的归档，并压缩旧文件。同时把重要日志同步到远程日志服务器或云存储，防止本地丢失。
结合上下文提供可追溯信息
单纯记录“订单创建失败”意义不大。加上 request_id、用户ID、IP地址、设备类型这些上下文，排查时才能还原现场。特别是在微服务架构下，一个请求经过多个服务，靠 trace_id 把各环节日志串起来，能大大缩短定位时间。
定期审查和优化日志策略
上线三个月后回头看看哪些日志根本没人看，哪些报错频繁出现却没被监控。删掉冗余输出，把常出问题的地方增强日志覆盖。就像家里整理衣柜，定期清理才能保持高效。