go中需用math.maxint64等带位宽的常量获取类型上限，因int/platform相关，math.maxint不存在；float64最大有限值为math.maxfloat64，非math.inf(1)。
怎么拿到 int、float64 这些类型的上限值
Go 里没有像 Python 的 sys.maxsize 或 Java 的 Integer.MAX_VALUE 那样直接暴露的全局常量，所有基本类型的极值都藏在 math 包里，且命名严格按类型区分。比如 int 本身是平台相关（32 位或 64 位），所以不能直接用 math.MaxInt——它根本不存在。
实际要用的是：math.MaxInt64、math.MaxInt32、math.MaxUint8、math.MaxFloat64 这类明确带位宽的常量。它们全都是预声明的 untyped 常量，可直接赋值给对应类型变量，不会溢出或隐式转换失败。
-
int类型要小心：编译时不确定是 32 还是 64 位，必须显式选math.MaxInt64或math.MaxInt32，否则逻辑可能跨平台不一致 -
uint没有负值，math.MinUint就是 0，但包里没定义这个常量，得自己写0 -
float32和float64的最大有限值是math.MaxFloat32和math.MaxFloat64，不是math.Inf(1)——后者是无穷大，不属于“可表示的最大值”
为什么 math.MaxInt 不是 int 的最大值
因为 Go 的 int 是实现相关的类型，math 包设计上拒绝模糊性。它只提供确定位宽的常量，逼你面对“我到底在 32 位环境还是 64 位环境运行”这个问题。
常见误用：var x int = math.MaxInt64 在 32 位系统上会编译失败（常量超出 int 范围），而 var x int64 = math.MaxInt64 永远安全。
立即学习“go语言免费学习笔记（深入）”；
- 想写可移植代码？用
int64显式代替int，再配math.MaxInt64 - 做约束校验（如限制 ID 不能超最大值）时，别用
int接收输入，优先用定宽类型，避免 runtime panic -
math.MaxInt根本不是导出常量——它不存在。查文档或go doc math会发现只有带位宽的版本
比较 float64 最大值时容易踩的坑
math.MaxFloat64 是能被精确表示的最大有限浮点数，但它和 math.Inf(1) 完全不同：前者可参与运算（比如 +1 会变成 +Inf），后者是特殊值，比较行为也不同。
典型错误是拿 math.MaxFloat64 当“无穷大哨兵值”用，结果遇到 x > math.MaxFloat64 永远为 false，而 x != x 才是检测 NaN 的方式。
- 判断是否溢出：用
result != result（NaN）或math.IsInf(result, 1)，而不是跟math.MaxFloat64比大小 -
math.MaxFloat64 + 1结果是+Inf，但math.MaxFloat64 == math.MaxFloat64 + 0仍为 true - 序列化/网络传输时，
math.Inf(1)可能被转成字符串"inf"，而math.MaxFloat64是具体数字，注意协议兼容性
替代方案：用 const 自定义更清晰的边界
如果业务里反复用到某个范围（比如用户 ID 限制在 64 位无符号整数内），与其每次写 math.MaxUint64，不如在包顶层定义：
const (
MaxUserID = math.MaxUint64
MinScore = 0
MaxScore = 100
)
这样既避免重复拼写，又把语义从“技术上限”拉回到“业务规则”，后续改规则也只需动一处。
注意：这些 const 必须放在 math 包导入之后，且不能用 := 声明（常量不能短变量声明）。
- 不要在函数内部用
const，Go 不允许 - 如果值依赖运行时（比如从配置读），那就不能用 const，得用 var + init 函数，但那就失去编译期检查优势
- 多个包共用同一边界？把它提到公共工具包里，别复制粘贴常量
位宽意识比记住常量名更重要——看到 int 就该条件反射想到“它到底多大”，而不是指望语言替你兜底。
