唯一可靠方式是运行 go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"，输出中出现 inlining call to 才算落地；defer、闭包、interface{} 返回等任一存在即直接跳过内联。
怎么确认函数真的被内联了
只看 can inline foo 没用，这仅表示编译器认为它“有资格”，不代表实际发生。唯一可靠方式是运行：go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"。输出中出现类似 ./main.go:42:15: inlining call to parseHeader 才算落地。
常见误判点：
- 在
go test -bench=.中测性能——默认带-gcflags="-l"（禁用内联），你测的其实是“全关内联”状态 - 跨包调用如
github.com/some/pkg.Foo()，哪怕加了//go:inline也无效，编译器根本不检查该 pragma - IDE 高亮或函数只有 2 行，不等于被内联；
defer、闭包、interface{}返回任一存在，就直接跳过分析
哪些写法会让内联立刻失败
Go 编译器有一套硬性拦截规则，命中任意一条，连成本模型评估都不走，直接放弃。和行数、是否加 //go:inline 无关。
典型触发条件：
立即学习“go语言免费学习笔记（深入）”；
-
defer、recover或panic：哪怕只是defer log.Println("done") - 闭包捕获外层变量：如
func() int { return x }()中的x来自外层作用域 - 返回值是
interface{}或方法集非空的结构体（例如带String() string的类型） - 函数体内调用
reflect、unsafe，或任何标有//go:noinline的函数 - 递归函数：编译器连日志都不打，静默跳过
//go:inline 必须紧贴函数声明上一行，中间不能有空行或其它注释；对方法接收者为接口类型的函数（如 func (r io.Reader) Read()）完全无效。
逃逸分析与内联的耦合关系
内联和逃逸不是独立过程。内联失败常因逃逸风险被提前否决；而成功内联又可能改变逃逸结果——因为展开后上下文变了。
关键诊断组合必须是：go build -gcflags="-l -m -m"：
-
-l禁用内联，暴露原始调用链，便于定位“本该内联却没发生”的位置 - 单个
-m只输出粗略线索（如leaking param: s） - 双
-m（-m -m）才显示深层原因：&x escapes to heap、sync.Pool.Put(x)因接口参数隐式堆分配等
例如：bytes.Buffer 参数若泄漏，&buf escapes to heap 会导致每次调用都触发 GC 压力——这种问题单 -m 看不到，必须双 -m。
内联的实际收益和代价边界
纳秒级收益只对高频热路径有意义，比如每秒调用数万次的 bytes.Equal 或 strings.HasPrefix；普通业务逻辑里强行拆小函数换内联，反而可能因逃逸恶化或二进制膨胀得不偿失。
真实代价容易被忽略：
- 二进制体积明显增大：一个被调用 10 次的函数，可能复制出 10 份指令；若含
json.Marshal，还会拖入整个encoding/json符号链 - 调试困难：内联后
runtime/debug.Stack()和 pprof 中该函数栈帧彻底消失，//go:noinline才能还原调用结构 - 跨包场景下，你以为自己写了可内联的小函数，结果传了个
map[string]interface{}或加了defer，编译器连看都不看一眼
