17370845950

位运算符在JavaScript中几乎不提升性能，现代引擎已优化%等操作；&替代%仅在非负整数且m为2的幂时成立，>>0与Math.floor性能相当但语义不同；位运算真正价值在于语义清晰、避免浮点误差及底层协议对接。

位运算符在 JavaScript 中几乎从不提升运行时性能，现代引擎优化后，&、|、^、~、、>>、>>> 的执行速度和等价的算术/布尔操作基本无差异；所谓“性能优势”多是过时经验或基准测试误导。

为什么 & 替代 % 并不总是更快？

常见说法：用 n & (m-1) 替代 n % m（当 m 是 2 的幂）能提速。这在 C 或底层语言中成立，但在 JS 中：

• V8 / SpiderMonkey 已对 % 做了专门优化，当右操作数为常量且是 2 的幂时，自动转为位运算
• 若 m 非常量（如 n % someVariable），手动位运算反而因类型转换开销更慢
• n & (m-1) 仅对非负整数正确；n 为负时结果与 % 不一致（JS 的 % 是带符号取余）

const n = -5;
console.log(n % 4);   // -1
console.log(n & 3);   // 3 ← 完全不同

>> 0 和 Math.floor() 性能对比真实情况

有人用 n >> 0 取整，认为比 Math.floor(n) 快。实际：

• >> 强制将操作数转为 32 位有符号整数（会丢失小数、截断高位、对 >2³¹-1 或
• Math.floor() 在 V8 中已内联优化，对浮点数输入并不比 >> 慢多少
• 若 n 是字符串（如 "123.45"），>> 会先调用 ToNumber 再 ToInt32，而 Math.floor 只走一次 ToNumber，此时 >> 更重

console.log(123.9 >> 0);     // 123
console.log(-123.9 >> 0);    // -124 ← 注意：这是算术右移，不是 floor
console.log(0x80000000 >> 0); // 0 ← 溢出后变成 0，非预期

真正值得用位运算的场景（非性能驱动）

位运算的价值不在提速，而在语义清晰、避免浮点误差、或对接底层协议：

• 权限掩码组合：userRole & READ_PERMISSION 比 userRole.includes('read') 更紧凑且无字符串开销
• 颜色值解析：rgb = [color >> 16 & 0xFF, color >> 8 & 0xFF, color & 0xFF] 直观且无正则/数组切分成本
• 游戏或 WebGL 中处理 packed vertex attributes（如用单个 Uint32 存 4 个 Uint8 分量）
• 实现确定性哈希（如 MurmurHash 的部分步骤），要求跨平台整数行为一致

记住：JS 中位运算最大的陷阱不是慢，而是隐式类型转换——&、| 等总会把操作数转成 32 位整数，一旦超出范围或含小数，结果就不可控。性能优化请优先看 profiler 数据，而不是凭经验替换操作符。