不完全等价：对非负整数，n >> 1 等价于 floor(n/2)；对负数，因算术右移补符号位，结果为向负无穷取整，与数学除法行为存在语义差异。
右移 >> 真的等价于除以 2 吗？
不完全等价。对非负整数，n >> 1 等价于 Math.floor(n / 2)；但对负数，结果取决于语言的「算术右移」语义，通常不是数学意义上的除法。
例如在 JavaScript、Java、C/C++ 中，-5 >> 1 得到的是 -3（补码算术右移），而 -5 / 2 的浮点结果是 -2.5，向下取整是 -3，向零取整是 -2 —— 这里恰好一致；但 -6 >> 1 是 -3，而 Math.trunc(-6 / 2) 也是 -3，看起来没问题；可一旦涉及更复杂逻辑（如循环索引、偏移计算），符号位扩展带来的行为差异就容易埋雷。
什么时候能安全用 >> 1 替代 / 2？
仅当满足全部以下条件时，才建议替换：
- 操作数始终为 非负整数（如数组长度、索引、计数器）
- 目标平台/语言保证
>>是算术右移（主流语言都满足，但 WebAssembly 或某些嵌入式 C 编译器可能需确认） - 不需要浮点结果或小数部分（
>>只作用于整数，且截断而非四舍五入） - 代码可读性未因此受损——比如
mid = (left + right) >> 1在二分查找中广泛接受，但timeoutMs >> 1就不如timeoutMs / 2直观
>> 和 / 2 的性能差异还值得在意吗？
现代编译器和 JIT（如 V8、JVM HotSpot、GCC -O2）几乎总会把常量除以 2 的整数运算自动优化为右移，所以手写 >> 1 一般不会带来实际性能提升。
真正影响性能的是：是否触发了类型去优化（如 JS 中混入浮点数）、是否引起隐藏的符号扩展开销（如对 int8_t 右移后又赋给 int32_t）、或是否阻碍了向量化（如 SIMD 指令无法处理位运算混合算术）。
典型反例：
let x = 100; for (let i = 0; i <h3>容易被忽略的边界坑：溢出与符号扩展</h3> <p>最隐蔽的问题不是“算得对不对”，而是“算的是谁”。比如：</p>
-
int8_t a = -128; printf("%d", a >> 1);→ 输出-64（正确），但若误写成(uint8_t)a >> 1，则先转成128u，再右移得64，语义全错 - JavaScript 中
2**31 >> 1是-1073741824（因为 JS 按 32 位有符号整数解释位运算），而2**31 / 2是1073741824 - 在无符号类型上下文中（如 Go 的
uint32），必须用>>而不能用/做位级操作，否则失去底层控制力
真要用右移替代除法，务必确认操作数类型、符号性、位宽，以及目标环境对位运算的定义——这些细节比“快不快”重要得多。
