JavaScript浮点运算不精确是因IEEE 754双精度格式无法精确表示十进制小数，如0.1+0.2≠0.3；应转整数运算或用差值比较替代直接相等判断。
JavaScript 的数字运算看似简单，但实际开发中常因浮点精度、类型隐式转换、大数溢出等问题导致结果出人意料。直接用 +、-、*、/ 并不总能得到你“以为”的结果。
浮点数计算为什么总是不准？
JavaScript 使用 IEEE 754 双精度浮点格式存储数字，这意味着很多十进制小数（如 0.1、0.2）无法精确表示，相加后出现 0.30000000000000004 这类结果是标准行为，不是 bug。
常见错误现象：0.1 + 0.2 === 0.3 返回 false；parseFloat('0.1') + parseFloat('0.2') 同样不准。
- 需要精确小数运算（如金额）时，优先转为整数运算：把元换算成分，
19.99 * 100 + 5.5 * 100 === 2549 - 临时容错可使用
Number((0.1 + 0.2).toFixed(10))，但注意toFixed返回字符串，需再Number() - 避免用
==或===直接比较浮点结果，改用差值判断：Math.abs(a - b)
parseInt 和 parseFloat 的坑在哪？
这两个函数不按直觉“取数字部分”，而是从字符串开头解析，遇到非法字符就停止，并且 parseInt 默认按十进制解析——除非字符串以 0x 开头（十六进制），或在旧环境里以 0 开头被误判为八进制。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：parseInt('08') === 0（ES5 以前）、parseInt('10px') === 10、parseInt('0x10') === 16。
- 始终显式传入基数：
parseInt('08', 10)、parseInt('10px', 10) - 想安全转数字，优先用一元加号：
+'10px'→NaN（更严格），或Number('10px')→NaN -
parseFloat不支持基数参数，但会忽略末尾非数字字符，适合处理带单位的长度值（如'2.5rem'→2.5）
大整数和 Number.MAX_SAFE_INTEGER 有什么关系？
JavaScript 中能“安全”表示的整数范围是 -(2^53 - 1) 到 2^53 - 1，即 Number.MAX_SAFE_INTEGER === 9007199254740991。超过这个值，++ 操作可能失效，相等判断不可靠。
常见错误现象：9007199254740991 + 1 === 9007199254740992 ✅，但 9007199254740992 + 1 === 9007199254740992 ❌（没变）。
- 涉及 ID、时间戳（毫秒级）、加密哈希等大数场景，应使用
BigInt：写成9007199254740992n或调用BigInt('9007199254740992') -
BigInt不能和普通number混合运算，1n + 1报错，必须统一类型 - JSON 不支持
BigInt，序列化前需手动转字符串或跳过
Math 函数哪些要特别注意？
Math 对象多数方法可靠，但几个容易误用：
-
Math.round()对负数的“四舍五入”是向零取整？错——它是“四舍六入五成双”？也不对。它只是四舍五入到最近整数，Math.round(-1.5)是-1（不是-2），因为 -1.5 距离 -1 和 -2 一样近时，JS 规定往正无穷方向舍入 -
Math.pow(0, 0)返回1，而数学上未定义；Math.sqrt(-1)返回NaN，不是Infinity -
Math.random()生成的是[0, 1)区间浮点数，要生成 [min, max] 整数，正确写法是Math.floor(Math.random() * (max - min + 1)) + min
真正麻烦的从来不是“怎么算”，而是“怎么算得既快又准还不出错”。尤其当输入来自用户、接口或 DOM 属性时，类型不确定 + 浮点误差 + 大数截断，三者叠加最容易在凌晨三点复现一个“明明测试过却线上崩了”的 case。
