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