Go 1.21 的 min 和 max 是编译期内联的语法糖，非运行时函数，不产生调用开销或泛型成本；其签名虽为泛型形式，但编译器在SSA阶段直接展开为条件表达式树。
Go 1.21 的 min 和 max 不是运行时函数，也不依赖标准库，它们在编译期就被展开为内联比较逻辑——这意味着没有函数调用开销，也没有反射或泛型运行时成本。
它们根本不是“函数调用”，而是编译器语法糖
虽然签名看起来像泛型函数：func min[T cmp.Ordered](x T, y T) T，但实际不生成任何可调用符号。编译器在 SSA 构建阶段直接将 min(a, b, c) 替换为等效的条件表达式树（例如 a ），对两个以上参数会递归展开。
- 所有参数必须在编译期已知类型且满足
cmp.Ordered，否则报错：cannot use ... as type T in argument to min - 不支持切片传参：
min(nums...)会编译失败，因为...展开后类型推导可能模糊，且违背“固定数量参数”的设计约束 - 常量表达式会被完全折叠：如
min(3, 5, 7)在编译后直接变成常量3，不占运行时空间
NaN 处理是浮点特例，由编译器硬编码逻辑保证
当任意参数是 float32 或 float64 类型且值为 NaN 时，min/max 必须返回 NaN —— 这不是靠 math.IsNaN 实现的，而是编译器在生成比较指令时插入了显式的 NaN 分支检查（例如 x86 上用 ucomisd + jp）。
- 哪怕只有一个 NaN 参数，比如
min(1.0, math.NaN())，结果就是NaN，不会 panic 也不会忽略 - 整数和字符串类型完全不涉及 NaN 逻辑，这部分代码路径在编译期就被剪除
- 该行为与 IEEE 754 一致，但实现上不依赖 runtime/math，纯编译器控制
类型一致性要求比表面更严格
min 和 max 要求所有参数属于同一具体类型，不能靠隐式转换“凑类型”。例如 min(1, int64(2)) 会报错，因为 1 是未定类型常量，但上下文未提供足够信息推导为 int64；而 min(int64(1), int64(2)) 没问题。
- 混合字面量和变量时，优先以第一个参数类型为准：
min(3, x)中若x是int32，则3被推导为int32；但如果x是int64，3就推导为int64 - 字符串比较按字节序（UTF-8 编码字节流），不是 Unicode 码点或 collation 规则，
min("α", "z")返回"α"（因为0xCE0x7A） - 自定义类型需显式实现可比较性：如果定义了
type MyInt int，它自动满足cmp.Ordered；但带字段的 struct 若含不可比较字段（如map[string]int），则整个类型不可用于min/max
真正容易被忽略的是：它们不解决“动态集合求极值”问题——没有 min(slice...)，也没有 min(interface{}) 变体。需要这类能力时，仍得手写循环或封装泛型工具函数。编译器内联优化虽好，但边界非常清晰：只服务「已知数量、已知类型、编译期可判定」的极值场景。
