hl-api-changelog/changelogs-v2/2026-09/24_frontend_团期详情配房配车明细更新时间列恒为空-前端优化-管理后台.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	frontend	团期详情「配房 / 配车」明细的“更新时间”列恒为空，建议隐藏该列或补真实时间源	admin	wx(GIT)	前端优化	not_required	not_required	verified	mmg	6e6fe48982e6b39f01aba5f5c1236437f999b7de	v2.1	2026-09-24	浏览器实测（测试服 web.test.1814.love，2026-09-24 17:0x，团期 2102981652823302146，4 户）：团期详情 → 配房 / 配车 两个芯片明细列表的“更新时间”列四行全部为「—」。对照后端契约：GET /v3/admin/order/group-batch/{groupBatchId}/chips/hotel 与 /chips/vehicle 的 items[].updateTime 恒为 null；后端源码 GroupBatchChipResolver#toItem 明确注释“无状态时间列时 updateTime=null”，ChipItem.updateTime 字段 javadoc 同款（“六状态列无独立时间戳”）。该列对房/车两块芯片永远渲染不出值，属纯前端展示问题，无需后端改动。 前端已交付并验证：ChipItemsTable 更新时间列改数据驱动显隐——全行 updateTime 为 null（房/车契约恒 null）整列不渲染，任一行有真值（约/保）出列截到分钟直显；不读 chipLabel 判芯片，禁拿 status-logs 凑值；列表弹层 ChipDetailModal 共用同组件自动生效。ChipStaffDisplay spec 7 例全绿（新增 2 例），hl-admin@6e6fe489。	2026-09-24	dev-v3

团期详情 · 配房/配车明细「更新时间」列恒为空

端: 管理后台 ｜ 页面: 团期详情 → 配房 / 配车 ｜ Issue: 无（前端展示优化，已核实无需后端改动）

---

一、现象（浏览器实测）

测试服 https://web.test.1814.love → 团期详情 2102981652823302146（4 户）：

• 配房 tab：表头为 联系人 | 订单号 | 人数 | 状态 | 更新时间，四行（甲/乙/丙/丁）的「更新时间」全部显示为「—」；
• 配车 tab：同一表格结构，四行「更新时间」同样全部为「—」（含状态已经是「配房完成」「配车完成」的两户）。

截图见本次浏览器测试留档。

二、根因（后端契约已核实，不是偶发渲染）

两个芯片明细接口对每一户返回的 updateTime 恒为 null：

{ "orderId": "2102981652680695809", "teamNo": "26-6045",
  "status": "PENDING", "statusText": "待车务配", "updateTime": null }

后端源码（hl-order-service-v3）两处写死这一口径：

• GroupBatchChipResolver#toItem 注释：「单户逐户派生（status 按芯片口径，无状态时间列时 updateTime=null）」，构造实参直接传 null；
• GroupBatchChipResolver.ChipItem.updateTime 字段 javadoc：「该项最后变更时间；无独立来源列时为 null（六状态列无独立时间戳）」。

也就是说：房/车两块芯片的状态取自 order_main.room_control_status / vehicle_control_status 等六状态列，这些列没有配套的时间戳列，所以该字段在契约上永远是 null。要让它有值必须后端补数据源（新增列或改用状态流转日志），不在本条目范围。

三、建议（前端）

两条路都不需要后端配合，推荐第一条：

1. （推荐）对房/车两块芯片隐藏「更新时间」列：若该表格组件同时服务约/保等芯片，可按 chipLabel 动态隐藏，或按「本页所有行 updateTime 皆为 null 时不渲染该列」，避免一整列永远只有「—」的占位列；
2. 若产品要求保留该列，则应先由后端补时间源；在当前契约下保留该列只会持续展示空值。

配套约束：不要在前端用 status-logs 等接口的最近一条时间「近似凑值」——那会让同一列在不同芯片上口径不一致（约/保是真值、房/车是近似值），排查成本比留空更高。

四、影响范围

• 仅展示：团期详情 → 配房 / 配车 两个 tab 的明细表格列。
• 零影响：接口契约与字段结构（updateTime 仍按契约返回 null）、聚合态与完成计数、房务/车务的实际操作链路。