---
schema: "hl-changelog/v2"
ticket: "8003"
title: "团期车辆共用关系：跨维度确认后成员行跟随最新派单行 + 新增每日悬挂核对任务 1045（无接口契约变更）"
consumer: "admin"
author: "jw(GIT)"
change_type: "修复"
backend_status: "deployed"
gateway_status: "verified"
frontend_status: "not_required"
frontend_owner: ""
frontend_ref: ""
target_release: ""
verified_at: ""
status_note: "本单没有新增、修改、删除任何 admin/mp 端点，请求参数与响应字段全部不变，change_type 取「修复」是按 20_7539 先例（校验器只允许 新增接口/修改接口/删除接口/修复/前端* 几类，接口三类要求逐端点模板而本单无 admin 端点可列）。唯一新增的是 Quartz 桥接用的内部端点 POST /internal/fleet/jobs/share-member-dangling-reconcile/run，只由 hl-user-service 的定时任务经 X-Internal-Token 调用，不经网关、前端不可达，故不单列后端 changelog 条目。gateway_status=verified 指共用关系确认端点 POST /admin/fleet/group-dispatch/batches/{groupBatchId}/share-groups 经测试网关实测通过（2026-09-20 在团期 2101174125761265666 上连建车、司机两个维度的关系，库内复核两组成员行均指向同一张最新派单行）。frontend_status=not_required：响应字段与结构不变，前端无需改调用；但 members[].sourceId 的取值行为变了（见第二节），任何把它缓存/固化的前端逻辑需要复核。 前端实证维持 not_required(mmg 2026-09-20):share-groups/shareGroups 全仓零命中,共用关系功能前端未接入(#7444 交接件未到件),members[].sourceId 取值行为变化零消费面;无缓存/固化该值的逻辑。"
updated_at: "2026-09-20"
base: "dev-v3"
---

# fleet: 团期车辆共用关系跨维度确认后成员行跟随最新派单行 + 每日悬挂核对任务 1045

