所有异常都返回“操作失败”，用户无法行动，开发也难定位。统一处理应统一结构，而不是抹平原因。
本文使用JDK 7、Spring Framework 3.2.6 与 Servlet 容器，代码为结构片段。把请求入口、业务服务和数据访问拆开，是为了明确依赖与事务归属。容器能够装配对象，但应用仍须负责业务规则、异常含义和外部资源生命周期。
1. 从现象推到机制
参数错误、未授权、资源不存在和服务端故障有不同语义。控制器异常处理器可以转换为稳定的响应结构，内部堆栈则留在受控日志。把数据库错误原样返回页面，会泄露实现信息，也不便于调用方稳定处理。
图中的四个节点分别表示业务异常、异常映射、用户反馈、内部日志。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
定义错误码、用户提示和关联编号，HTTP 状态码与业务含义保持一致。示例是设计结构，具体异常映射需按项目实现。
1
2
{"code":"ORDER_NOT_FOUND","message":"订单不存在",
"request_id":"demo-request-7"}
将片段放入匹配版本的 Maven 工程，补齐组件扫描、数据库连接及依赖。验证时通过容器取得对象，区分普通对象调用和代理调用，避免绕过要研究的机制。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 输入格式不合法 | 返回能定位字段的问题 |
| 服务端未知异常 | 返回通用提示并保留内部堆栈 |
| 访问无权限订单 | 不能顺带泄露其他订单详情 |
对照 1：输入格式不合法
返回能定位字段的问题。观察时记录响应状态与稳定错误码。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：服务端未知异常
返回通用提示并保留内部堆栈。观察时记录关联编号能否定位日志。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：访问无权限订单
不能顺带泄露其他订单详情。观察时记录权限判断与错误内容。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
统一异常处理不能吞掉事务失败。事务拦截器与异常转换的顺序需要理解，错误被捕获后若正常返回，可能改变原本的回滚行为。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“访问无权限订单”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
