JS 用位运算判断整数的原理与风险

在 JavaScript 代码库或性能极客的代码片段中，常能见到类似 (num | 0) === num、~~num === num 或 (num >> 0) === num 的写法，用于快速校验一个值是否为整数。这种模式利用了 ECMAScript 规范中位运算符会隐式触发 ToInt32 抽象操作、截断浮点数小数部分的特性；如果截断后的数值与原值严格相等，且数值落在 32 位有符号整数范围内，表达式即返回 true。然而，这一技巧存在严重的安全区间收缩缺陷：一旦数值超出 32 位范围（约 ±21.47 亿），就会发生溢出回绕引发误判，且对非数值类型及特殊浮点值抗干扰能力极弱。在现代 JavaScript 中，推荐使用规范标准提供的 Number.isInteger()。

一、位运算判断整数的实现模式与底层原理

JavaScript 的所有数字在底层默认均以双精度 64 位浮点数（IEEE 754 标准）存储。无论我们在代码中声明 let a = 10; 还是 let b = 10.5;，它们在底层都是双精度浮点类型，本身并不存在专门的独立 32 位整数基础类型。

为了实现诸如按位或（|）、按位异或（^）、按位取反（~）以及有符号右移（>>）等操作，ECMAScript 规范强制要求：所有位运算在执行之前，必须先将操作数转换为 32 位有符号二进制整数。这一转换过程在语言规范中被定义为抽象操作 ToInt32(argument)。

常见的位运算判断整数表达式通常有以下几种书写形式：

// 常见的三种位运算判断写法
function isIntegerByOr(n) {
  return (n | 0) === n;
}

function isIntegerByTilde(n) {
  return (~~n) === n;
}

function isIntegerByShift(n) {
  return (n >> 0) === n;
}

1.1 ToInt32 规范转换的具体执行逻辑

以最普遍的按位或零 (num | 0) 为例，当 JavaScript 引擎执行此表达式时，会严格遵循规范流程：

1. 类型转换为数值（ToNumber）：如果传入的值不是数值类型，首先调用内部 ToNumber 操作。
2. 特殊浮点值归零：如果数值是 NaN、+0、-0、+Infinity 或 -Infinity，ToInt32 规范直接返回 +0。
3. 向零舍入截断小数：计算 sign(number) * floor(abs(number))，将浮点数的小数部分直接抛弃，保留整数部分。
4. 取模 2³² 截断：对整数部分执行模 2³² 计算，将其限制在 32 位无符号整数区间 [0, 2³² - 1]。
5. 映射为 32 位有符号整数：如果结果大于或等于 2³¹，则减去 2³²，使其映射回 [-2147483648, 2147483647]（即 [-2³¹, 2³¹ - 1]）的有符号补码区间。

完成 ToInt32 转换后，表达式通过 === 与原值进行严格全等比对。如果原数字带有小数（如 3.14），经过截断后变为 3，3 !== 3.14，结果为 false；如果原数字本身是不带小数的整数且在 32 位范围内（如 42），截断后仍为 42，42 === 42，结果为 true。

二、核心风险一：32 位有符号整数边界截断与溢出盲区

使用位运算判断整数最致命的缺陷，在于人为压缩了 JavaScript 数字的安全整数区间。

在标准 JavaScript 中，双精度 64 位浮点数可以精确表示高达 53 位的连续整数。规范明确给出了安全整数边界常量：

• Number.MAX_SAFE_INTEGER = 9007199254740991（即 2⁵³ - 1，约 9007 万亿）
• Number.MIN_SAFE_INTEGER = -9007199254740991（即 -(2⁵³ - 1)）

然而，位运算符的内部计算规则将操作数强行压制在 32 位有符号整数区间（[-2147483648, 2147483647]）。这意味着：一旦整数的绝对值超过 21.47 亿（即 2³¹ - 1），位运算就会触发高位溢出回绕，导致合法整数被错误判定为“非整数”。

2.1 典型溢出反例代码验证

// 反例 1：刚好越过 32 位有符号正整数上限 (2³¹ - 1)
const bigInt1 = 2147483648; // 2³¹
console.log(bigInt1 | 0);               // 输出: -2147483648 (最高符号位变为1，回绕为负数)
console.log((bigInt1 | 0) === bigInt1); // 输出: false ❌ (明明是纯整数，却被判定为不是整数)

// 反例 2：达到 2³² 时发生完全模回绕归零
const bigInt2 = 4294967296; // 2³²
console.log(bigInt2 | 0);               // 输出: 0 (模 2³² 截断后完全归零)
console.log((bigInt2 | 0) === bigInt2); // 输出: false ❌

