hl-api-changelog/changelogs-v2/2026-10/02_8708_未支付订单自动取消时刻改为24h-修复-管理后台.md

schema, ticket, title, consumer, author, change_type, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base

schema	ticket	title	consumer	author	change_type	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base
hl-changelog/v2	8708	二期未支付订单自动取消时刻由创建后 2h 恢复为 24h，接口契约不变	multiple	wx(GIT)	修复	deployed	not_required	not_required					接口路径、入参、出参、错误码均不变；变化的只是二期待支付订单被系统自动取消的时刻：由创建后约 2h 恢复为创建后 24h，与已展示的支付截止时刻 expiryTime 一致。	2026-10-02	dev-v3

二期订单：未支付订单自动取消时刻恢复为创建后 24h

服务: hl-order-service-v3（取消判定与扫描任务）、hl-user-service（定时任务调度） 关联 Issue: #8708 关联 PR: #8729（合并提交 89c87fd217） 部署状态: 测试环境已部署并实测，见「五、实测验证」 影响范围: 小程序订单详情/列表与发起支付、管理后台订单详情与线下收款登记——只影响订单何时被自动取消，不改任何字段

---

⚠️ 关键变化

改前：二期订单对外展示的支付截止时刻是创建后 24h（expiryTime = 创建时刻 + expiryMinutes，expiryMinutes 为 1440），但系统在创建后约 2h 就把未支付订单自动取消。2~24h 之间，客户看到的截止时刻还没到，订单却已是 CANCELLED：小程序无法再发起支付，管理后台也无法登记线下收款。

改后：系统按同一个截止时刻取消。创建时刻 + expiryMinutes 到达后，在下一次每分钟扫描中取消，取消原因为「订单超时未支付，系统自动取消」。

---

一、背景

根因：自动取消原来只靠 RocketMQ 延迟消息触发。RocketMQ 4.x 延迟消息最长 2h，24h 窗口的过期消息实际在约 2h 后投递并取消订单；测试服 SYSTEM_AUTO_CANCEL 记录的延迟全部是 120 分钟。

后果（二期尚未上生产，影响面限于测试服数据）：

• 客户在创建后 2~24h 之间无法支付；
• 取消会连带房务释放：测试服有 8 单取消后配房被软删并回补库存；
• 客户在取消前发起、取消后才到账的款落入 CANCELLED_PAID，需要人工退款。

---

二、后端改动

• 窗口 ≤ 120 分钟的订单仍由延迟消息触发取消；消费延迟消息时增加到期判定，截止时刻未到不取消。
• 新增每分钟一次的扫描任务：order-v3 OrderExpiryJob，由 user-service 定时任务经内部接口 POST /v3/internal/jobs/order-expiry/run 触发，按「创建时刻 + expiryMinutes ≤ 当前时刻」取消。窗口超过 120 分钟的订单靠它取消；延迟消息丢失时，它也是兜底。
• 该内部接口经网关访问一律返回 403，前端不可调用，也无需调用。
• 到期判定与小程序展示的 expiryTime 共用同一个计算（OrderPayWindow）：展示的截止时刻就是系统取消的依据。

---

三、对前端的影响

前端无需改动。 接口路径、入参、出参、错误码均不变。

可观察到的行为变化

端	接口	改前	改后
小程序	订单详情、订单列表（order-v3 内部端点 GET /v3/internal/mp/order/{orderId}、GET /v3/internal/mp/order/list，经小程序服务转发）	创建约 2h 后订单变为 CANCELLED，expiryTime 不再返回	截止时刻到达前订单保持 PENDING_PAY，expiryTime 持续返回
小程序	发起支付（order-v3 内部端点 POST /v3/internal/mp/order/{orderId}/payment/unified-order，经小程序服务转发）	2~24h 之间订单已取消，返回 520104「订单当前状态不允许支付」	截止时刻到达前可正常发起支付
管理后台	GET /v3/admin/order/{id}	创建约 2h 后为 CANCELLED	截止时刻到达前为 PENDING_PAY
管理后台	POST /v3/admin/order/{orderId}/payment/manual-receipt	2~24h 之间订单已取消，无法登记	截止时刻到达前可正常登记；登记后订单离开待支付，不再被自动取消

字段口径（均未变化）

• 小程序详情/列表的 expiryTime：仅订单为 PENDING_PAY 时返回，值为 创建时刻 + expiryMinutes（expiryMinutes 为空时按 1440 计）；其他状态返回 null。
• 管理后台创单响应的 expiryMinutes：仍为 1440。

---

四、覆盖范围与边界

• 范围：二期 order-v3 的待支付订单。一期 v2 订单不受影响。
• 已支付或已登记线下收款的订单离开待支付，不会被自动取消。
• 撤销线下收款后回到待支付的订单，系统不自动取消，需人工处理（与改前一致）。
• 取消时刻：截止时刻之后的下一次每分钟扫描，按设计在截止时刻后 2 分钟内。
• 按产品配置不同支付窗口，不在本次范围。

---

五、实测验证（测试环境）

• 部署后存量：创建早于部署时刻 24h 以上、仍待支付的订单经扫描全部取消（剔除撤销收款后回到待支付的单，计数为 0）。阳性对照单部署前为超期待支付，部署后转为 CANCELLED，状态日志新增一条 SYSTEM_AUTO_CANCEL 记录。
• 新建订单：管理后台新建两张核心订单，创建后 132 分钟两单仍为 PENDING_PAY（改前此时已被取消）。对其中一张登记线下收款，返回 code 200，订单转为已付定金，状态日志中没有自动取消记录。

---

关联

• 工单 #8708，PR #8729