Go 1.21起应优先使用泛型内置函数max/min替代math.Max/Min处理整数，因其支持int等类型、避免float64转换导致的精度丢失和溢出；但仅接受两个参数，不支持变参或nil指针。
Go 1.21 之后别再用 math.Max 和 math.Min 处理整数
Go 1.21 引入了泛型版的内置函数 max 和 min，它们能直接处理 int、float64、string 等可比较类型，而旧的 math.Max 和 math.Min 只接受 float64，对整数必须显式转换——这不仅啰嗦，还容易因截断或溢出出错。
常见错误现象：math.Max(1, 2) 直接报错 cannot use 1 (untyped int) as float64 value in argument to math.Max；有人写成 int(math.Max(float64(a), float64(b)))，但若 a 或 b 超过 float64 精度（比如大于 2⁵³），结果就不可靠。
- 整数场景一律优先用
max(a, b)/min(a, b)，编译器自动推导类型 -
math.Max和math.Min仅保留在需要严格 IEEE 754 行为时使用（例如处理NaN、-0.0） - 泛型函数不支持切片，想对 slice 求极值仍得手写循环或用
slices.Max（Go 1.21+ 的golang.org/x/exp/slices，非标准库）
max 和 min 的参数限制很实在：只能传两个值
这两个内置函数不是变参函数，不支持 max(a, b, c, d)。想比三个及以上数，得嵌套调用，比如 max(a, max(b, c))，或者先放进切片再遍历。
使用场景：适合二元比较（比如取两个配置项中的较大者、边界裁剪），不适合聚合计算。
立即学习“go语言免费学习笔记（深入）”；
- 嵌套是合法且高效的，编译器会内联，无运行时开销
- 如果逻辑里频繁要三数取大，建议封装成辅助函数，避免满屏嵌套降低可读性
- 注意：不能传 nil 接口或未初始化变量，否则 panic；比如
var x *int; max(*x, 0)会 panic
和 slices.Max 混用时小心类型不匹配
标准库没提供 slices.Max，它是 golang.org/x/exp/slices 里的实验性函数，要求切片元素类型实现 constraints.Ordered（即支持 比较）。但它和内置 <code>max 不是一套机制，类型约束不完全重叠。
常见错误现象：对 []uint 调用 slices.Max 报错 cannot infer T，因为 uint 不在 constraints.Ordered 默认覆盖范围内（它包含 int、int32、float64、string 等，但不含无符号整型）。
- 安全做法：统一用有符号类型（如
int）或显式指定类型参数，例如slices.Max[uint](s) - 性能影响：内置
max(a,b)是编译期常量折叠，slices.Max是运行时遍历，大数据量时别误当内置函数用 - 兼容性提醒：
golang.org/x/exp/slices属于实验包，API 可能在未来版本变更或移入标准库
事情说清了就结束。真正容易被忽略的是：泛型内置函数的类型推导看似智能，但一旦涉及接口、指针或自定义类型，它就罢工——这时候你得退回去老老实实写比较逻辑，别硬套 max。
