go 将 `math.maxint64` 视为无类型常量，其值在赋值或转换时需显式指定目标类型；若依赖默认类型推导，编译器会尝试转为 `int`，导致 32 位系统溢出错误。
在 Go 语言中，math.MaxInt64（值为 9223372036854775807）是一个
无类型整数常量（untyped integer constant）
，而非 int64 类型字面量。根据
Go 语言规范
，无类型常量具有任意精度，本身不会溢出；但一旦参与变量声明、类型转换或接口赋值等上下文，Go 会依据
上下文类型（contextual type）
或
默认类型规则
进行
隐式转换
。
关键规则如下：
当使用短变量声明 := 且右侧为无类型常量时，Go 会为其推导
默认类型
：
整数常量 → 默认为 int
浮点常量 → 默认为 float64
复数常量 → 默认为 complex128
因此，以下代码会失败：
而以下写法是安全的：
⚠️ 注意事项：
即使在 64 位系统（int 通常为 64 位）上代码可能“侥幸通过”，该行为
不具备可移植性
——Go 规范仅保证 int 至少 32 位，不保证为 64 位。跨平台构建（如 GOARCH=386）时极易暴露问题。
math.MaxUint64 同理：它是无类型常量，但无法无损转为 int（有符号），必须显式转为 uint64。
不要依赖 fmt.Printf("%T", math.MaxInt64) 查看类型——它输出 int 是运行时反射结果（因常量已按默认类型实例化），而非其原始无类型本质。
✅ 最佳实践：
对 math.MaxInt64/MaxUint64 等边界常量，
始终显式指定目标类型
；
在泛型或接口场景中，优先使用带类型的转换：int64(math.MaxInt64) 而非裸常量；
若需复用，可定义具名常量增强可读性与类型安全性：
这并非 bug，而是 Go 类型系统对“无类型常量 + 默认类型推导”机制的一致体现——设计初衷是兼顾灵活性与安全性，但要求开发者主动承担类型意图的表达责任。
a := math.MaxInt64 // ❌ 错误：math.MaxInt64 被推导为 int，而 9223372036854775807 > MaxInt32（2147483647），在 int=32 位的平台（如某些嵌入式环境或 32 位构建）上编译失败
b := interface{}(math.MaxInt64) // ❌ 同样失败：interface{} 无类型约束，Go 回退到默认 int，触发溢出var a int64 = math.MaxInt64 // ✅ 显式声明目标类型，直接赋值
b := interface{}(int64(math.MaxInt64)) // ✅ 强制转换为 int64 后再装箱，消除歧义
c := int64(math.MaxInt64) // ✅ 显式转换，类型明确const (
MaxInt64 = int64(math.MaxInt64)
MaxUint64 = uint64(math.MaxUint64)
)