> **服务**: hl-fleet-service（改绑与核对逻辑）/ hl-user-service（任务注册 1045）
> **PR**: [#8029](https://git.1814.love:8443/wx/HL/pulls/8029)
> **Issue**: [#8003](https://git.1814.love:8443/wx/HL/issues/8003)
> **日期**: 2026-09-20
> **影响范围**: 无对外接口变化；共用关系详情里 `members[].sourceId` 在跨维度确认后会指向最新那张派单行

---

## ⚠️ 关键变化

- **本单没有任何可调用的新接口**：admin 侧没有新增、修改、删除端点，请求参数、响应字段、枚举、路径全部不变。
- **同一批成员先后建「车维度」和「司机维度」两个共用关系时，两个关系的成员身份现在指向同一张派单行**。
  此前第二次确认只更新它自己那个维度，先建的那个维度会一直指着一张已经作废的派单。
- **新增每日定时任务 1045「共用关系成员悬挂核对」**（每天 `04:10`），只巡检、只记日志，**不改任何业务数据**。
- **前端不需要改任何调用**，但要知道：`GET /admin/fleet/group-dispatch/batches/{groupBatchId}/share-groups`
  返回的 `members[].sourceId` 会在成员被重新派车后换成新值，**不能把它当成稳定标识长期缓存**。

---

## 一、原先的现象

确认共用关系时，如果某个成员当前还没占着这辆共用车（或这名共用司机），后端会替它走一次改派
把它派进来。**改派是「作废旧的派车记录、生成一张新的」**，派车记录的 ID 必然换新。

一户成员可以同时在两个关系里：一个是「共用这辆车」，另一个是「共用这名司机」。
过去第二次确认只把**它自己那个维度**的成员身份更新成新的派车记录，先建的那个维度仍记着旧的那张
——而旧的那张此刻已经作废。结果是：

- 关系的成员名单里挂着一个**已经不存在的派车记录**；
- 这户真正在跑的那张派车记录，反而不在那个关系的成员名单里。

对使用者当时不可见（冲突校验会跳过已作废的记录，所以不会误判、不会报错），
但凡是按「这个关系有几个成员」计数的地方都会多算一个。

## 二、现在的行为

| 场景 | 原来 | 现在 |
|------|------|------|
| 先建车维度关系，再建司机维度关系 | 车维度成员仍指向被作废的派车记录 | 两个维度的成员都指向同一张、当前在跑的派车记录 |
| 关系详情里的 `members[].sourceId` | 可能是一个已作废的派车记录 ID | 始终是当前在跑的那张 |
| 关系的活跃成员数 | 可能把同一户算两次（旧 ID 一次、新 ID 一次） | 与真实成员数一致 |

**响应结构没有任何变化**，变的是 `members[].sourceId` 的取值：

```jsonc
// GET /admin/fleet/group-dispatch/batches/2101174125761265666/share-groups?serviceDate=2027-01-06
// 车维度关系（359966491308855296）——下面这个 sourceId 就是修复后的取值
{
  "code": 200,
  "message": "成功",
  "data": [
    {
      "shareGroupId": "359966491308855296",
      "resourceType": "VEHICLE",
      "resourceId": "2065329519232720897",
      "status": "ACTIVE",
      "members": [
        { "sourceType": "GROUP_DISPATCH", "sourceId": "2101174278589190146", "requirementId": null,             "orderId": null },
        { "sourceType": "ASSIGNMENT",     "sourceId": "359966520803201024",  "requirementId": "7330996163649609", "orderId": "2101174125723516929" }
      ]
    }
  ]
}
```

修复前这一格会停在 `359966492122550272`（已作废的那张），修复后是 `359966520803201024`（当前在跑的那张），
与司机维度关系里那一格完全相同。

**给前端的一句话**：`sourceId` 是「这户当前挂的那张派车记录」，会随改派变化；
要长期标识一户成员请用 `requirementId`（用车需求 ID，跨改派不变）或 `orderId`。

## 三、新增定时任务 1045「共用关系成员悬挂核对」

| 任务 | 时间 | 做什么 | 会不会改数据 |
|------|------|--------|--------------|
| 1045 共用关系成员悬挂核对 | 每天 `04:10` | 巡检全部在关系里的成员，找出那些指向**已作废/已不存在**派车记录的 | **不会**，只记日志并返回条数 |

- **只发现、不处置**：一条这样的记录，可能该改绑到新的派车记录、也可能该退出关系，
  从记录本身分辨不出，自动猜错方向会把车务人工确认过的关系悄悄改掉。所以任务只把它们报出来，由人处置。
- 任务的结果在 fleet 服务日志里按关系汇总（`共用关系存在悬挂成员行: shareGroupId=... 悬挂行数=...`），
  并作为返回值回给调度侧的执行日志。
- 任务不对前端暴露任何接口，前端无需感知。

## 四、测试服实测（2026-09-20）

| 项 | 实测 |
|---|---|
| 连建车、司机两个维度的关系（团期 `2101174125761265666` / `2027-01-06`） | 两次确认均 `code=200`；库内复核两个关系的成员行 `source_id` 同为 `359966520803201024`，被作废的 `359966492122550272` 上无任何在关系中的成员 |
| 定时任务 1045 | `sys_job` 已注册且 `ACTIVE`，cron `0 10 4 * * ?`；两个 fleet 实例各触发一次均 `code=200` |
| 核对结果与库读数对账 | 存量处置前 **4** → 处置 2 条后 **2** → 新建两个关系后仍 **2**（新关系零悬挂），每一次都与同口径 SQL 读数相同 |

存量：测试服清查出的历史遗留记录共 4 条，已处置 2 条（改绑到当前在跑的派车记录），
另 2 条因对应需求当日已无在途派车记录而保留待人工判断，任务会继续把它们报出来。

---

## 五、前端要不要动

**不需要**。响应结构、字段名、枚举、路径、错误码全部不变。唯一需要知悉的是第二节末尾那句：
`members[].sourceId` 不是稳定标识，不要缓存或用它做跨请求的比对，要稳定标识用 `requirementId` / `orderId`。