异常消息须含可定位上下文，如“timeoutMs must be positive, but got: -1”；禁用模糊词、敏感数据、堆栈拼接及处理逻辑；自定义异常需重写getMessage()并提供带参构造；日志须用log.error(msg, e)格式；消息长度应≤256字符。
异常信息必须包含「可定位的上下文」而非仅描述错误类型
Java中抛出IllegalArgumentException却只写"Invalid parameter"，等于没说——调用方完全无法判断是哪个参数、在哪个方法、传了什么值出的问题。真正有用的异常消息要能直接对应到代码现场。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 始终包含「关键变量名 + 当前值 + 期望条件」，例如：
"timeoutMs must be positive, but got: " + timeoutMs - 避免模糊动词如“invalid”“wrong”“bad”，改用具体约束词："
must be non-null"、"must not exceed 1024 characters"、"must be in ISO_LOCAL_DATE format" - 如果涉及多个参数，用逗号分隔并明确归属：
"startTimestamp (" + start + ") must be before endTimestamp (" + end + ")"
不要在异常消息里拼接敏感数据或堆栈逻辑
把用户密码、token、数据库连接串、完整SQL语句塞进getMessage()，轻则泄露信息，重则被日志系统持久化后引发安全审计失败。更隐蔽的问题是：有些框架（如Spring Boot Actuator）会默认暴露异常消息到HTTP响应体中。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 禁止出现
password、authToken、jdbcUrl等字段的实际值；可用占位符代替："Failed to connect to database (redacted url)" - 不把
e.toString()或e.getStackTrace()手动拼进消息——异常本身已有完整堆栈，重复拼接只会让日志冗余且难以解析 - 避免在消息中写处理逻辑，例如
"Retrying with fallback..."——这是代码行为，不是错误事实
自定义异常类必须重写getMessage()且避免空参构造
继承RuntimeException却只提供无参构造函数，等于放弃对消息内容的控制权。JVM默认的getMessage()返回null或空字符串，下游捕获后根本无法做有意义的判断或日志分级。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每个自定义异常类至少提供两个构造函数：
MyBusinessException(String message)和MyBusinessException(String message, Throwable cause) - 禁止在构造函数里调用可能抛异常的方法（如格式化日期、IO操作），否则可能触发二次异常掩盖原问题
- 若需动态生成消息，确保参数已校验且非null，例如：
public OrderNotFoundException(Long orderId) { super("Order not found with id: " + Objects.requireNonNull(orderId, "orderId must not be null")); }
日志记录异常时，log.error(msg, e)比log.error(msg + e.getMessage())更可靠
很多开发者习惯把异常消息手动拼进日志字符串，结果遇到e.getMessage()为null时，日志变成"Failed to process: null"，丢失全部线索。Logback/Log4j等主流日志框架的error(String, Throwable)重载方法，会自动提取堆栈并保证结构化输出。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远优先使用带
Throwable参数的日志方法：log.error("Failed to parse config file", e) - 如果必须补充上下文，用占位符而非字符串拼接：
log.error("Failed to send notification to user {}", userId, e) - 避免在
catch块里吞掉异常又不记录——哪怕只是log.debug("Ignored", e)也要保留堆栈
