A collaborative coaching mode …

# 接手订单管理系统：从退款模块看懂调用链

一、接手前的准备工作（先做，别急着看代码）

• 跑起来再说话：本地把前后端启动，配置好数据库（重点找 application.yml 里的数据源、Redis、第三方支付配置）
• 拿三样东西：接口文档（如有 Swagger/Knife4j 直接访问 /doc.html）、数据库 ER 图、部署环境说明
• 画接口清单：30 个接口不多，用表格列出：路径、方法、所属模块、是否依赖外部服务（支付、短信等）

二、退款模块代码定位（推荐路径）

后端（标准分层结构，按这个顺序找）：

• Controller：搜 RefundController 或全局搜 refund 关键字 → 看接口入参出参（VO/DTO）
• Service：RefundService / RefundServiceImpl → 业务逻辑核心，你花 70% 时间的地方
• Mapper/Repository：RefundMapper → 看涉及哪些表（一般是订单表 + 退款记录表）
• 外部依赖：重点找支付渠道 SDK 调用（微信/支付宝退款接口）和事务注解 @Transactional

前端：

• views/refund/ 目录下的页面组件
• api/refund.js 之类的封装文件 → 里面有接口 URL，能反查后端 Controller

三、退款调用链（典型结构，对照你的代码验证）

```

前端页面点击"退款"

→ axios 请求 POST /api/order/refund

→ Controller：参数校验（订单号、金额、退款原因）

→ Service：

1. 查订单状态（只有"已支付"才能退）

2. 金额校验（退款额 ≤ 实付额 - 已退额）

3. 生成退款单记录（状态：处理中）

4. 调用支付渠道退款 API

5. 更新退款单状态 + 订单状态

→ Mapper：写库（注意是否在一个事务里）

→ 可能还有：MQ 异步通知、回调接口接收支付渠道结果

```

四、边改边学的实操建议

• 先加日志再改代码：在 Service 关键节点加 log，跑一遍真实退款流程（测试环境），把日志顺序和代码对上
• 用 IDE 的调用链功能：Ctrl+Alt+H（IDEA 查看调用层级）从 Controller 往下追
• 第一个改动选低风险的：比如给退款列表加个筛选条件、改个字段校验，跑通“改代码 → 自测 → 提交”全流程
• 盯紧三个坑：事务边界（退款失败回滚是否完整）、幂等性（重复提交退款）、回调处理（支付渠道异步通知怎么验签）

五、下一步

你把 RefundServiceImpl 的代码发我，我带你逐行分析，指出状态机和事务设计的问题，然后定第一个练手改动。