JPA非受检异常需按业务语义分类映射HTTP状态码：EntityNotFoundException→404，DataIntegrityViolationException→400/409，OptimisticLockException→409，兜底异常→500；应通过@ControllerAdvice或@Provider统一处理，脱敏错误信息并记录结构化日志。
Java中JPA持久化操作抛出的非受检异常（如EntityNotFoundException、DataIntegrityViolationException等）本身不带HTTP语义，也不能自动传播到上层调用链。准确分类与捕获的关键，在于理解每种异常背后的业务含义，并配合统一拦截机制做语义化处理，而非简单包裹或忽略。
核心非受检异常类型与业务语义
这些异常均继承自PersistenceException，但语义差异显著，不能一概而论：
-
EntityNotFoundException：明确表示“按ID查询资源失败”，属于客户端请求错误，对应REST语义中的资源不存在——应映射为
404 NOT_FOUND -
DataIntegrityViolationException：常见于唯一约束冲突（如重复用户名）、外键缺失或字段长度超限，本质是客户端提交数据不合法——优先返回
400 BAD_REQUEST；若涉及资源状态冲突（如尝试创建已存在的租户），可用409 CONFLICT -
OptimisticLockException：并发修改检测失败，属可预期的业务竞争场景，不是系统故障——建议返回
409 CONFLICT，并在响应体中提示“数据已被他人修改，请刷新后重试” -
PersistenceException / TransactionSystemException：兜底异常，无法归因到具体业务逻辑，通常意味着底层连接异常、SQL语法错误或映射配置问题——统一映射为
500 INTERNAL_SERVER_ERROR
Spring环境下的统一捕获方式
避免在每个Service方法里写try-catch，推荐使用@ControllerAdvice集中处理：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 按子类优先原则编写
@ExceptionHandler，例如先捕获EntityNotFoundException，再捕获更宽泛的PersistenceException，防止父类提前截断 - 返回
ResponseEntity<ErrorResponse>，显式设置状态码，不依赖HTTP响应体中的success: false来判断失败 - 对错误信息脱敏：禁用
e.getMessage()直接输出，改用预定义文案（如“请求的用户不存在”），且不暴露表名、字段名、SQL片段或堆栈路径 - 记录带traceId的结构化日志，便于链路追踪和问题定位
区分协议层与业务层责任边界
状态码误用常源于混淆异常来源和责任归属：
立即学习“Java免费学习笔记（深入）”；
- ID格式非法（如传入字符串
"abc"）应在参数解析阶段由Spring抛出MethodArgumentTypeMismatchException，映射为400；而非等到JPA执行时才报错 - 主键为空导致插入失败，需结合
@Valid参数校验前置拦截，而不是让数据库约束兜底并返回模糊的DataIntegrityViolationException - 事务成功提交但业务逻辑失败（如余额不足扣款），不应返回
200——此时异常不属于JPA层，应由业务代码主动抛出自定义异常并映射对应状态码
JAX-RS环境的等效实践
若项目基于JAX-RS（如Quarkus、Jersey），可用@Provider实现ExceptionMapper：
- 为每种JPA异常编写独立的
ExceptionMapper<T>实现类 - 在
toResponse()方法中构造Response对象，设置状态码与标准化错误体 - 通过
@Priority注解控制多个Mapper的匹配顺序，确保特化类型优先于泛化类型
