主题
租车功能完整性审查
审查日期：2026-09-16
代码基线：d45a9f89
范围：Api、AdminWeb、MerchantWeb、App、MerchantApp 的租车相关实现及公共订单、退款、结算链路。
说明：以下为初次审查时的基线发现，保留原始证据。后续已开展代码修复，当前实现进度和新增验证请以同目录《租车功能补全实施清单_2026-09-16.md》为准，不能将本报告所有问题视为仍未修复，也不能将已修复部分视为全功能完成。
一、结论
租车正常履约主链路已经具备，但不能判定为完整的经营闭环。
已具备：平台车型及增值服务配置、商户车队及日期报价、用户选日期和地图地址下单、支付后派单、商户接拒单、交还车、用户或平台确认完成、商户结算。
主要缺口集中在取消与退款联动、退款和履约互斥、精确时间占用、异常费用、三端信息同步，以及平台自营活动商品的预约入口。建议先处理下列 P1 问题，再扩大正式接单量。
这里区分两种实现，不能混为一谈：
- 车型直订：用户先付款，平台随后找车派单。当前下单只创建预约记录，不锁定实际车辆。
- 平台自营租车活动商品：可通过团购等活动销售，支付后进入待预约，再调用平台租赁预约接口创建派单。这条链路的用户端没有接通。
二、确定问题
F1 / P1：平台取消派单没有联动主订单和租金退款
平台对待派单、待接单或已拒单记录点击“取消”时，cancelDispatch 只把派单状态改为 7，并处理可能存在的押金。它不修改主订单、不创建租金退款申请，也不产生可重派状态；指派方法只接受状态 0、8。
后果：已支付订单可能仍显示待派单，但派单已经终止。用户需要另行申请退款；接近预约取车时间时还可能受到普通退订阶梯的限制。现有平台客服渠道可人工兜底，不等于取消操作本身闭环。
建议：区分“撤销本次指派，重新找车”和“平台无法履约，终止并退款”。后者统一联动主订单、退款、车辆释放、通知及审计记录。
验证：隔离调用取消方法，确认主订单 Mapper 没有任何读写调用。
F2 / P1：退款和实际交车缺少互斥
pickupCar 只检查派单状态为 2，不检查主订单是否仍为已支付，也不检查是否存在退款申请。新退款申请把主订单置为 REFUNDING，并未同步把派单移出可交车状态。
另一方向也有缺口：租车退款计算只看预约取车时间，不读取实际取车状态。如果商户提前交车，预约取车时间尚未到，仍可以按未取车阶梯自动审核退款。
后果：可能出现退款处理中继续交车，或者已经交车后仍触发自动退款。真正收款、实际履约和车辆释放不能只依靠预约时间推断。
建议：在同一事务中锁定主订单及派单，检查退款占用；交车后记录明确的履约状态，并由退款规则读取。已交车的争议退款应走受控售后流程。
验证：交车方法不读取主订单；向实际退款计算器传入 IN_SERVICE、未来一小时的取车时间及 10000 分金额，仍得到可退 5000 分。此验证使用隔离对象，没有发起真实退款。
F3 / P1：车辆冲突按日期判断，预约时刻没有参与占用
用户可以选择精确到分钟的取还车时间，但车辆可用查询仅比较 pickup_date、return_date，商户报价服务也只传入日期。
例如同一辆车的订单 A 在 2026-09-17 18:00 还车，订单 B 在 2026-09-17 10:00 取车。现有条件认为 A 的还车日期不大于 B 的取车日期，因此不会排除该车，尽管有 8 小时重叠。车辆逾期未还时，也没有按实际占用持续阻断后续日期。
建议：统一按预约时间区间检查，必要时加交接缓冲；实际未还车辆单独纳入占用规则。此问题与“下单是否锁车”的业务模式无关，人工派单时同样存在。
验证范围：代码和 SQL 条件核对；未进行真实 MySQL 并发派单。
F4 / P1：平台自营租车活动缺少用户预约入口
平台可以创建 CAR_RENTAL 履约商品并设置团购、拼团等活动；团购支付处理器会把此类订单置为 AWAIT_BOOK。后端也有 /api/app/platform-rental-bookings，但整个 App 未找到该接口的调用或租车活动预约表单。现有订单预约入口仍是酒店日历和入住人表单。
后果：如果运营上架这类租车活动商品，用户付款后不能从当前小程序完成租车预约，后续派单链路无法自然启动。此结论不影响独立车型直订入口。
建议：接通独立预约表单、履约类型展示及完成确认；在接通前限制此类活动发布。还应统一直订和活动预约的日期、驾驶人、地址校验。
证据：平台商品配置、支付后待预约、租车活动预约服务、现有酒店预约入口。
F5 / P2：接单、拒单和取消的状态迁移存在并发覆盖风险
接单、拒单等使用普通查询检查状态，随后按 ID 无条件更新。只有指派方法显式锁定派单；接单和拒单即使有事务，也没有旧状态条件。
场景：商户两个客户端同时接单、拒单，或平台取消与商户接单并发，双方都可能读到状态 1 并成功更新，后写入者覆盖前者。接单触发的结算冻结与最终派单状态可能不一致。
建议：统一行锁或旧状态条件更新，检查影响行数，并将金额及库存副作用放在同一事务。
验证范围：静态并发风险分析，未运行数据库并发复现。
F6 / P2：用户端没有接通真实租车阶段
支付时主订单进入 IN_DISPATCH，商户接单、交车、还车都只修改派单。公共展示状态把 IN_DISPATCH 一律译为“待派单”。公共订单详情仅为接送订单填充 dispatchStatus，未为租车填充。
App 虽然额外读取了租车派单并展示日期、地址、车牌等信息，但进度计算仍取公共详情的 rawOrder.dispatchStatus，没有使用新获取的派单状态。当前详情模板也没有渲染 progressSteps。
后果：已接单、已取车、已还车订单的主状态仍可能显示“待派单”，用户不能可靠判断当前阶段。
建议：主展示态和进度统一映射真实派单状态，明确区分待重派、取消、待支付和正常履约。现有进度函数简单使用数值大小比较，输入 7、8、9 都会把全部步骤标记完成；接通展示时必须同时修复，但不能把这个潜在错误当作当前已经显示的页面效果。
证据：订单详情投影、展示状态文案、App 进度数据来源。
F7 / P2：商户网页版没有展示已购买的增值服务
后端派单详情返回 services，用户端和商户小程序也有服务明细。MerchantWeb 租车详情只展示基本信息、总预计结算收入及部分验车信息，没有服务名称、数量、商户分成明细。
后果：只使用网页版的商户可能漏交付已付费的附加服务，也无法逐项核对收入。
建议：网页版补齐服务快照；平台派单详情也应能查看服务要求，而不只显示汇总分成金额。
F8 / P2：逾期只有一次性标记，未形成补费闭环
定时任务忽略预约还车时刻，只比较还车日期；且只有 isOverdue 尚未标记时才写入逾期天数。第一次标记一天后，后续扫描不会递增。overdueFeeFen 已有字段和映射，但未找到业务计算、补费订单、用户支付和商户结算的接入。
后果：当天晚还不被识别，跨天持续逾期天数不准确；系统也不能据此完成收费和对账。
建议：先确认宽限期和计费规则，再接入动态扫描、最终还车结算、费用确认、补款和争议处理。
证据：逾期扫描。
验证：对已经标记逾期一天、实际已超过三天的记录运行真实任务方法，确认没有再次写入。
F9 / P2：租车派单没有接入现有商户通知队列
现有通知服务已支持接送、旅拍派单，租车指派没有调用它。普通支付通知又会跳过主订单 merchantId <= 0 的订单，而车型直订主订单归属平台，merchantId = 0。
后果：车行有工作台待办计数，但没有这条链路对应的主动派单通知，依赖主动刷新或平台人工联络。
建议：复用可靠通知队列，接入租车指派、重派、取消及重要时间提醒，保留幂等和重试。
F10 / P2：交还车验收规则只在部分前端存在
商户小程序要求油量和至少一张照片；网页版允许不传照片，后端也没有必填校验、里程非负校验或“还车里程不低于取车里程”校验。
后果：缺少证据的订单仍可进入已取车、已还车，损坏、油量和里程争议无法可靠追溯。
建议：把两端统一的验收要求放到服务端，并补齐历史照片、油量和损坏证据的查看。平台当前派单页面也缺少完整验收详情入口。
验证：隔离调用实际服务，可用空验车资料交车，也可用负数还车里程完成还车。
F11 / P2：付款前没有展示实际生效的退订规则
后端已保存租车退款政策快照并执行距取车时间的阶梯退款，但车型详情只显示可选的购买须知，确认订单页没有接入公共退款政策提示接口。公共订单详情是在下单后展示规则。
后果：后台调整退款政策后，付款前的自由文案可能为空或与实际扣费规则不一致。
建议：像酒店和团购确认页一样展示实际生效的政策，并明确“平台未能派到车”和“用户主动退订”的处理区别。这里是产品信息一致性问题，本报告不作法律合规结论。
三、三方功能清单
| 角色 | 已有能力 | 完整性判断 / 缺口 |
|---|---|---|
| 平台 | 车型分类、车型上下架、图片与价格、绑定增值服务 | 基础商品管理已有 |
| 平台 | 候选车行报价、指定车牌、锁定出车价、拒单后重派 | 有正常流程；精确时间冲突、撤销和退款联动不足 |
| 平台 | 确认完成、结算入口、公共订单及售后能力 | 正常结算已有；租车验收详情、异常费用闭环不足 |
| 商户网页版 | 车队、基础报价、日期报价、日期停用 | 已有；不是用户销售价格日历 |
| 商户网页版 | 接拒单、客户信息、交还车、结算收入 | 缺增值服务明细；验车规则弱于小程序 |
| 商户小程序 | 工作台待办、接拒单、交还车、服务及分成信息 | 履约入口已有；未找到租车车队和日期报价维护，仍依赖网页版 |
| 用户 | 车型浏览、日期时刻、自由地图选点、驾驶人信息、增值服务、优惠券、支付 | 直订已有；付款不保证锁车，业务承诺需明确 |
| 用户 | 订单、取还车地址、车牌、服务明细、确认还车、公共退款及客服 | 阶段状态未接通；没有完整的验车证据核对和费用争议入口 |
| 跨端 | 订单归属校验、商户能力权限、服务端报价、完成与结算联动 | 已有基础防护；并发履约与退款互斥需补齐 |
| 活动租车 | 平台配置、后台预约接口 | 小程序预约入口缺失，不应按可用完整链路验收 |
四、需要确认的业务边界
以下不是一概判为代码缺陷，先由业务确认要支持什么：
- 先收款后找车还是有车才收款：现有专项测试明确断言下单不调用锁车方法。自由地图地址也明确不限制服务区域。如果保持此模式，应增加找车期限、失败退款和人工接单责任，而不是直接恢复旧库存限制。证据：明确不预占的测试。
- 计费天数：当前按日期差计费，不按实际小时向上取整；同日租赁不允许。若采用 24 小时制，需要同时调整用户价格、商户报价、服务计费和逾期规则，不能只改前端。
- 押金是否在系统内收取：默认
car-rental.deposit-enabled=false，用户页面有意不展示押金，属于当前明确范围。但后台仍可配置押金；现有冻结、退还实现只改数据库状态，没有真实资金动作。不能直接打开开关并宣称已支持线上押金；开启后用户端也没有对应操作入口。证据：开关、押金服务。 - 续租、改期、换车、提前还车：未找到独立的业务接口和三端操作闭环。若线下处理，需要说明如何同步车辆占用、应收金额和订单快照。
- 油电差额、超里程、损坏赔付、违章：目前主要是验车信息字段，未找到租车专属的定价、用户确认、收款、对账及申诉流程。
- 驾驶资格和合同：驾驶人姓名、手机号和驾驶证号已采集，但未找到驾驶资格审核状态、拒绝交车处理、电子交接确认或租车合同签署闭环。可采用线下流程，但不能把字段采集算作已完成审核。
- 完成和结算时效：已有用户或平台确认完成、结算周期及微信结算条件检查；未找到租车还车后用户不确认的专门超时完成机制。是否采用人工平台确认需明确责任。
- 评价和质量反馈：未找到租车专属评价闭环；现有
XdRentalReviewServiceImpl使用的是物品租赁派单，不等于租车已经支持评价。
五、验证结果及限制
已执行
- 后端租车、车队、报价、退款计算、生命周期及逾期任务相关测试：57 项发现，56 项通过，1 项跳过，0 失败。
- App、MerchantApp 和 MerchantWeb 相关前端测试：8 项通过。
- 隔离调用实际后端方法，验证了取消不触及主订单、交车不检查主订单、缺失或非法验车资料可提交、退款计算忽略实际履约状态、逾期天数不持续更新。
- 加载真实用户订单页面逻辑验证进度函数：状态 7、8、9 均被计算成所有步骤完成；当前模板未展示这些步骤，已在 F6 区分潜在问题与实际显示问题。
- 检查两条销售链路、三端页面、接口归属、状态更新、SQL、数据库迁移及对应测试。
执行的后端测试选择：
bash
mvn -pl ruoyi-admin -am test \
'-Dtest=*CarRental*,*MerchantCar*,RentalOverdueTaskTest' \
-Dsurefire.failIfNoSpecifiedTests=false -DfailIfNoTests=false未验证
- 真实 MySQL 测试
CarRentalMysqlTest因未设置隔离测试库环境变量而跳过。 - 未连接开发或生产业务数据库，未检查线上迁移执行状态、调度开关、真实商品配置或已有异常订单。
- 未发起真实微信支付、退款、押金、分账或资金结算。
- 未运行浏览器完整交互测试，也未运行微信开发者工具或真机验收。
- 现有生命周期测试隔离了数据库、支付和钱包 IO；若干前端测试只是代码契约检查。全部通过不代表完整经营流程已验收。
测试期间有本地日志目录不存在的告警，但专项测试本身通过。本次只新增审查报告，没有修改业务代码或部署。
六、建议验收顺序
- 先修复 F1、F2、F3；若要销售平台活动租车，同时修复 F4，否则暂时限制该入口。
- 补齐并发状态保护、三端阶段显示、服务明细、派单通知和服务端验车校验。
- 确认业务边界后，补齐无车履约失败、逾期、损坏、押金和续租等异常流程。
- 用隔离数据库覆盖接拒单并发、退款与交车并发、跨时刻占用和退款失败恢复。
- 三端联合验收：正常完成、无车可派、拒单重派、平台取消、提前交车后退款、逾期归还、有损归还、用户不确认、结算未到期和结算完成。