JavaScript数字精度问题源于IEEE 754双精度浮点数无法精确表示十进制小数，如0.1+0.2≠0.3；解决需分场景：金融用decimal.js等高精度库，展示用toFixed()或Math.round()缩放，运算优先转整数；禁止直接用==/===比较浮点数，应采用误差容忍判断。
JavaScript 数字精度问题本质是二进制浮点数表示缺陷
JavaScript 所有数字都用 Number 类型（IEEE 754 双精度浮点数）存储，无法精确表示大多数十进制小数。比如 0.1 + 0.2 不等于 0.3，而是 0.30000000000000004。这不是 JS 独有，而是所有遵循 IEEE 754 的语言共性，但 JS 没有原生整数类型或小数类型，暴露更直接。
避免小数计算误差的三种实操路径
没有银弹，需按场景选：金融计算必须用高精度库；UI 展示可四舍五入；简单逻辑判断应改用整数运算。
- 金融/金额类计算：用
decimal.js或big.js，它们基于字符串实现十进制算术const Decimal = require('decimal.js'); const a = new Decimal('0.1'); const b = new Decimal('0.2'); console.log(a.plus(b).equals('0.3')); // true - 展示用的浮点结果：用
toFixed()或Math.round()配合缩放，但注意它返回字符串，且toFixed()在某些浏览器对1.005会返回"1.00"（非预期四舍五入）console.log((0.1 + 0.2).toFixed(1)); // "0.3" console.log(Math.round((0.1 + 0.2) * 10) / 10); // 0.3
- 能转整数就转整数：价格统一用“分”为单位，时间用毫秒，避免小数参与运算
const priceInCents = 199; // 而不是 1.99 const discountInCents = 20; const finalInCents = priceInCents - discountInCents; // 179 → 显示时除以 100
警惕 == 和 === 对浮点数的直接比较
直接用等号判断两个浮点运算结果是否相等，几乎必然出错。哪怕你用 toFixed() 处理过，返回的是字符串，和数字比较也会隐式转换出偏差。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 永远不要写
if (a + b === 0.3) - 改用误差容忍比较：
Math.abs(a + b - 0.3) （<code>EPSILON约2.22e-16，适合一般场景） - 对业务敏感值（如金额），优先走整数比较或高精度库的
.equals()方法
JSON 序列化和后端交互时精度可能二次丢失
JSON.stringify() 会把 Number 原样转成字符串，但若后端解析为 float/double，同样面临精度问题。尤其当 JS 传 { amount: 0.1 }，后端收到可能是 0.10000000000000000555。
立即学习“Java免费学习笔记（深入）”；
- 前后端约定金额字段统一用字符串传输，例如
{"amount": "19.99"} - 避免在 JS 中用
parseFloat()解析后端返回的金额字符串，直接用高精度库构造 - 如果必须用数字，确保后端使用
BigDecimal（Java）、Decimal（Python）等十进制类型接收
实际项目里最容易被忽略的是：把 toFixed() 当作“修复精度”的万能解，但它只是格式化输出，内部值没变；还有就是测试时用整数常量验证逻辑，上线后换成用户输入的小数就崩了。
