别让错误悄悄溜走
你有没有遇到过这种情况：系统突然卡住，用户投诉不断，可翻遍日志却只看到一行冷冰冰的“Error occurred”？这种模糊的日志就像报警器响了却不告诉你哪里着火，干着急没用。
日志记录中的错误处理，不是简单地把异常打出来就完事。它得说清楚谁、在哪儿、什么时候、因为什么、导致了什么后果。否则，等真出问题时，你就是在靠猜排查故障。
记录错误时别偷懒
很多开发者习惯写这样的代码：
try {
doSomething();
} catch (Exception e) {
log.error("出错了");
}这等于在事故现场只留下一张写着“有人摔倒”的纸条。你应该把异常对象本身也打出来，让堆栈信息暴露路径：
log.error("文件上传失败，用户ID：" + userId, e);这样你才能一眼看出是网络超时、权限不足，还是磁盘满了。
带上上下文，别光记错误本身
光有堆栈还不够。比如一个支付失败的日志，除了异常，最好带上订单号、用户ID、请求金额、调用的第三方服务名称。这些信息能帮你快速定位是某个用户特有问题，还是全局性故障。
想象你在查凌晨三点的告警，如果日志里写着“订单 20240405-8891 支付失败，原因：调用微信统一下单接口超时（已重试3次）”，那你直接就能去找网络或第三方的问题，而不是从头梳理整个流程。
别把敏感信息也记进去
加了上下文是好事，但别一不小心把密码、身份证号、令牌全打到日志里。曾经有团队把完整请求体写进日志，结果泄露了上千用户的手机号。可以在记录前做脱敏处理：
String safePhone = phone.replaceAll("(\d{3})\d{4}(\d{4})", "$1****$2");
log.warn("短信发送失败，手机号：" + safePhone);既保留了排查线索，又不越界。
错误分级要明确
不是所有错误都值得半夜打电话叫醒人。该用 warn 还是 error 得分清。比如用户输错密码一次，打个 info 或 warn 就够了；但如果连续十个用户在同一分钟内都连不上数据库，那就得标成 error 并触发告警。
有些团队用日志级别来区分影响范围：info 记操作流水，warn 记可恢复异常，error 记系统级故障。统一标准后，排查时过滤起来也快。
定期看日志，别等出事才翻
再好的日志，没人看也是摆设。建议每周抽点时间扫一眼 warn 和 error 级别的记录。可能你会发现某个接口每天都有几条超时，一直没被注意。早点优化，能避免它某天突然变成大面积故障。
日志不是记给机器看的，是记给人用的。你写的每一条错误日志，都是在给未来的自己留线索。别图省事，别藏关键信息，让错误老老实实暴露出来，排查时才能少走弯路。