docs(changelog): 团期详情配房/配车明细更新时间列恒为空（前端优化）

changelogs-v2/2026-09/24_frontend_团期详情配房配车明细更新时间列恒为空-前端优化-管理后台.md

@@ -0,0 +1,63 @@
+---
+schema: "hl-changelog/v2"
+ticket: "frontend"
+title: "团期详情「配房 / 配车」明细的“更新时间”列恒为空，建议隐藏该列或补真实时间源"
+consumer: "admin"
+author: "wx(GIT)"
+change_type: "前端优化"
+backend_status: "not_required"
+gateway_status: "not_required"
+frontend_status: "pending"
+frontend_owner: "mmg"
+frontend_ref: ""
+target_release: ""
+verified_at: ""
+status_note: "浏览器实测（测试服 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 同款（“六状态列无独立时间戳”）。该列对房/车两块芯片永远渲染不出值，属纯前端展示问题，无需后端改动。"
+updated_at: "2026-09-24"
+base: "dev-v3"
+---
+
+# 团期详情 · 配房/配车明细「更新时间」列恒为空
+
+> **端**: 管理后台 ｜ **页面**: 团期详情 → 配房 / 配车 ｜ **Issue**: 无（前端展示优化，已核实无需后端改动）
+
+---
+
+## 一、现象（浏览器实测）
+
+测试服 `https://web.test.1814.love` → 团期详情 `2102981652823302146`（4 户）：
+
+- **配房** tab：表头为 `联系人 | 订单号 | 人数 | 状态 | 更新时间`，四行（甲/乙/丙/丁）的「更新时间」**全部显示为「—」**；
+- **配车** tab：同一表格结构，四行「更新时间」**同样全部为「—」**（含状态已经是「配房完成」「配车完成」的两户）。
+
+截图见本次浏览器测试留档。
+
+## 二、根因（后端契约已核实，不是偶发渲染）
+
+两个芯片明细接口对每一户返回的 `updateTime` **恒为 null**：
+
+```json
+{ "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）、聚合态与完成计数、房务/车务的实际操作链路。