JavaScript对象与JSON互转时精度问题主要在数字类型：大整数超安全整数范围（9007199254740991）会丢失精度，BigInt不被原生支持，浮点数如0.1+0.2误差会被固化；解决方案包括敏感数字转字符串传输、自定义replacer/reviver处理、金额用整数单位等。
JavaScript中对象与JSON字符串互相转换时，精度问题主要出现在数字类型上，尤其是超出JavaScript安全整数范围（Number.MAX_SAFE_INTEGER = 9007199254740991）的大整数，以及含小数的浮点数在序列化/反序列化过程中可能发生的隐式舍入。
大整数在JSON中会丢失精度
JSON规范本身不区分整数和浮点数，所有数字都按IEEE 754双精度浮点格式解析。当JavaScript将一个超过 2⁵³ − 1 的整数（如9007199254740992）转为JSON字符串再解析回来时，可能变成相邻的可表示值（例如9007199254740992 → 9007199254740992看似没变，但9007199254740993会变成9007199254740992）。
- 前端接收到后端传来的超长用户ID（如MongoDB ObjectId或雪花ID）时，若直接
JSON.parse()，可能被截断或错误四舍五入 -
JSON.stringify({ id: 9007199254740993n })会报错（BigInt不能被原生JSON处理），必须手动转换 - 解决方案：对敏感大整数字段，统一用字符串传输（如
{ "id": "9007199254740993" }），解析后保持字符串类型，业务层按需转为 BigInt 或继续以字符串操作
小数的浮点表示误差会被固化
像 0.1 + 0.2 === 0.30000000000000004 这类误差本就存在，而 JSON 序列化会把该数值“拍平”成最短可精确表示的十进制字符串（如 0.30000000000000004 可能被存为 0.30000000000000004 或 0.3，取决于引擎实现），反序列化后无法恢复原始计算上下文。
-
JSON.stringify(0.30000000000000004)通常输出"0.30000000000000004"，但某些环境可能简化为"0.3" - 涉及金额、科学计算等场景，应避免直接用 Number 存储小数，改用整数单位（如“分”代替“元”）或专用库（如
decimal.js） - 若需保留原始小数位数（如后端返回
"0.10"），应让后端以字符串形式传输该字段，而非数字
自定义序列化/反序列化可缓解精度问题
通过 JSON.stringify 的 replacer 参数和 JSON.parse 的 reviver 参数，可以拦截关键字段做特殊处理。
立即学习“Java免费学习笔记（深入）”；
- 序列化时将
BigInt转为字符串：JSON.stringify(obj, (k, v) => typeof v === 'bigint' ? v.toString() : v) - 反序列化时识别特定字段名（如
"id"、"amount"）并转为 BigInt 或 Decimal：JSON.parse(json, (k, v) => k === 'id' ? BigInt(v) : v) - 注意：
reviver对嵌套结构需递归判断；生产环境建议封装成可复用的工具函数，避免散落逻辑
Date、undefined、Function 等非JSON类型也会导致信息丢失
虽然不属于“精度”范畴，但常被误认为精度问题：JSON标准只支持 null、boolean、number、string、array、object 六种类型。
-
Date对象序列化后变成 ISO 字符串，JSON.parse不会自动还原为 Date 实例 -
undefined、function、Symbol、Map、Set在JSON.stringify中被忽略或报错 - 若需保真传输，应统一约定序列化规则（如给 Date 加
$date标记），并在 reviver 中还原
