企业级异常处理规范需覆盖“怎么抛、怎么分、怎么转、怎么记”四环节，明确划分业务异常、客户端异常、系统异常三类，统一响应结构与字符串错误码，分层约束抛出职责，并通过CI检查、日志规范和文档同步保障落地。
企业级项目要让异常处理真正“规范”，关键不是堆砌注解或写一个全局处理器，而是建立一套可落地、可维护、能协同的处理标准。它必须覆盖异常怎么抛、怎么分、怎么转、怎么记四个环节，而不是只关注最后“怎么返回”。
定义清晰的异常分类体系
不区分异常类型，就谈不上规范处理。企业级标准要求把异常明确划分为三类，并各自有对应类和使用场景：
- 业务异常：如“库存不足”“用户已存在”“支付超时”。必须继承自自定义基类（如BusinessException），带唯一错误码（如BUSI_STOCK_SHORTAGE）和语义化消息，由Service层主动throw，绝不包装成RuntimeException。
- 客户端异常：参数校验失败、路径不存在、权限不足等。由框架自动抛出（如MethodArgumentNotValidException、AccessDeniedException），全局处理器按类型精准捕获，返回4xx状态码。
- 系统异常：空指针、数据库连接中断、序列化失败等非预期错误。统一由@ExceptionHandler(Exception.class)兜底，生产环境屏蔽堆栈细节，返回5xx状态码+通用提示（如“服务暂时不可用”），同时记录完整日志供排查。
统一响应结构与错误码管理
前端靠错误码做逻辑分支，靠结构做统一解析。规范要求：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 所有接口——无论成功或失败——都返回同一JSON结构，例如{"code": 200, "msg": "OK", "data": {}, "timestamp": 1727231022}；
- 错误码必须是字符串枚举（如ResultCode.BUSINESS_ERROR），禁止硬编码数字；
- 业务错误码按域划分前缀（如USER_、ORDER_、PAY_），便于归因和监控；
- HTTP状态码与业务码分离：4xx/5xx反映请求合法性与服务可用性，业务码（如601）反映领域语义，两者共存不冲突。
分层职责与抛出约束
规范的核心是让每层只做该做的事：
- Controller层：只接收请求、调用Service、返回成功结果；不捕获任何异常，不处理业务逻辑分支；
- Service层：专注业务规则；遇到业务规则不满足时，直接throw具体业务异常（如throw new BusinessException(USER_LOCKED, "账号已被锁定")）；
- DAO/Repository层：不封装或转换数据库异常；让SQL异常原样上抛，由全局处理器中的专用方法（如@ExceptionHandler(DataAccessException.class)）统一转为系统异常并记录；
- 全局处理器：只做三件事——格式转换、状态码映射、日志记录；不做重试、补偿、降级等业务动作。
配套机制保障落地效果
光有代码规范不够，还需工程机制兜底：
- 在CI流程中加入静态检查，拦截catch (Exception e)和e.printStackTrace()等反模式；
- 所有业务异常构造必须传入错误码枚举，禁止用字符串字面量初始化；
- 日志中强制打印traceId + 错误码 + 简洁上下文（如“订单ID=ORD-20260925001，库存校验失败”），禁用长堆栈刷屏；
- 提供内部错误码文档页，实时同步枚举值、含义、触发场景、建议操作，供前后端共同查阅。
