JavaScript处理64位ID时精度丢失必然发生，因Number仅安全表示±2⁵³−1内整数；BigInt是唯一可靠原生方案，但需配合json-bigint等库或字符串化传输规避JSON限制。
JavaScript 中处理 64 位整型 ID（如雪花 ID）时，精度丢失不是“会不会发生”的问题，而是“何时暴露”的问题。因为 Number 类型只能安全表示 ±253−1 范围内的整数，而典型雪花 ID（如 13579246810111213）早已超出该范围——解析后末位悄然变更，却无任何报错提示。
为什么 BigInt 是前端唯一可靠的原生方案
BigInt 是 ECMAScript 2020 正式引入的原始类型，专为任意精度整数设计。它不参与 IEEE 754 浮点运算，可精确表示 64 位甚至更大整数。但关键在于：它不能直接用于 JSON.parse / JSON.stringify，需配合定制解析逻辑才能落地。
- JSON 标准本身不支持 BigInt，原生
JSON.stringify(BigInt(123))会抛出 TypeError - 浏览器内置
JSON.parse()永远返回 Number，无法绕过——这是 JS 引擎层限制，后端或中间件无法干预 - 因此，防护必须从前端接收响应那一刻开始：拦截原始字符串，跳过默认解析，改用支持 BigInt 的解析器
在 Axios 或 Fetch 中集成 json-bigint
json-bigint 是目前最成熟、零依赖的解决方案，它重写了 JSON 解析逻辑，将超限整数自动转为 BigInt（可选），同时保持对标准 JSON 的完全兼容。
- 安装：
npm install json-bigint - Axios 全局配置示例：
axios.defaults.transformResponse = [(data) => {
if (typeof data === 'string') {
try {
return JSONbig({ storeAsString: false }).parse(data); // 返回 BigInt
} catch (e) {
return JSON.parse(data);
}
}
return data;
}];
- 注意：
storeAsString: false启用 BigInt；设为true则返回字符串（适合后端未适配 BigInt 的场景） - 若服务端已将 ID 字段统一改为字符串（如
"id": "13579246810111213"），则无需 BigInt，直接用字符串比对更稳妥
手动解析 + BigInt 安全兜底
当无法引入第三方库，或需精细控制字段时，可对响应体做轻量级预处理：
- 用正则识别疑似大整数字段（如
"id":\s*\d{17,}），将其包裹引号转为字符串，再调用JSON.parse() - 或使用
JSON.parse(text, (key, value) => typeof value === 'number' && value > 9007199254740991 ? BigInt(value.toString()) : value)——但此法有风险：value 在进入 reviver 前已被转为 Number，**原始精度已在解析第一毫秒丢失**，不可取 - 真正安全的做法是：先用
JSON.parse(text, (k, v) => typeof v === 'string' && /^\d{17,}$/.test(v) ? BigInt(v) : v)，前提是后端已发字符串格式 ID
前后端协同才是根治关键
单靠前端用 BigInt 只是补救。真正健壮的方案需两端约定：
- 后端对所有可能超
2^53−1的字段（ID、时间戳微秒值、金额等），**强制序列化为字符串**，并在 OpenAPI 文档中标注type: string, format: int64 - 前端收到字符串后，按需转
BigInt（计算/比对）或保持字符串（渲染/传参），避免隐式转换 - 数据库与 ORM 层同步调整：如 Golang 结构体字段声明为
Id string `json:"id"`，或使用json.Number+.String()输出，确保 JSON 输出始终是字符串
