JS处理大数或特殊值(NaN、Infinity)向下取整的结果

一、核心机制剖析：IEEE-754 标准取整与 ECMAScript ToInt32 的分流

JavaScript 的数字类型本质上是以 IEEE-754 64位双精度二进制浮点格式存储的。这意味着所有常规数值（除 BigInt 以外）都共享同一个数值空间，包括正常小数、极小值、极大值以及特殊的 NaN 和 ±Infinity。

当开发者执行向下取整时，主要有两种完全不同的技术路径：

1. 标准数学函数 Math.floor(x)：返回小于或等于给定数字的最大整数。该操作完全在 64 位浮点数语义下进行，遵循 ECMAScript 规范对 Math.floor 的具体定义。若输入是特殊值，运算器会严格返回对应的特殊浮点值，不会强行吞掉异常状态。
2. 位运算截断 ~~x、x | 0、x >> 0：开发者常借用位运算符截断小数位以达到所谓“快速取整”的目的。然而 ECMAScript 规范规定，所有 32 位位运算符在求值前必须先对其操作数调用 ToInt32(x) 内部抽象操作，将其强制截断并映射为 32 位有符号二进制补码整数。

这种底层规范的根本差异，直接导致了它们在处理极端边界输入时完全分道扬镳。

二、特殊值取整结果详查：NaN、+Infinity 与 -Infinity

在真实业务系统中，由于除以零、非法输入解析失败或数值未初始化，程序往往会产生 NaN 或 Infinity。以下是各取整手段在面对这些特殊值时的执行输出：

1. Math.floor 的规范行为

根据 ECMAScript 规范定义，Math.floor 对特殊值的处理规则非常直接明确：

• 如果参数为 NaN，结果为 NaN；
• 如果参数为 +0，结果为 +0；若为 -0，结果为 -0；
• 如果参数为 +Infinity，结果为 +Infinity；
• 如果参数为 -Infinity，结果为 -Infinity。

// Math.floor 针对特殊值的实际运行结果示例
console.log(Math.floor(NaN));         // 输出: NaN
console.log(Math.floor(Infinity));    // 输出: Infinity
console.log(Math.floor(-Infinity));   // 输出: -Infinity
console.log(Math.floor(null));        // 输出: 0 (Number(null) 隐式转为 0)
console.log(Math.floor(undefined));   // 输出: NaN (Number(undefined) 隐式转为 NaN)
console.log(Object.is(Math.floor(-0), -0)); // 输出: true (保留负零符号)

2. 位运算符（~~、| 0）的致命“静默归零”

很多工程师喜欢在代码中书写 ~~val 来替代 Math.floor(val)，但在遇到特殊值时，位运算会产生严重的静默 Bug：

// 位运算针对特殊值的运行输出示例
console.log(~~NaN);         // 输出: 0
console.log(~~Infinity);    // 输出: 0
console.log(~~(-Infinity)); // 输出: 0
console.log(NaN | 0);       // 输出: 0
console.log(Infinity >> 0);  // 输出: 0

三、大数陷阱：32位溢出翻转与 53位安全整数精度断层

大数取整涉及两个重要的关键界限：32 位有符号整数上限（$2^31 - 1 = 2,147,483,647$）与 IEEE-754 双精度安全整数上限（Number.MAX_SAFE_INTEGER，即 $2^53 - 1 = 9,007,199,254,740,991$）。

1. 32 位位运算环绕溢出（Wrap-around）

当数值超过 $2,147,483,647$（约 21.47 亿，常见于时间戳、大额流水号、网络 ID）时，任何使用 ~~、| 0 或 >> 0 的取整代码都会直接崩溃。

以数字 3,000,000,000 为例：在数学意义上它是一个正整数，但在经过 ECMAScript 规范的 ToInt32 算法处理时，计算过程如下：

1. 取低 32 位二进制比特序列，得到十六进制 0xB2D05E00；
2. 检查第 31 位（最高符号位），该位为 1；
3. 根据二进制补码规则，系统将其解析为负数：$3,000,000,000 - 2^32 = -1,294,967,296$。

// 32 位溢出示例
const amount = 3000000000.75;

console.log(Math.floor(amount)); // 输出: 3000000000 (正确向下取整)
console.log(~~amount);           // 输出: -1294967296 (严重错误：正数变负数！)
console.log(amount | 0);         // 输出: -1294967296 (同上)

2. 负数取整的方向性差异：向下取整 (floor) vs 朝零截断 (trunc)

另一个隐蔽且常被忽视的问题是负数方向。许多人误以为位运算 ~~x 等价于 Math.floor(x)，但在数学定义上：

• Math.floor(x) 是朝负无穷大方向向下取整；
• 位运算 ~~x 和 Math.trunc(x) 是朝零方向截断小数。

// 负数取整差异示例
console.log(Math.floor(-1.8)); // 输出: -2 (真实向下取整)
console.log(Math.trunc(-1.8)); // 输出: -1 (朝零截断)
console.log(~~(-1.8));         // 输出: -1 (行为与 trunc 一致，并非向下取整！)

在物理坐标系下沉计算、网格定位计算中，这一偏差会导致负半轴的索引出现 1 个单位的系统性偏移。

3. 53位安全整数限制与精度丢失

当数字超过 Number.MAX_SAFE_INTEGER（9007199254740991）时，即使是 Math.floor 也无法保障输出与数学期望完全一致，因为数字本身在进入 Math.floor 之前，已经在 IEEE-754 的尾数存储中丢失了精度。

