Go 语言中，1<<64 不报错是因为左操作数 1 是未类型化常量，编译期按无限精度计算；而 1<<65 报溢出错误，是因为结果超出 uint64 表示范围；运行时非常量右操作数的位移则自动截断为低 64 位，不触发溢出检查。
go 语言中，`1
在 Go 中，位移操作（<< 和 >>）的行为严格区分 常量表达式 与 非常量表达式，这是理解 1<<64 为何合法、而 1<<65 却导致编译错误的关键。
✅ 常量位移：高精度编译期计算
当位移表达式的左右操作数均为常量（如 1 << 64），Go 将其视为常量表达式。根据 Go 语言规范，常量表达式始终以任意精度精确求值，不受预声明类型（如 uint64）限制：
const MaxInt uint64 = 1<<64 - 1 // ✅ 合法：1 是未类型化常量，1<<64 计算为 2⁶⁴（即 18446744073709551616），再减 1 得到 0xffffffffffffffff
此时 1 并非 int64 或 uint64，而是具有无限精度的未类型化整型常量。1<<64 的结果是数学上精确的 2⁶⁴，仅在最终赋值给 uint64 类型变量时才进行范围检查——而 2⁶⁴ − 1 恰好等于 uint64 最大值，完全合法。
但若超出表示能力：
const Overflow uint64 = 1<<65 - 1 // ❌ 编译错误：constant 36893488147419103231 overflows uint64
因为 2⁶⁵ − 1 > math.MaxUint64（即 2⁶⁴ − 1），赋值前校验失败。
⚠️ 非常量位移：运行时截断，无溢出检查
一旦位移的右操作数为非常量（如变量或函数调用），整个表达式变为非常量位移表达式。此时规则变化：
若左操作数为未类型化常量，它首先被转换为“若仅保留左操作数时本应具有的类型”——即 uint64(1)。
这意味着位移在 uint64 类型上执行，且 Go 规定：对无符号整数进行位移时，若位移量 ≥ 类型位宽，结果为 0（等价于取模：shift % 64 对 uint64）。
验证示例：
package main
import "fmt"
func main() {
for i := 60; i <= 65; i++ {
shift := uint64(i)
j := uint64(1)<<shift - 1 // ⚠️ 非常量位移：1 先转为 uint64(1)，再执行位移
fmt.Printf("%2d | %064b | %#18x\n", i, j, j)
}
}输出关键行：
64 | 1111111111111111111111111111111111111111111111111111111111111111 | 0xffffffffffffffff 65 | 0000000000000000000000000000000000000000000000000000000000000000 | 0x0
- i=64：1<<64 在 uint64 上等价于 1<<0（因 64 % 64 == 0），故 1<<64 == 1 → j = 1 - 1 = 0？等等——但实际输出却是全 1！
✅ 正确理解：uint64(1) << 64 中，Go 规范明确要求：当右操作数 ≥ 位宽时，结果为 0。然而示例中 j = 1<<shift - 1 实际计算为 (1<<64) - 1。由于 1<<64 为 0，则 0 - 1 触发无符号整数下溢，得 0xffffffffffffffff（即 2⁶⁴ − 1）。这正是你观察到 64 和 65 输出相同的原因：两者均因位移模运算归零，再减 1 得到最大值。
? 关键提醒：1<<65 - 1 在非常量场景下不会编译失败，但逻辑结果不可靠（恒为 ^uint64(0)），应避免依赖。
? 总结与最佳实践
- 常量位移（如 1<<n）：用于定义边界值（如 math.MaxUint64），需确保 n ≤ 64（对 uint64）；n > 64 直接编译失败。
- 非常量位移（如 1<<shiftVar）：位移量会被模 64 处理，shiftVar >= 64 时等效于 shiftVar % 64；结果为 0 或循环位移，不触发溢出 panic，但易引发逻辑错误。
-
安全写法：显式约束位移量，例如：
if shift >= 64 { j = 0 // 或 panic("shift too large") } else { j = uint64(1) << shift }
理解 Go 的常量语义与运行时类型转换机制，是写出健壮位运算代码的基础。切勿假设位移行为与 C/Java 完全一致——Go 的设计以安全性与可预测性优先。
