From 0be57f0e615cda076f32f656fa9568074d90b6c6 Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Mon, 15 Jun 2026 10:16:12 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog):=20=E5=8F=B8=E6=9C=BA=E7=BB=AD?= =?UTF-8?q?=E7=AD=BE=E7=94=9F=E6=88=90=E9=93=BE=E6=8E=A5=E6=8A=A5targetDri?= =?UTF-8?q?verId=E6=A0=BC=E5=BC=8F=E9=94=99=E8=AF=AF-=E5=89=8D=E7=AB=AF?= =?UTF-8?q?=E9=9B=AA=E8=8A=B1id=E4=BC=A0=E6=88=90=E7=A7=91=E5=AD=A6?= =?UTF-8?q?=E8=AE=A1=E6=95=B0=E6=B3=95=E4=B8=A2=E7=B2=BE=E5=BA=A6,?= =?UTF-8?q?=E5=90=8E=E7=AB=AF=E5=AE=9E=E6=B5=8B=E6=95=B4=E6=95=B0=E5=AD=97?= =?UTF-8?q?=E7=AC=A6=E4=B8=B2/=E6=95=B0=E5=AD=97=E5=9D=87=E6=AD=A3?= =?UTF-8?q?=E7=A1=AE=E6=97=A0=E9=9C=80=E6=94=B9=20[=E5=89=8D=E7=AB=AFBUG?= =?UTF-8?q?=C2=B7P0]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- ...riverId格式错误-前端雪花id传成科学计数法-前端BUG.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 changelogs-v2/2026-06/15_司机续签生成链接报targetDriverId格式错误-前端雪花id传成科学计数法-前端BUG.md diff --git a/changelogs-v2/2026-06/15_司机续签生成链接报targetDriverId格式错误-前端雪花id传成科学计数法-前端BUG.md b/changelogs-v2/2026-06/15_司机续签生成链接报targetDriverId格式错误-前端雪花id传成科学计数法-前端BUG.md new file mode 100644 index 0000000..f701581 --- /dev/null +++ b/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 格式错误」。