JavaScript中位运算符强制将操作数转为32位有符号整数，流程为：先ToNumber，再ToInt32（取整后对2³²取模并按补码映射），结果恒在[-2147483648, 2147483647]范围内。
JavaScript 中 Number 类型在位运算中会**强制转为 32 位有符号整数（int32）**，这个过程不是“可选”或“按需”，而是位运算符（&、|、^、~、<<、>>、>>>）的底层语义要求——它们只对整数操作，且仅处理低 32 位。
位运算前的隐式转换流程
所有操作数都会经历以下三步转换：
- 先调用
ToNumber（比如Number(x)），把原始值转为数字（如"15"→15，null→0，undefined→NaN）； - 若结果是
NaN、+0、-0、+Infinity或-Infinity，则统一转为0； - 再执行
ToInt32：取该数字的整数部分，然后对 2³² 取模，再按补码规则映射到 [-2³¹, 2³¹−1] 区间。
例如：2.7 | 0 → 先转成 2.7，取整得 2，再转 int32 还是 2；-1.9 | 0 → -1.9 → -1 → int32 的 -1（即 0xFFFFFFFF）。
浮点数和大整数的截断风险
由于只保留低 32 位，超出范围或含小数的数值会被“悄悄修正”：
立即学习“Java免费学习笔记（深入）”；
-
Math.pow(2, 32) | 0→0（因为 2³² mod 2³² = 0）； -
0x100000000 | 0→0； -
123.456 | 0→123（小数部分直接丢弃，不四舍五入）； -
2147483647 | 0→2147483647（即0x7FFFFFFF，最大正 int32）； -
2147483648 | 0→-2147483648（溢出后变成最小负 int32，即0x80000000）。
特殊值与边界行为
这些值在位运算中都有确定归宿：
-
null | 0→0（Number(null) === 0）； -
undefined | 0→0（Number(undefined) === NaN，而ToInt32(NaN) === 0）； -
true | 0→1（Number(true) === 1）； -
false | 0→0； -
"12" | 0→12；"12abc" | 0→0（因Number("12abc") === NaN→0）。
为什么不用 parseInt 或 Math.floor 替代？
虽然 parseInt(x) 或 Math.floor(x) 看似更“可控”，但它们：
- 不处理
NaN/Infinity的统一归零逻辑； - 不自动完成 32 位截断与符号扩展；
- 性能略低（函数调用开销 + 更多判断）；
- 对负数行为不同：
Math.floor(-1.9)是-2，但-1.9 | 0是-1（取整方式为 toward zero）。
所以 | 0 常被用作快速取整（向零）+ 安全转 int32 的惯用写法，但务必清楚它隐含的精度丢失和符号翻转风险。
