位运算符在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 数据，而不是凭经验替换操作符。
