3.5 KiB
二期 v3：修复服务标准条目 remark/color/contactName/phone 四字段下单时丢失（恒为 null）
服务: hl-order-service-v3 PR: #3295 Issue: #3294 日期: 2026-06-01 影响: 🟢 缺陷修复，无契约变更。订单详情「服务标准」Tab 的条目，此前
remark/color/contactName/phone四字段因后端缺陷恒为null，本次修复后新建订单会正确返回这四个字段的真实值。响应结构不变，前端无需改代码，原本就该读这四字段的渲染逻辑现在能拿到数据。
总览（前端 mmg 必读）
接续 PR #3254/#3255/#3256（服务标准模板改 6 字段），那一期把产品侧服务标准升级到 6 字段条目，但下单写订单快照的中间环节漏跟进：
订单详情服务标准来自下单时冻结的产品快照（order_product_snapshot）。该快照由订单服务接收产品 Feign 数据后整体序列化，但订单侧接收用的 VO 还停留在旧 3 字段（title / content / contact），导致产品发来的 remark / color / contactName / phone 在反序列化时被静默丢弃，冻进快照只剩 title + content。
结果：所有订单详情服务标准 Tab 的条目这 4 个字段恒为 null。本次补齐订单侧 VO 字段，使整条服务标准 6 字段完整进快照。
受影响接口（响应行为修正，无字段增减）
GET /v3/admin/order/{id}/service-standard
响应 data.serviceStandard.sections[].items[] 条目，6 字段修复前后对比：
// 修复前（4 字段恒 null）
{
"title": "专业司机",
"content": "持有A1驾照,8年以上驾龄",
"remark": null, // ❌ 恒 null
"color": null, // ❌ 恒 null
"contactName": null, // ❌ 恒 null
"phone": null // ❌ 恒 null
}
// 修复后（新建订单）
{
"title": "专业司机",
"content": "持有A1驾照,8年以上驾龄",
"remark": "仅限指定时段", // ✅
"color": "#FF6600", // ✅
"contactName": "李师傅", // ✅
"phone": "13800000000" // ✅
}
字段名、类型、嵌套层级完全不变，仅是原本恒 null 的值现在有了真实数据。
重要边界：只对「新建订单」生效
- 快照是下单时间点的冻结值，修复部署前已生成的历史订单快照仍只有
title+content，这 4 字段对老订单仍为null（不回填，符合快照语义）。 - 修复部署后新建的订单，服务标准 6 字段完整。
- 前端渲染需对这 4 字段做
null容错（老订单仍可能为 null），有值即展示。
测试服验证（已通过）
部署 dev-v3 后端到端实测：建含 6 字段服务标准模板的产品订单 → GET .../service-standard 与 DB 快照 snapshot_content 双查，6 字段（含 remark/color/contactName/phone）全部正确返回。
影响评估
- 后端：hl-order-service-v3 改 1 个传输 VO（
ProductDetailVO.ServiceStandard.Item补 4 字段、删废弃contact）+ 1 个端到端回归测试。无 DB 改动，重启生效。 - 前端：无需改代码，原服务标准 Tab 条目渲染逻辑现在能拿到 4 个新字段值。
- mp 端：本次未涉及。