JavaScript数值处理需按场景取舍：超大整数用BigInt（如123n），不可与Number混用；小数运算应转整数单位（如“分”）或用误差范围比较，避免0.1+0.2≠0.3问题。
JavaScript 数值处理的核心矛盾在于：语言原生的 Number 类型（IEEE 754 双精度浮点）既无法安全表示超大整数，也无法精确表达多数十进制小数。最佳实践不是追求“一种通用解法”，而是根据场景在安全边界、精度需求、运行性能三者间做明确取舍。
区分整数与小数，选对底层类型
整数运算超出 Number.MAX_SAFE_INTEGER（9007199254740991）就不可信，此时必须用 BigInt：
- 用
123n或BigInt("123")创建，不能和普通数字混用（10 + 20n报错） - 支持
+、-、*、**、%，但除法/会自动截断小数，不返回小数结果 - 适合 ID、计数器、加密哈希、大整数运算等纯整数场景
小数运算（如金额、比例、科学计算）则天然存在 0.1 + 0.2 !== 0.3 问题，BigInt 不适用，需转向高精度十进制库或策略性规避：
- 金融类：统一转为“分”或“最小货币单位”用整数计算（例如
1999代表 ¥19.99），全程避免小数 - 展示层：用
.toFixed(n)格式化输出，但注意它返回字符串，且四舍五入逻辑需确认（如1.005.toFixed(2) === "1.00"） - 比较判断：不用
===，改用误差范围，如Math.abs(a - b)
高精度场景优先选用成熟库，而非自行封装
当业务明确要求任意精度（如银行利息复利、区块链余额、物理模拟），应直接集成经过充分验证的库，而非用 parseFloat(toFixed()) 等简单封装应付：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- decimal.js：功能最全，支持任意精度、丰富数学函数（sin/log/pow）、链式调用，适合金融与科学计算
- bignumber.js：更轻量，API 简洁，兼容性好（ECMAScript 3），适合前端嵌入与长期维护项目
- 避免使用已停止维护的
big.js（注意名称拼写差异）
所有库都要求显式创建实例（如 new Decimal("0.1")），字符串初始化是关键——传 0.1 仍会带入原始浮点误差。
性能敏感场景下，接受可控妥协
并非所有地方都需要 100% 精确。在动画、渲染、实时游戏、日志统计等对吞吐量要求高的环节，可合理降级：
- 用
Math.round(x * 100) / 100快速保留两位小数，比调用库快一个数量级 - 大数组数值聚合（如求和、均值）优先用原生
for循环，避免reduce闭包开销 - 仅对最终用户可见/影响决策的关键值（如付款金额、库存余量）做严格精度保障，中间计算允许微小误差
建立基础校验与防御习惯
很多精度问题其实在源头就能拦截：
- 输入阶段就用
Number.isFinite()和Number.isSafeInteger()做初步过滤 - 后端返回大整数 ID 时，明确要求以字符串形式传输（避免 JSON 自动转成不安全的
Number） - 全局搜索代码中所有
==或===比较浮点数的地方，替换为带容差的判断 - 单元测试必须覆盖边界值：如
MAX_SAFE_INTEGER ± 1、0.1 + 0.2、极小数乘法等
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