// 反例 3：超出 2³² 的加法偏移整数
const bigInt3 = 4294967301; // 2³² + 5
console.log(bigInt3 | 0);               // 输出: 5 (高位被直接截断丢弃)
console.log((bigInt3 | 0) === bigInt3); // 输出: false ❌

三、核心风险二：类型隐式转换与特殊浮点值陷阱

除了 32 位溢出外，位运算符对待非数值类型及特殊浮点值的转换规则，也容易引起严重的代码逻辑漏洞。

3.1 误用双等号（宽松相等）导致的类型穿透

不少开发者在使用位运算时，若不慎写成双等号（==），JavaScript 引擎在两边类型不一致时会尝试类型强转，导致纯字符串或布尔值被错误识别为整数：

// 致命的隐式类型转换漏洞
const strVal = '100';

// 错误写法：使用宽松相等 ==
console.log((strVal | 0) == strVal); // 输出: true ❌ (字符串 '100' 被判定为整数！)

// 虽然使用严格相等 === 可以避免部分非数值：
console.log((strVal | 0) === strVal); // 输出: false (100 !== '100')

3.2 特殊浮点常量的静默归零

在 IEEE 754 规范中，Infinity（无穷大）和 NaN（非数字）拥有独特的计算规则。但根据 ToInt32 算法，它们在参与位运算时都会被静默强制转换为 0：

console.log(Infinity | 0); // 输出: 0
console.log(-Infinity | 0);// 输出: 0
console.log(NaN | 0);      // 输出: 0
console.log(null | 0);     // 输出: 0 (null 先被转为 0)

如果开发者编写了某些旨在“提取并校验整数”的辅助函数（例如 function parsePositiveInt(x) { const n = x | 0; return n > 0 ? n : 0; }），当传入 NaN 或 Infinity 时，函数不会抛出异常或返回失败，而是静默返回 0，从而掩盖真正的上游数据异常。

四、现代标准实践：为什么推荐 Number.isInteger()

为了彻底解决历史遗留的整数校验痛点，ECMAScript 2015（ES6）正式引入了语言级内置方法 Number.isInteger() 与 Number.isSafeInteger()。

4.1 Number.isInteger() 的执行机制与优势

规范中 Number.isInteger(argument) 的判定流程十分清晰且严密：

1. 首先检查 typeof argument === 'number'。若类型不符（例如字符串 '42'、布尔值 true、null、undefined），直接返回 false，杜绝任何隐式类型转换。
2. 检查数值是否为有限数值（等价于 isFinite(argument)），自动排除 NaN、+Infinity 和 -Infinity。
3. 计算其绝对值的向下取整是否与自身相等：Math.floor(Math.abs(argument)) === Math.abs(argument)。如果相等，则确定为整数并返回 true。

// 标准规范用例对比
Number.isInteger(42);                  // true ✅
Number.isInteger(3.14);                // false ✅
Number.isInteger(2147483648);          // true ✅ (完美支持超出 32 位的大整数)
Number.isInteger(1730000000000);       // true ✅ (毫秒时间戳准确识别)
Number.isInteger('42');                // false ✅ (严格拒绝字符串，避免类型隐患)
Number.isInteger(NaN);                 // false ✅
Number.isInteger(Infinity);            // false ✅

4.2 性能神话破灭：现代 JS 引擎下的性能真相

早年部分前端开发者执着于使用位运算做判断，往往是出于“位运算比浮点函数快”的传统认知。然而在当今的 V8（Chrome / Node.js）、SpiderMonkey（Firefox）与 JavaScriptCore（Safari）等现代 JIT 编译器中：

• Number.isInteger 属于标准内置内联原语（TurboFan 内建优化节点），在编译时直接生成高效率机器码指令，几乎零额外开销。
• 位运算符在接收非常规类型或偶发超出 32 位的输入时，反而容易破坏 JIT 引擎的内联缓存（Inline Cache）与类型反馈猜测，导致去优化（Deoptimization），产生性能负优化。
• 代码可读性与健壮性远比微秒级的微优化更重要。Number.isInteger 语义清晰直白，便于代码审计与静态类型检查器（如 TypeScript）进行类型收窄。

4.3 兼容老旧环境的 Polyfill 规范实现

如果项目需要运行在极度老旧的 ECMAScript 5 运行环境（如 IE11），也不应该回退到位运算方案，而应当使用符合官方规范的垫片函数：

// 符合 ECMAScript 规范的 Number.isInteger Polyfill
if (!Number.isInteger) {
  Number.isInteger = function (value) {
    return typeof value === 'number' &&
           isFinite(value) &&
           Math.floor(value) === value;
  };
}

五、常见问题与工程落地建议