用户看到的异常信息不应是NullPointerException等技术堆栈，而应是绑定业务动作的可操作提示；需用消息码（如"user.login.username.required"）配合ResourceBundle实现国际化与可维护性；后端抛自定义异常并记录完整堆栈，前端仅展示业务级提示且过滤敏感字段。
用户看到的异常信息不该是 NullPointerException 堆栈
直接把 Java 异常类名、toString() 结果或完整堆栈抛给前端或终端用户，等于把开发调试日志当 UI 文案用。用户不关心 Caused by: java.lang.NullPointerException，只关心“为什么提交失败”“哪填错了”“现在该做什么”。真正的友好提示必须脱离技术细节，绑定具体业务动作和可操作反馈。
用 ResourceBundle 或配置化消息码替代硬编码字符串
避免在 catch 块里写 "用户名不能为空" 这类字符串——它无法国际化、难维护、改文案要发版。推荐用消息码（如 "user.login.username.required"）配合 ResourceBundle 或 Spring 的 MessageSource。
-
后端抛出带码的自定义异常，例如
BusinessException.of("order.payment.timeout", "2025-08-15") - 消息配置文件（如
messages_zh_CN.properties）中定义：order.payment.timeout=订单支付已超时，请重新下单（有效期至 {0}） - 前端或接口层通过统一拦截器查码渲染，{0} 由后端传入的参数自动填充
不要在 catch 里吞掉原始异常
对用户友好 ≠ 对开发者隐藏问题。常见错误是这样写：
try {
processOrder(order);
} catch (Exception e) {
log.error("下单失败", e); // ✅ 记日志
return Result.fail("操作失败，请稍后重试"); // ❌ 丢原始异常上下文
}
正确做法是保留原始异常用于排查，同时返回业务级提示：
- 记录完整
e（含堆栈），至少打到 ERROR 级别 - 返回的错误码和提示语走业务消息体系，不暴露
e.getMessage() - 必要时在日志中附加关键业务字段，如
log.error("下单失败 orderId={}, userId={}", order.getId(), user.getId(), e)
前端展示前需过滤敏感字段，后端绝不传 exception.stacktrace
哪怕做了消息码映射，也要防住“意外泄露”。检查所有对外 API 响应体：
- 禁止响应字段包含
stackTrace、cause、
suppressed等原生异常属性 - 序列化框架（如 Jackson）加全局配置：
@JsonIgnoreProperties({"stackTrace", "cause", "suppressed"})到基础异常类 - 网关或统一异常处理器中，用
instanceof拦截未处理的Throwable，强制转为通用错误码（如"system.error.unknow"）
最常被忽略的是：开发环境开启 spring.mvc.throw-exception-if-no-handler-found=true 后，404 会抛 NoHandlerFoundException，若没被全局捕获，可能把整个异常对象序列化出去——务必在测试阶段用非法路径压测接口响应体。
