Go 1.21+ 应使用 cmp.Min/cmp.Max 安全取极值，支持 int、string 等任意可比较类型；math.Min/Max 仅限 float64，整数转换易致精度丢失或溢出；切片需手动遍历配合 cmp.Min；浮点边界用 math.Inf 而非 MaxFloat64。
Go 语言里没有“math.Minimize”这种函数，math 包本身不提供最小化算法，它只提供基础数学工具；所谓“最小化”，实际是靠你选对边界值、用对比较函数、避开溢出和精度陷阱来实现的。
用 cmp.Min 和 cmp.Max 安全取极值（Go 1.21+）
别再用 math.Min 处理整数——它只收 float64，强制转换容易丢精度或引入 NaN 风险。Go 1.21 起标准库有了 cmp 包，这才是正解：
-
cmp.Min(a, b)和cmp.Max(a, b)支持任意可比较类型（int、int64、string等），类型必须一致，编译期检查 - 不接受混合类型，比如
cmp.Min(5, int64(3))直接报错，反而帮你提前暴露类型混乱问题 - 对切片求最小值？得自己遍历，但可以安全复用
cmp.Min：func minIntSlice(s []int) (int, bool) { if len(s) == 0 { return 0, false } m := s[0] for _, v := range s[1:] { m = cmp.Min(m, v) } return m, true }
浮点边界要分清 MaxFloat64 和 SmallestNonzeroFloat64
用 math.MaxFloat64 表示“尽可能大”，但别误以为它能当“无穷大”参与计算——很多运算（如 1 / MaxFloat64）会下溢成 0；而真正该用“无穷大”的地方，应该用 math.Inf(1)（正无穷）或 math.Inf(-1)（负无穷）。
-
math.MaxFloat64 ≈ 1.8e308：最大可表示有限值，再大就变+Inf -
math.SmallestNonzeroFloat64 ≈ 4.9e-324：最小正非零值，比它还小就下溢为 0 - 做归一化或防止除零时，用
math.SmallestNonzeroFloat64比硬写1e-100更语义清晰、更跨平台
整数边界别硬写数字，优先用 math.MaxInt64 和 math.MinInt64
手写 9223372036854775807 不仅易错，还隐藏了类型假设。Go 标准库的常量才是可靠选择：
立即学习“go语言免费学习笔记（深入）”；
- 所有带符号 64 位整数操作（包括
int在 64 位系统上），统一用math.MaxInt64/math.MinInt64 - 如果真要适配
int的平台相关性，可用int(^uint(0) >> 1)计算最大值，但绝大多数业务场景没必要——明确用int64+math常量更直白 - 测试边界行为时，直接传
math.MinInt64进函数，比构造一个“看起来很小”的负数更能暴露溢出逻辑缺陷
类型转换是边界问题的高发区，int64 → int 尤其危险
Go 不自动转换，但显式转也不等于安全。最常踩的坑是把超范围的 int64 往 int 转：
-
int(math.MaxInt64)在 32 位系统上必然溢出，结果是未定义行为（不是 panic，是静默错误） - 从
float64转整数时，先用math.Round或math.Floor明确舍入意图，别依赖截断——int(3.9)是 3，不是 4 - 涉及用户输入或外部数据时，永远校验范围再转换：
if x > math.MaxInt || x < math.MinInt { return fmt.Errorf("value %v out of int range", x) } val := int(x)
边界处理真正的复杂点不在“怎么写常量”，而在于你是否清楚每个值在哪个环节可能被隐式提升、被截断、被下溢，以及你的比较逻辑是否覆盖了 NaN、+Inf、-0.0 这些特殊浮点状态——这些细节不会报错，但会让结果在特定输入下悄然偏离预期。