// 超安全整数精度丢失示例
const huge1 = 9007199254740992; // 2^53
const huge2 = 9007199254740993; // 2^53 + 1 (JS 无法精确表示奇数，直接舍入为 9007199254740992)

console.log(Math.floor(huge2)); // 输出: 9007199254740992 (无法得到期望的 9007199254740993)
console.log(~~huge2);          // 输出: 1 (由于模 2^32 截断，结果完全丧失真实意义)

四、BigInt 的参与限制与向下除法实现

为了解决大整数溢出问题，ECMAScript 引入了原生 BigInt。但是，绝对不能将 BigInt 直接传入 Math.floor，否则会直接引发运行时异常：

// BigInt 传给 Math.floor 抛出异常
try {
  Math.floor(100n);
} catch (err) {
  console.error(err); // TypeError: Cannot convert a BigInt value to a number
}

Math 对象下的所有静态方法都设计为只接收 Number 类型，规范显式禁止将 BigInt 隐式类型转换为 Number，以防止无感知的精度丢失。

此外，BigInt 的原生整除运算 / 默认是朝零截断（Truncating），而非向下取整。若需要对包含负数的 BigInt 实现严格的数学向下取整除法（Floor Division），必须手动处理余数：

/**
 * 针对 BigInt 的严格数学向下取整除法 (Floor Division)
 * @param {bigint} a 被除数
 * @param {bigint} b 除数
 * @returns {bigint} 向下取整后的商
 */
function bigintFloorDiv(a, b) {
  if (b === 0n) {
    throw new RangeError("Division by zero");
  }
  const quotient = a / b;
  const remainder = a % b;
  // 当有余数且两数异号时，向下取整商需要减 1n
  const isOppositeSign = (a < 0n) !== (b < 0n);
  if (remainder !== 0n && isOppositeSign) {
    return quotient - 1n;
  }
  return quotient;
}

// 验证向下取整除法与原生除法的区别
console.log(-7n / 2n);               // 输出: -3n (朝零截断)
console.log(bigintFloorDiv(-7n, 2n)); // 输出: -4n (真正向下取整)

五、工程化落地：生产级安全取整函数封装

综合上述所有边界条件，在面对用户不可控的输入、外部 API 数据或高精计算需求时，建议在公共工具库中封装一套具备防御性校验的安全取整函数，其完整实现如下：

/**
 * 生产级安全向下取整工具
 * @param {unknown} val 输入参数
 * @param {object} options 配置项
 * @param {number} options.fallback 遇到无法处理的非法值时的回退默认值
 * @returns {number|bigint} 规范取整结果
 */
function safeFloor(val, options = {}) {
  const { fallback = 0 } = options;

  // 1. 处理 BigInt 独立类型
  if (typeof val === "bigint") {
    return val; // BigInt 本身已是精确整数，直接返回
  }

  // 2. 转换为 Number
  const num = Number(val);

  // 3. 校验 NaN
  if (Number.isNaN(num)) {
    if ("fallback" in options) return fallback;
    return NaN; // 遵循规范保留 NaN
  }

  // 4. 校验无穷大 ±Infinity
  if (!Number.isFinite(num)) {
    return num; // 严禁抹平为 0，原样保留极值语义
  }

  // 5. 校验安全整数范围
  if (Math.abs(num) > Number.MAX_SAFE_INTEGER) {
    console.warn(`[safeFloor] 数值 ${num} 超出安全整数范围，可能存在精度失真。建议改用 BigInt 或高精度库。`);
  }

  // 6. 执行安全规范向下取整
  return Math.floor(num);
}

// 验证生产级函数输出
console.log(safeFloor("123.85"));      // 输出: 123
console.log(safeFloor(NaN, { fallback: 0 })); // 输出: 0 (受控兜底)
console.log(safeFloor(Infinity));      // 输出: Infinity (安全保留极值)
console.log(safeFloor(3000000000.9));  // 输出: 3000000000 (安全处理大数，避开位运算负数陷阱)
console.log(safeFloor(-2.3));          // 输出: -3 (严格负向下取整)

六、排查清单与团队编码规范建议

为了防止线上出现由向下取整引起的重大事故，建议在代码评审（Code Review）与静态代码扫描中落实以下规范：

• 全面禁止在业务逻辑中使用 ~~、| 0、>> 0 等位运算符进行取整：现代 V8、JavaScriptCore 引擎对 Math.floor 的 JIT 优化已极为高效，位运算在当今的微基准测试中几乎没有实用性能优势，却带来了 32 位溢出、特殊值被吞和负数取整方向反转三大不可控高危风险。
• 涉及负数计算时明确取整语义：明确业务需要的是“朝零截断”（使用 Math.trunc）还是“向下取整”（使用 Math.floor）。
• 对大整数交互强制使用 BigInt：凡涉及雪花 ID（Snowflake ID）、高精度微秒时间戳、区块链地址或大额资金分厘计算，必须使用 BigInt 或成熟的任意精度数学库（如 bignumber.js、decimal.js），并在除法时显式指定舍入模式。
• 严格校验上游数据的有限性：在执行核心算法前，优先使用 Number.isFinite(x) 进行断言拦截，杜绝让 NaN 或 Infinity 悄无声息地污染业务流水线。