退货功能需校验订单状态、时效、商品属性及重复申请，支持仅退款、退货退款、换货三类流程，通过状态机控制审核流转，结合事务或消息队列确保退款、库存、优惠分摊的数据一致性。
商品退货管理是电商系统中非常关键的一环，涉及订单状态、库存、支付、物流等多个模块的协同。在Java开发中实现退货功能时，不仅要考虑基本的数据操作，更要做好业务逻辑的判断和流程控制，确保系统的数据一致性与用户体验。
1. 退货申请的前置条件校验
用户提交退货申请前，必须对订单和商品的状态进行严格校验，避免非法操作。
- 订单是否已完成或已发货：只有已发货或已完成的订单才允许申请退货。未支付或已取消的订单不能发起退货。
- 是否在退货有效期内：比如系统规定签收后7天内可申请退货，需比对签收时间与当前时间。
- 商品是否支持退货：部分商品如虚拟商品、定制类商品可能不支持退货，需检查商品配置。
- 同一订单项是否已存在处理中的退货申请：防止重复提交，需查询退货表中是否存在status为“待审核”或“处理中”的记录。
示例代码片段：
if (!order.getStatus().equals("DELIVERED") && !order.getStatus().equals("COMPLETED")) {
throw new BusinessException("该订单当前状态不支持退货");
}
long diffDays = ChronoUnit.DAYS.between(deliveryTime, LocalDateTime.now());
if (diffDays > 7) {
throw new BusinessException("超过7天无理由退货期限");
}
if (!product.getReturnable()) {
throw new BusinessException("该商品不支持退货");
}
2. 退货类型与流程分支判断
根据用户选择的退货原因，系统需执行不同的处理逻辑。
立即学习“Java免费学习笔记（深入）”；
- 仅退款（未收到货）：不涉及退货寄回，确认后直接走退款流程，需标记物流状态为异常。
- 退货退款（已收货）：需用户提供退货物流信息，后台审核通过后触发退款。
- 换货：需冻结原商品库存，新发货后释放原退货商品的库存。
可通过枚举定义退货类型，并在服务层使用策略模式或switch判断分支：
enum ReturnType {
REFUND_ONLY, // 仅退款
RETURN_REFUND, // 退货退款
EXCHANGE // 换货
}
3. 审核与状态流转控制
退货申请提交后进入审核阶段，后续状态变更必须遵循预设流程，不可逆或跳步。
- 初始状态为“待审核”，管理员审核通过后变为“待用户退货”。
- 用户填写退货单号后更新为“待商家收货”。
- 仓库确认收货并验货无误后，进入“待退款”或“待换货发货”。
- 最终完成状态为“已完成”或“已关闭”（如验货不合格）。
建议使用状态机（如Spring State Machine）或状态模式来管理状态流转，避免非法跳转。
4. 退款与库存处理
退货完成后，需同步处理资金与库存，保证数据一致性。
- 退款：调用支付网关的退款接口，传入原始订单交易号和金额。需记录退款流水，防止重复退款。
- 库存回滚：将退货商品数量加回可用库存。若为部分退货，只增加对应数量。
- 优惠分摊计算：若订单使用了优惠券或参与满减，需按比例计算应退金额，不能简单按单价退还。
注意：这些操作应放在同一个事务中，或通过分布式事务/消息队列保证最终一致性。
基本上就这些核心逻辑。退货功能看似简单，但边界情况多，比如并发申请、多次退款、物流异常等，都需要在代码中细致处理。写好业务判断，才能让系统稳定可靠。不复杂但容易忽略细节。
