应使用businessexception封装业务语义，统一异常处理、消息码管理、参数化文案及前端兜底机制，确保错误提示可运营、可维护、安全可控。
用 BusinessException 封装业务语义，别直接 throw RuntimeException
用户看到“NullPointerException”和“java.lang.IllegalArgumentException: userId is null”，等于在读你的调试日志。真正该抛的，是带业务码的自定义异常——它不暴露技术路径，只说清“谁在哪干了什么出了什么问题”。
- 错误做法：
throw new RuntimeException("用户名为空")——硬编码、不可翻译、改文案要发版 - 正确做法：
throw BusinessException.of("user.login.username.required").withParam("field", "username") - 消息码命名统一用小写+点分隔，如
order.payment.timeout，便于后端查表、前端映射、监控聚合 - 必须携带上下文参数（如
userId、orderId），否则日志里全是“某用户登录失败”，排查时得翻三天
在 @ControllerAdvice 里统一拦截，别在每个 @ExceptionHandler 里重复写逻辑
每个 Controller 自己写 @ExceptionHandler，等于把错误处理逻辑散落在二十个文件里。统一收口到全局异常处理器，才能保证所有接口返回结构一致、敏感字段被过滤、状态码符合语义。
- 对
BusinessException：提取code查MessageSource，填充参数后返回{"code": "user.login.fail", "msg": "密码错误，请重试"} - 对未知异常（如
IOException）：一律转为"system.error.unknown"，绝不透出e.getMessage()或堆栈片段 - 务必加
@JsonIgnoreProperties({"stackTrace", "cause", "suppressed"})到基础异常类，Jackson 序列化时才不会意外吐出trace字段 - HTTP 状态码按语义设：400 对应参数错，401 对应未登录，408 对应
TimeoutException，别全用 500
消息文案存在 messages_zh_CN.properties 里，别写进 Java 类
文案不是代码逻辑，它是可运营、可 A/B 测试、可热更新的内容。一旦写死在 catch 块里，换句提示就得走一次发布流程。
- 配置示例：
user.login.password.wrong=密码错误，请确认大小写后重试；user.login.password.wrong=Password is incorrect. Check case sensitivity and try again.（英文版） - 动态占位符用
{0}、{1}，由withParam()注入，比如order.pay.timeout=订单 {0} 支付已超时，请重新下单 - 前端不拼接文案，只传
code和参数数组，后端或网关层完成渲染——避免前后端文案不一致、占位符错位 - 上线前检查所有 API 响应体，确认没有字段名含
stackTrace、cause、localizedMessage
前端展示前再过滤一次，别信后端“已经处理好了”
后端漏一个 toString()，前端就可能弹出“com.xxx.exception.BusinessException: user.login.fail”。信任但要验证，尤其在网关或 Axios 拦截器里做最后一道清洗。
- 前端收到响应后，先校验
data.code是否在白名单内（如user.*、order.*），否则降级为通用提示 - 禁止把
error.response.data.message直接alert()—— 它可能是后端没兜住的原始异常字符串 - 对空
msg、万能提示（如“操作失败，请稍后重试”）、含反斜杠或 HTML 标签的值，强制替换为兜底文案 - 移动端尤其注意：Toast 提示长度限制多，
user.register.email.duplicate这种长码对应文案要精简，比如“该邮箱已被注册”
BusinessException，而在于团队是否接受“错误提示是产品功能，不是开发副产品”——它需要产品定文案、测试验场景、运维盯日志、前端做兜底。少一环，友好就变成自欺。Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
