Java移位运算不抛异常，但超长移位量会自动取模：int取%32（即&0x1F），long取%64（即&0x3F）；负数移位如-3实际变为29，易导致意外结果，应禁止负移位并校验或使用>>>。
Java 中移位运算本身不会因“移动位数过大”而抛异常，但超出类型长度的移位量会被自动取模处理——这不是溢出，而是语言规范定义的行为。真正需要防止的，是**误以为移位无效或结果不可控**，以及**因取模逻辑导致的意外行为**。
移位位数自动取模的规则
Java 明确规定：对 int 类型移位时，实际移位数为 右操作数 & 0x1F（即 % 32）；对 long 类型，则为 右操作数 & 0x3F（即 % 64）。
5 等价于 <code>5 ，结果是 401L 等价于 <code>1L ，结果是 64-
10 >> -1是合法语法，但-1 & 0x1F = 31，所以等价于10 >> 31，结果为 0（正数右移31位后全为0）
为什么不用“防止超过长度”？
因为 Java 编译器和 JVM 已强制处理了该问题——你写 x ，运行时不会报错，也不会卡死，而是按 <code>x 执行（对 int）。这种设计是为了性能和确定性，不是疏漏。
- 无需手动判断
num >= 32再截断，JVM 已做 - 也不建议用
Math.min(num, 31)替代，会掩盖真实意图，且可能引入分支开销 - 若业务逻辑确实依赖“移位数不能大于31”，应单独校验并抛 IllegalArgumentException，而非依赖移位语义
真正要防范的两类风险
移位位数“超长”本身安全，但容易连带引发两类实际问题：
立即学习“Java免费学习笔记（深入）”；
-
语义误解：比如想实现“清空低 n 位”，写了
x > n，当n >= 32时，x 变成 0，后续右移仍是 0，结果全丢——这不是移位溢出，而是逻辑失效 -
负数移位数：虽然语法允许（如
x >> -3），但-3 & 0x1F = 29，实际执行的是右移29位，极易偏离预期。应禁止负移位数，直接校验if (shift
实用建议
写移位代码时，聚焦三点即可：
- 明确移位目的：是做乘除、掩码、还是位提取？目的清晰，自然知道合理范围（如索引位提取通常 ≤ 5）
- 对用户输入或配置的移位数，加显式范围检查（如只接受 0–31），避免魔法数字和隐式取模误导维护者
- 负数参与移位时，优先确认是否真需符号扩展（用
>>）或无符号处理（用>>>），尤其在哈希、序列化、协议解析中
