javascript数值精度问题源于ieee 754双精度浮点限制，非bug而是设计取舍；金额计算应转整数单位（如元→分）全程整数运算；通用小数需封装位数对齐函数；高精度场景用decimal.js或bignumber.js；超大整数用bigint并注意安全边界。
JavaScript 数值计算的精度问题本质是 IEEE 754 双精度浮点表示的固有限制，不是 bug，而是设计取舍。要保障结果可靠，关键不在“绕开”，而在“选对策略”——根据场景匹配方法。
金额类计算：统一用整数单位处理
金融、电商等对误差零容忍的场景，最稳妥的做法是主动规避浮点参与运算。
- 把元转为分、美元转为美分，所有输入、中间计算、存储都使用整数
- 加减乘除全程在整数域完成，不出现小数点
- 仅在最终展示时除以 100，并配合 toFixed(2) + parseFloat 格式化
- 示例：0.99 元 + 1.5 元 → 99 分 + 150 分 = 249 分 → 显示为 (249 / 100).toFixed(2) → "2.49"
通用小数运算：封装带位数对齐的安全函数
当需支持任意小数（如配置系数、权重、比例）且不能改业务单位时，可封装加减乘除函数，自动提取最大小数位数并放大还原。
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
下载
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 核心逻辑：找出 a、b 的小数位数，取最大值 n，用 Math.pow(10, n) 放大后整数运算
- 避免直接用 toFixed 修复中间值，因为 toFixed 本身也有精度陷阱（如 1.005.toFixed(2) 得 1.00）
- 推荐实现中保留原始字符串或科学计数法解析，比单纯乘除更鲁棒
- 不建议手写复杂逻辑，可参考 number-precision 等轻量库的思路
高精度/复杂表达式：引入 decimal.js 或 bignumber.js
涉及多位小数连续运算、幂、开方、比较、科学计数，或需要严格十进制语义（如会计准则要求），必须用专业库。
- decimal.js：API 清晰、默认十进制、支持 setPrecision、toDecimalPlaces、isGreaterThan 等，适合金融系统
- bignumber.js：更轻量，兼容性好，适合前端资源敏感项目
- 两者均支持链式调用、不可变对象、自定义舍入模式（四舍五入、向上取整、银行家舍入等）
- 注意：所有数值需显式构造，new Decimal('0.1').plus('0.2') 比 new Decimal(0.1) 更安全（避免字面量已失真）
超大整数与安全边界：BigInt 与 Number 安全范围识别
当数字超过 ±9,007,199,254,740,991（即 Number.MAX_SAFE_INTEGER），普通 Number 类型不再能精确表示相邻整数。
- 身份证号、长 ID、加密哈希值等纯整数大数，应使用 BigInt（末尾加 n），如 123456789012345678901234567890n
- BigInt 不支持小数，也不能和 Number 混合运算，需统一类型或显式转换
- 日常开发中可用 Number.isSafeInteger(val) 快速判断是否处于安全整数范围内
- 大数运算若含小数，仍应回到 decimal.js 而非 BigInt
