空catch块会切断异常链，导致日志缺失堆栈、异常类型和业务上下文；正确做法是捕获具体异常类型，记录带描述性消息、关键参数和异常对象的完整日志。
空catch块会直接切断异常链，让日志失去关键诊断信息：没有堆栈、没有异常类型、没有业务上下文，运维查不到时间点、类名和行号，监控系统也收不到错误信号。
空catch块彻底抹掉可追溯性
catch (Exception e) { } 这类写法不是“兜底”，而是主动销毁线索。异常对象e未被传递给日志框架，堆栈信息完全丢失；日志里既看不到orderId、reqId等上下文，也查不到是哪一行代码触发了SQLException还是JsonProcessingException。结果就是——用户反馈“提交没反应”，你翻遍日志却找不到对应记录。
日志必须带全三要素才能回溯
每条错误日志要同时满足：
- 有意义的描述性消息，比如“支付回调验签失败”，而不是“处理出错”
- 关键业务参数用占位符传入，如orderId={}、userId={}，避免字符串拼接
- 异常对象e作为最后一个参数传入，确保日志框架自动输出完整堆栈和cause链
正确写法示例：
logger.error("订单支付回调验签失败, orderId={}, reqId={}", orderId, reqId, e);
立即学习“Java免费学习笔记（深入）”；
捕获类型越具体，日志定位越精准
用catch (Exception e)会把FileNotFoundException、TimeoutException、DataAccessException全混在一起记录，无法区分是配置缺失、网络超时还是数据库慢查询。应按实际风险点分层捕获：
- 文件操作只捕获IOException或其子类
- 数据库访问捕获SQLException或DataAccessException
- JSON解析捕获JsonProcessingException
不同异常类型对应不同日志模板和后续动作，比如超时可重试，文件不存在则走默认逻辑。
忽略异常的极少数场景仍需留痕
即使确认某异常可忽略（如FileNotFoundException表示配置文件未提供），也必须：
- 捕获具体类型，禁用catch (Exception e)
- 加注释说明原因，例如// 忽略：配置文件不存在属于预期行为，使用默认值
- 至少用logger.debug("配置文件未找到，启用默认配置", e)记录，保留审计依据
