Spring Boot异常处理疑问：为何用自定义异常而非按HTTP状态码定义？

1. 业务语义一目了然 #

HTTP状态码是通用的协议级标识，比如404只告诉你“资源没找到”，但你没法直接从这个码判断是用户不存在还是商品库存为空。自定义的UserNotFoundException、StockEmptyException这类异常，一眼就能定位到具体业务场景，不管是开发排错、运维看日志，还是产品理解问题，都不用再翻一堆细节才能搞清楚状况。

2. 能携带更精准的业务信息 #

自定义异常可以封装专属的业务字段，比如NameAlreadyExistsException里可以加个conflictingName字段，直接把重复的名字带出来。不管是打日志还是给前端返回提示，都能提供比单纯HTTP状态码更有用的信息——用户能知道是自己填的哪个名字重复了，开发也能更快定位到具体的冲突数据。

3. 代码维护和扩展更省心 #

如果全靠HTTP状态码处理异常，业务逻辑里会到处都是“找不到用户就抛404”的判断。哪天业务调整，比如某个场景下用户找不到需要返回400而非404，你得挨个改所有相关的代码。但用自定义异常的话，只需要在全局异常处理器里调整这个异常对应的状态码映射就行，业务代码完全不用动，改动成本低太多。

4. 清晰区分业务异常和系统异常 #

HTTP状态码没法区分是业务层面的预期异常（比如用户名重复、余额不足）还是系统层面的意外故障（比如数据库连不上、Redis挂了）。自定义异常可以把业务类异常统一继承BusinessException，系统类异常继承SystemException，全局处理时就能分开对待：业务异常返回友好的用户提示，系统异常返回通用错误并记录详细日志排查问题。

5. 贴合面向对象的设计思路 #

异常本身就是对象，不同业务场景对应不同的异常类，这刚好符合“单一职责”和“封装”的设计原则。每个异常类只负责对应场景的异常信息，代码结构更清晰，也和Spring生态里的异常处理最佳实践对齐。

内容的提问来源于stack exchange，提问作者Leon