防止JavaScript数字精度丢失的关键是根据数据类型选择合适方案：大整数用BigInt或字符串，小数用decimal.js等库处理，展示类可容忍误差时用.toFixed()格式化。
防止 JavaScript 数字变量精度丢失，核心是避开 Number 类型的固有缺陷——它基于 IEEE 754 双精度浮点数，无法精确表示大多数十进制小数，且整数安全上限仅为 ±9007199254740991（即 253−1）。一旦超出这个范围或参与小数运算，误差就会产生。关键不是“修复 Number”，而是根据数据类型和业务场景，选择合适的数据形态与处理路径。
区分数据用途：大整数用 BigInt，小数用字符串+高精度库
先判断你处理的是哪类数字：
-
ID、时间戳（毫秒级）、订单号、密码学整数：只要可能 ≥ 253，一律视为“大整数”，全程使用
BigInt或字符串； -
金额、百分比、测量值等带小数的业务数值：本质是十进制小数，不能依赖
Number运算，应转为字符串交给decimal.js或bignumber.js处理； -
纯展示或简单比较（如 UI 上显示“约 1.23 万”）：可容忍微小误差，用
.toFixed()或.toLocaleString()格式化，但注意它们返回字符串，不改变底层值。
大整数：从源头保持字符串或 BigInt
后端返回的 long 型字段（如 Java 的 Long）绝不能直接 JSON 解析成 Number——这是最常见也是最容易被忽略的精度丢失入口。
- 后端序列化时将大整数转为字符串（如 Spring Boot 中配置
@JsonSerialize(using = ToStringSerializer.class)）； - 前端接收后，始终以字符串形式存储、传递、渲染；仅在必要计算时用
BigInt(str)构造，且整个运算链路只用BigInt（例如id1n + id2n），避免混入Number（如Number(id1n)会立刻失真）； - 需要 JSON 传输时，手动转成字符串：
JSON.stringify({ id: myId.toString() })，接收端再BigInt(data.id)恢复。
小数运算：绕过二进制，用十进制模拟
0.1 + 0.2 !== 0.3 不是 bug，是二进制表示的必然结果。解决思路是彻底脱离 Number 的运算流程：
立即学习“Java免费学习笔记（深入）”；
- 所有输入必须是字符串：
new Decimal('0.1').plus('0.2')，禁止传new Decimal(0.1)（误差已在构造时引入）； - 金额类固定小数位场景，可用“整数放大法”：统一乘以 100 转整数运算，结果再除以 100，但需确保放大后不超过
Number.MAX_SAFE_INTEGER（约 9e15）； - 避免连续浮点运算链，能合并的步骤尽量合并（如
a * b + c比(a * b) + c累积误差更小，但仍不如 decimal.js 可靠）。
比较与显示：用容差代替严格相等
当无法避免使用 Number（如第三方 API 返回、DOM 属性读取），又需逻辑判断时：
- 浮点数相等比较不用
===，改用容差：Math.abs(a - b) 或自定义阈值（如 <code>1e-10）； - 显示时优先用
.toFixed(n)控制位数，但注意它对1.005这类边界值可能截断而非四舍五入；更稳妥可用Math.round(num * Math.pow(10, n)) / Math.pow(10, n)； - 不要对
Number做多次parseFloat或toString()转换，每次转换都可能引入新误差。
