区分业务异常和系统级故障的关键在于异常语义：业务异常是“用户做错了什么”，如输入非法、状态冲突、资源不足，应抛BusinessException并返回400；系统异常是“系统哪里坏了”，如数据库中断、第三方超时，需包装为SystemException并返回500或503。
区分业务异常和系统级故障，关键不在代码位置或技术形态，而在于异常背后的语义：是“用户做错了什么”，还是“系统哪里坏了”。前者可预期、可提示、不需运维；后者不可控、需恢复、常要告警。
看异常是否源于业务规则被违反
业务异常对应明确的业务约束条件，属于设计内、流程中正常的失败分支：
- 用户输入不合法：邮箱格式错误、密码少于6位、年龄填了-5
- 状态流转被阻断：已发货订单尝试取消、冻结账号尝试登录、重复提交支付请求
- 资源前提不满足：余额不足扣款、库存为零下单、优惠券已过期
这类异常应在 Service 层主动抛出，用自定义 BusinessException（继承 RuntimeException），带业务码（如 "INSUFFICIENT_BALANCE"）和上下文（如订单ID、用户ID）。它不表示程序写错了，而是业务逻辑在按规则执行。
看异常是否反映基础设施临时失效
系统级故障指向支撑服务运行的底层环节出了问题，与具体业务无关，且用户重试可能成功：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 数据库连接中断、SQL 执行超时、主键冲突（非因业务逻辑导致）
- 调用第三方服务返回 500 或超时、MQ 消息发送失败、Redis 连接断开
- 文件读写失败（磁盘满、权限不足）、线程池耗尽、配置加载异常
这类异常通常由框架、驱动或中间件抛出（如 SQLException、TimeoutException、IOException）。Service 层应捕获后包装为统一的 SystemException（或直接使用标准异常类型），保留原始 cause，并记录完整堆栈。它需要监控指标、触发告警，甚至熔断降级。
看异常发生后用户的合理应对方式
一个简单但实用的判断方法：
- 用户改个输入、换种操作就能继续 → 是业务异常（返回 400 + 友好提示）
- 用户刷新页面或等几秒再试大概率能成 → 是系统异常（返回 500 或 503 + “服务暂时不可用”）
- 连开发都看不出为啥出这个错（如 NPE、ClassCastException、JSON 反序列化失败）→ 属于编码疏漏，需补日志、加校验、修逻辑
分层处理不能错位
DAO 层只负责数据存取，不判断业务含义。例如 UPDATE 影响行数为 0，它只返回 false 或 0；是否构成“库存不足”，由 Service 层根据业务语义决定并抛 BusinessException。若在 DAO 层直接抛业务异常，会导致事务边界混乱、测试难模拟、全局处理器误判响应码。
Controller 层或 @ControllerAdvice 中按类型分流：BusinessException 走 WARN 日志 + 400 响应；SystemException 或未识别异常走 ERROR 日志 + 500 响应，且绝不暴露敏感细节（如表名、SQL、绝对路径）。
