订单核验是分层校验机制，涵盖接口层@Valid参数校验、服务层业务逻辑核验（用户/商品状态、库存、金额一致性、幂等）、数据库唯一约束与Redis防重，以及清晰错误码返回。
订单核验功能的核心是确保用户提交的订单数据合法、完整、一致且未被篡改。在Java后端（如Spring Boot项目）中，这不是一个“单点方法”，而是一套分层校验机制，涵盖参数接收、业务规则、库存/状态一致性、防重与幂等几个关键环节。
一、接口层：用@Valid做基础参数校验
这是第一道防线，拦截明显非法输入（如空字段、格式错误、超长字符串）。
- 定义DTO并添加校验注解，例如：
@NotBlank(message = "用户ID不能为空")
private String userId;
@NotNull(message = "商品ID不能为空")
private Long productId;
@Min(value = 1, message = "数量至少为1")
private Integer quantity;
@DecimalMin(value = "0.01", message = "金额不能小于0.01")
private BigDecimal amount;
}
Controller中启用校验：
@PostMapping("/orders")public Result
// 校验失败时，Spring会自动返回400及错误信息
return orderService.create(dto);
}
二、服务层：执行核心业务核验逻辑
这一层检查的是“业务合理性”，需查库、比对状态、计算一致性。建议封装成独立的OrderVerificationService或在service方法内分步校验。
立即学习“Java免费学习笔记（深入）”；
- 查用户是否存在且状态正常（如未冻结）
- 查商品是否存在、是否上架、库存是否充足（注意：库存校验需考虑并发，推荐先扣减再下单，或使用Redis原子操作预占）
- 核对金额：前端传入的
amount应等于price × quantity（防篡改，避免仅依赖前端计算） - 检查用户是否重复提交（结合订单号/业务流水号+用户ID做幂等判断，可借助数据库唯一索引或Redis SETNX）
三、数据库与幂等：防止重复下单和脏数据
订单表主键建议用业务唯一ID（如雪花ID或UUID），同时加唯一约束字段组合（如user_id + biz_no）。
- 插入前尝试INSERT IGNORE或ON DUPLICATE KEY UPDATE（MySQL）
- 或先SELECT再INSERT，但需加事务+行锁（如
SELECT ... FOR UPDATE）避免并发问题 - 更推荐方式：用Redis记录“用户+商品+时间窗口”的临时标记，5分钟内相同请求直接拒绝
四、返回清晰的核验结果与错误码
不要只抛异常或返回泛型错误。定义明确的核验失败类型，方便前端提示或埋点监控：
- PARAM_INVALID（参数不合法）
- USER_NOT_FOUND / USER_DISABLED
- PRODUCT_OFFLINE / INSUFFICIENT_STOCK
- AMOUNT_MISMATCH（金额不一致，疑似篡改）
- ORDER_DUPLICATED（重复提交）
每个错误对应具体message和code，统一由全局异常处理器捕获并格式化输出。
基本上就这些。订单核验不是“写个if判断”就完事，而是要从前端传参、服务逻辑、存储一致性到防刷防重层层设防。关键在于把校验点拆清楚，每一步都留痕、可回溯、可告警。
