math.Max 不内联因其需严格遵循 IEEE 754 对 NaN 和 -0.0 的语义，底层用汇编实现且无 //go:inline 标记；而 Go 1.21+ 内置 max/min 在编译期展开为条件表达式，无调用开销且类型安全。
math.Max 和 math.Min 没有内联优化，它们是标准库函数，不是编译器语法糖。 这和 Go 1.21+ 的内置 max/min 完全不同——后者在编译期展开为条件表达式，无调用开销；而 math.Max 始终是函数调用，哪怕参数是常量，也不会被折叠。
为什么 math.Max 不内联？
因为它是 func Max(x, y float64) float64，定义在 math 包里，属于标准库实现，受 Go 编译器内联策略限制：只有小、无副作用、标记为 //go:inline 的函数才可能被内联，而 math.Max 显式不满足（它需严格遵循 IEEE 754 对 NaN/-0.0 的行为，底层用汇编实现，不可简单替换）。
- 即使写
math.Max(1.0, 2.0)，编译后仍生成函数调用指令，不会变成常量2.0 - 对比
max(1, 2)：编译后直接消失，只剩一个整数加载指令 - 性能差异在微基准下可测出：对热点路径频繁调用
math.Max，会多一次 call/ret 开销（虽小但真实存在）
math.Max 的 NaN 行为是硬性依赖，无法绕过
它的返回逻辑不是“if x > y { x } else { y }”，而是按 IEEE 754 定义：math.Max(NaN, x) == NaN，math.Max(-0.0, +0.0) == +0.0。这种语义无法由普通分支模拟，必须靠 runtime 或汇编保障。
- 手写
a > b ? a : b在遇到NaN时恒为false，结果永远是b，逻辑错误 -
math.Max是唯一能安全处理未初始化浮点变量、JSON 解析出的null（转成 NaN）、或外部计算传入异常值的方案 - 想“优化掉”它而改用条件表达式，等于主动放弃 NaN 安全性
混用 math.Max 和内置 max 容易踩类型坑
两者签名和约束完全不同，强行替换会立刻编译失败，且错误信息不直观。
立即学习“go语言免费学习笔记（深入）”；
-
math.Max(3, 5)报错：cannot use 3 (untyped int) as float64 -
max(3, 5)正确，推导为int -
max(3, int64(5))报错：cannot use 3 as type int64 in argument to max（类型不一致） -
math.Max(float64(3), float64(5))正确，但丢了整数精度保障（比如int64(1 转 <code>float64会截断）
真正容易被忽略的是：你不能靠“加个 -gcflags=-l”强制内联 math.Max——它被编译器明确禁止内联。需要极致性能且确定无 NaN 时，要么用内置 max，要么自己写带 //go:inline 的封装（但得重实现 IEEE 语义）。事情说清了就结束。
