生产环境禁止e.printStackTrace()，须用SLF4J记录带业务标识的日志；禁用空catch；受检异常仅用于调用方必须恢复的场景；finally中避免抛异常，优先用try-with-resources；异常信息需含可行动上下文并脱敏敏感数据。
避免在 catch 块里只写 e.printStackTrace()
这是最常见也最危险的习惯——它把异常信息输出到标准错误流，既没记录上下文，也没触发监控，线上出问题时根本没法定位。生产环境必须用日志框架（如 SLF4J）记录，并带上关键业务标识。
- 用
logger.error("订单支付失败，orderNo={}", orderNo, e)，而非e.printStackTrace() - 不要吞掉异常：空
catch块或只打日志不抛出/不处理，等于掩盖故障 - 若决定忽略某类异常（如
InterruptedException在清理线程时），必须加明确注释说明“为什么可忽略”
区分 RuntimeException 和受检异常的使用场景
Java 强制你处理受检异常（Exception 及其子类，但不包括 RuntimeException），但这不意味着“所有异常都该是受检的”。滥用受检异常会导致大量无意义的 throws 声明和模板式 try-catch，反而降低可读性。
- 受检异常适合：调用方**必须决策如何恢复**的场景，比如
IOException（文件不存在？重试？降级？） -
RuntimeException更适合：程序逻辑错误或不可恢复的意外，如IllegalArgumentException、NullPointerException（应提前校验，而非靠 catch） - 自定义异常优先继承
RuntimeException，除非你有强契约要求调用方显式处理
不要在 finally 里执行可能抛异常的操作
finally 的本意是保证资源释放，但如果里面又抛出新异常，会覆盖原始异常，导致根因丢失——这是调试时最让人抓狂的问题之一。
- 关闭资源用
try-with-resources，它自动抑制（suppressed）后续异常，保留主异常 - 如果必须手写
finally（如老 JDK），对每个 close 操作单独 try-catch，并记录而非抛出 - 示例错误写法：
finally { outputStream.close(); }——close()可能抛IOException，覆盖前面的业务异常
异常信息要包含“可行动”的上下文，而非仅堆栈
堆栈告诉你“哪里出错了”，但运维和下游服务需要知道“什么条件下错的”。比如 "HTTP 500 from payment gateway" 远不如 "Payment gateway timeout after 30s, requestID=abc123, amount=¥299.00" 有用。
立即学习“Java免费学习笔记（深入）”；
- 构造异常时传入组合字符串，而非拼接后丢给
getMessage() - 避免泛化消息如
"操作失败"，换成"无法更新用户邮箱：邮箱已被其他账号占用（email=john@example.com）" - 敏感信息（密码、token、身份证号）必须脱敏，日志中禁止明文出现
