docs(changelog): 司机续签生成链接报targetDriverId格式错误-前端雪花id传成科学计数法丢精度,后端实测整数字符串/数字均正确无需改 [前端BUG·P0]

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

changelogs-v2/2026-06/15_司机续签生成链接报targetDriverId格式错误-前端雪花id传成科学计数法-前端BUG.md

@@ -0,0 +1,34 @@
+# 【前端BUG·司机续签】续签「生成链接」报「targetDriverId 格式错误」：前端把雪花司机 id 传成了科学计数法（精度丢失），应作字符串原样透传
+
+> 端：hl-ui（车务管理 → 司机自助录入 → 「2026 赛季续签」tab，fleet 二期）| 严重度：**P0**（续签生成链接整功能不可用）| 后端测试服实测正确、**无需改动** | 2026-06-15
+
+## ⚠️ 现象
+
+「2026 赛季续签」选中司机（如吴师傅）点「生成链接」→ 顶部红条报 **400「请求数据格式错误：字段 [targetDriverId] 格式错误」**，链接生不出来。
+
+## 根因（后端实测复现，确认是前端传值格式问题）
+
+对 `POST /admin/fleet/h5/token` 的 `targetDriverId` 逐格式实测（测试服网关，真 admin token）：
+
+| 前端传的值 | 后端结果 |
+|---|---|
+| `"1916000000000000001"`（整数字符串）| ✅ 正常解析（进业务，返 600205 司机不存在）|
+| `1916000000000000001`（数字）| ✅ 正常解析 |
+| `""`（空字符串）| ✅ 按 null 处理（全局 Jackson 空串→null）|
+| **`"1.916e18"`（科学计数法字符串）** | ❌ **400「targetDriverId 格式错误」← 与线上报错完全一致** |
+| `1916000000000000001.0`（小数）| ✅ 解析（截断）|
+
+**结论：前端把 19 位雪花司机 id 当成 JS Number 处理，丢了精度并序列化成了科学计数法字符串（`1.9..e18`）**，后端无法把它还原成精确 Long → 报格式错误。
+
+- 后端对「整数字符串 / 数字」都能正确接收，**后端无需改动**。
+- 后端**不应**接受科学计数法：到那一步 id 已经丢精度，硬收会查到错误的司机，必须由前端在源头保住精度。
+
+## 前端修法
+
+- `targetDriverId` **全程当字符串透传**：司机列表接口返回的 id 本就是字符串（后端对 > 2^53 的雪花已序列化为 String），前端**别 `Number()` / `parseFloat()` / `+id` / 算术运算**，原样塞进 generate 请求体。
+- 自查：生成请求 payload 里 `targetDriverId` 应是 `"1916xxxxxxxxxxxxxxx"` 这种纯数字字符串，**不是** `1.9e18`、也不带小数点。
+- 同类风险点排查：续签司机选择卡片绑定 id、其它带雪花 id 的请求体字段，统一按"字符串透传、不入数字类型"处理。
+
+## 验收
+
+「2026 赛季续签」选司机 → 生成链接 → 应正常返回 token / 二维码 / 短链，不再报「targetDriverId 格式错误」。