Go 内联的真相：没有「强制 pragma」，只有「把函数写小」加「-m 验证」

编译器的内联（inlining）是 Go 性能调优里最容易被人「想当然」的一块。最常被问的一个问题是：「Go 有没有像 C/C++ 那样的 #pragma inline / __attribute__((always_inline))？怎么强制把一个函数内联进去？」

答案很干脆：没有 //go:inline，Go 设计上只提供 //go:noinline 来「禁止」内联，不提供任何「强制」语法。 你能做的只有一件事——让函数满足内联条件，然后用编译器开关验证它确实被内联了。

下面所有结论都来自 Go 1.26.5 的真实编译输出（不是文档猜的），我用一份演示代码逐条跑过 go build -gcflags="-m -m"。

默认行为：gc 自动挑「够便宜」的吃掉

Go 的 gc 编译器在 SSA 后端有一个内联成本预算。函数体足够小、足够简单，就会被自动内联进调用方——无需任何标注，普通函数和方法是同一套规则。

我实测时能内联的包括：

叶子小函数（Add 这类两行算术）
值接收者方法（Point.Dist2，只做一次乘法）
interface 方法（Cat.Sing）——只要调用点能确定具体类型，devirtualization 会让它内联
带小循环的函数（sumSlice 这种 for range 累加）
调用了「不可内联函数」的包装函数（wrap 调了标了 //go:noinline 的 safeDiv，但 wrap 自己照样 can inline）

最后这条最反直觉，也是最大误区：内联是逐函数独立决策的，被调函数能不能内联，不影响调用方能不能内联。 所谓「调用了不可内联函数就会阻断整条 mid-stack 链」是错的。

实测编译器原话节选（go build -gcflags="-m -m"）：

can inline Add
can inline Point.Dist2
can inline Cat.Sing
can inline perform
can inline sumSlice
can inline wrap
can inline CallsPrintln            // 调 fmt.Println，而 fmt.Println 自身也可内联

怎么让一个函数被内联

1. 把函数体写小。内联成本预算实测上限约 80；超出即拒。useReflect 因调用 reflect 把 cost 推到 98 被拒，demo 因函数体过大 cost 523 被拒。小循环、小 switch 没事，深分支/大循环会被拒。 2. 挪走顶层 defer。Go 1.26 实测顶层 defer 仍触发 unhandled op DEFER 直接拒绝（safeDiv、WithDefer、main 都因此被拒）。注意：defer 里那个匿名闭包体本身可以内联，只是闭包里若含 recover 就不可内联。 3. 别用 recover。含 recover 的闭包会被拒（cannot inline ...: call to recover）。 4. 别在热路径上碰 reflect。它的 cost 会直接撑爆预算。 5. 方法无所谓值/指针接收者，只跟函数体成本有关；但若值接收者复制一个大结构体，复制成本也算进预算。

验证命令：

go build -gcflags="-m" . —— 看到 can inline <函数> 即成功
go build -gcflags="-m -m" . —— 看拒绝原因 cannot inline <函数>: <原因>
go build -gcflags="-l" . —— 全局关闭内联（调试用，能看完整栈帧；多次 -l 关得更彻底）

三个被实测推翻的旧认知

「调用了不可内联函数，自身也被卡住」——错。wrap 调了 //go:noinline 的 safeDiv，wrap 自己仍 can inline。
「Go 1.14 之后顶层 defer 都能内联」——错。Go 1.26 实测顶层 defer 仍 unhandled op DEFER 拒绝；只有 defer 包裹的闭包体可内联。
「有 //go:inline 可以强制」——没有。Go 只给 //go:noinline 禁止、不给 //go:inline 强制。理由很工程化：强制内联会拖慢编译、膨胀二进制、破坏「去内联」（de-inlining）调试能力。

关键数据点

内联成本预算：约 80（实测 useReflect 98、超大 demo 523 双双被拒）
内联是逐函数独立决策，不沿调用链强制传染
跨包导出函数也能被调用方内联（同一 module 内的 whole-program / mid-stack inlining），-m 输出里能看到 inlining call to <跨包函数>
interface 方法在调用点被 devirtualize 后可内联（不是「interface 方法一律不内联」）
顶层 defer / 闭包内 recover / reflect 调用 = 实测明确拒绝触发项
验证入口：go build -gcflags="-m -m"（注意 Go 1.26 的 -m=2 输出格式有变，单级 -m -m 最稳）

必须警惕的限制

内联不等于性能。 小函数内联能消掉调用开销、给后续优化（常量传播、逃逸分析）开窗口；但内联本身会让二进制变大，热点函数若因此超预算反而进不了内联——要 profile 说话，别盲信。
//go:noinline 是调试/性能探针工具，不是优化手段。真正要极致性能时，正确做法是「保持小 + 验证」，或把热点改写成已优化的库（如 kelindar/simd），而不是强行内联。
不要相信「Go 会自动向量化我所有的循环」。这点跟内联无关但要一起记牢：gc 不会自动向量化你的普通循环（编译速度优先 + bounds check 两层原因），SIMD 只存在于标准库特定函数。想用 AVX2 看另一篇。

一句话方法论：写小函数 → go build -gcflags="-m" 确认 can inline → 不满足就削函数体、挪走顶层 defer/recover/reflect → 仍要极致性能就走手写汇编或现成 SIMD 库。

— 实证环境：Go 1.26.5，go build -gcflags="-m -m" . 逐条验证；演示代码包含 main.go + blocked.go 两组对照（可内联 / 被拒），可复现全部输出。

暂无表态