日志这东西，平时安安静静躺在那儿，一旦系统出故障，它就成了救命稻草。怎么用好Java日志来定位问题？这活儿看似简单，但真要干得漂亮，里面门道不少。下面这几条，是经过多次实战检验的硬功夫。
1. 选择合适的日志框架
别在日志框架上凑合。Log4j、Logback、SLF4J——这几个都是久经考验的选手。它们不光配置灵活，还能精细控制日志级别，出问题的时候，该看的细节一个不落，不该看的也不会刷屏。
2. 配置日志级别
日志级别不是摆设，得根据场景来调。常见的有：
- DEBUG：最细粒度的调试信息，开发环境随便用。
- INFO：关键操作和状态，比如“订单已创建”。
- WARN：潜在问题提醒，比如“磁盘空间不足”。
- ERROR：真的出错了。
- FATAL：严重错误，系统可能扛不住了。
生产环境里，一般开到INFO或WARN就行。级别太低，日志量太大，性能会受影响；级别太高，又容易遗漏关键线索。
3. 记录关键信息
日志不是记流水账，得打在要害上。哪些地方值得记？方法入口和出口、重要的业务逻辑节点、异常处理块、数据库操作、网络请求——这些地方出了问题，往往就是故障的根源。
4. 使用结构化日志
纯文本日志看着方便，但分析起来头疼。用JSON格式的结构化日志，配合Logstash或Fluentd这类工具，解析、查询、搜索都轻松不少。比如“按用户ID查所有日志”，在结构化日志里就是一行命令的事。
5. 日志聚合和分析
单机日志好办，但微服务、分布式系统下，日志散落各处，光靠手动翻文件可不行。ELK Stack、Splunk这类工具就是干这个的——集中收集、统一搜索、快速定位。比如搜一下“ERROR”再加上“请求超时”，几秒钟就能锁定问题范围。
6. 日志轮转和归档
日志会一直写，不轮转的话，磁盘迟早爆掉。按大小、按时间、按级别——选一种策略，配置好轮转和归档。这样既保留了历史记录，又不会把磁盘撑满。
7. 异常堆栈跟踪
捕获异常时，别只打个“出错了”，堆栈跟踪才是关键。把完整的异常信息记下来，哪个类、哪一行、什么原因——一目了然。
try {
// 业务逻辑
} catch (Exception e) {
logger.error("An error occurred: ", e);
}8. 使用MDC（Mapped Diagnostic Context）
分布式系统里，一个请求可能经过多个服务。MDC能在日志里注入上下文信息，比如用户ID、请求ID。这样，一个请求从开始到结束的所有日志，都能串成一条线。
MDC.put("userId", "12345");
logger.info("Processing request");
MDC.remove("userId");9. 日志监控和告警
日志不能只等着出事了再查，得主动监控。当日志里出现ERROR或FATAL时，触发告警通知，让相关人员第一时间知道。ELK Stack的告警功能、或者第三方监控工具，都能派上用场。
10. 定期审查日志
最后一条，定期翻翻日志，哪怕系统没出问题。日志里藏着系统的健康状况——慢查询、频繁的WARN、异常增长——这些早期信号，比事后救火管用得多。
把上面这些做到位，Java日志就不再只是事后诸葛亮，而是故障定位的利器。系统稳定可靠，靠的不光是代码写得对，还得靠日志看得清。
