2.4 KiB
2.4 KiB
【前端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 格式错误」。