区分systemexception和businessexception的核心在于异常原因和可控性：前者因基础设施故障导致，后者因业务规则违反引发；其他异常多属开发疏漏。

区分 SystemException 和 BusinessException 的核心在于异常发生的原因和可控性，而不是抛出位置或代码层级。分类的关键是看这个异常反映的是“系统底层出了问题”，还是“业务规则被违反了”。

业务异常（BusinessException）：规则没被遵守

这类异常源于业务逻辑本身的约束条件被触发，属于可预期、可校验、可提示用户的场景。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 用户输入不符合业务要求：比如注册时邮箱格式错误、密码长度不足、年龄填了负数
• 操作违反状态流转规则：如已发货的订单不能再取消、冻结账户不能登录
• 资源不满足业务前提：余额不足扣款、库存为零仍下单、重复提交同一笔支付
• 通常在 Service 层主动 throw，不依赖 try-catch 捕获外部异常

系统异常（SystemException）：基础设施不可用

这类异常代表支撑系统运行的某个环节临时失效，属于不可控、不可预测、需运维介入的问题。

• 数据库连接失败、SQL 执行超时、主键冲突（非业务逻辑导致）
• 远程服务调用失败（HTTP 500/超时）、MQ 消息发送失败、Redis 连接断开
• 文件系统读写异常（磁盘满、权限不足）、线程池耗尽、配置加载失败
• 一般由框架或中间件抛出，Service 层捕获后包装成 SystemException 再上抛

其他异常（Exception / RuntimeException）：未覆盖的盲区

不属于前两类的，基本都归入这一类——通常是开发疏漏或极端边界情况：

• 空指针（NPE）、数组越界、类型转换失败等编程基础错误
• 未对第三方 SDK 返回值做判空、未处理流关闭异常
• 配置项缺失导致初始化失败、JSON 反序列化字段类型不匹配
• 这类异常应被兜底捕获，记录完整堆栈，但不对用户暴露细节

判断小技巧：问自己一句话

如果异常发生后，用户刷新页面重试大概率能成功 → 是 SystemException；
如果异常发生后，用户改个输入或换个操作才能继续 → 是 BusinessException；
如果异常发生后，连开发都不知道为啥会出这个错 → 就是其他异常，需要补日志、加校验、修逻辑。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南