唯一可靠方式是运行go build -gcflags="-m=2"，若输出“inlining call to xxx”则成功内联；“cannot inline”后跟具体原因（如defer、闭包、递归等）即失败，且跨包调用默认不内联。
Go 编译器不会按你写的函数长度“自动内联”，它有一套严格的审查机制；想确认某个函数是否被内联，唯一靠谱的方式是加 -gcflags="-m=2" 看编译输出，而不是数行数、看 IDE 高亮或凭经验猜测。
怎么确认函数被内联了
运行 go build -gcflags="-m=2" main.go，观察输出中是否出现：
-
can inline xxx或inlining call to xxx→ 成功内联 -
cannot inline xxx: contains closure、cannot inline xxx: uses defer、cannot inline xxx: function too complex→ 明确失败原因
注意：-m=2 必须作用于整个构建过程（如 go test -gcflags="-m=2" 也有效），且只对当前包内定义的函数生效；跨包调用（如 github.com/some/pkg.Foo）默认不内联，加 //go:inline 也无效。
哪些写法会让内联直接失败
哪怕函数只有 3 行，只要命中以下任意一条，编译器立刻放弃内联：
- 含
defer、recover或panic—— 即使是defer fmt.Println()这种简单语句也不行 - 使用闭包捕获外部变量（如
func() int { return x }中的x来自外层作用域） - 返回值是接口类型（如
interface{}）或结构体方法集非空（编译器认为类型转换开销不可控） - 函数体里调用了带
//go:noinline的函数，或用了reflect、unsafe - 是递归函数 —— 编译器连分析都不做
//go:inline 必须紧贴函数声明上方，中间不能有空行或其它注释；对方法接收者是接口类型的函数（如 func (i io.Reader) Read(...)）完全无效。
内联后体积变大、性能提升有限
内联不是“免费午餐”。它会把函数体复制到每个调用点，可能导致二进制体积明显增大：
- 一个被调用 10 次的小函数，可能生成 10 份指令副本
- 若该函数调用了
json.Marshal，整个encoding/json符号链可能被拖入最终二进制 - 真实服务中，一次内联带来的收益通常在几纳秒级，远不如减少一次
interface{}类型断言、避免一次切片append扩容来得实在
别为了“让编译器内联”而强行拆分逻辑（比如把 processRequest 拆成 parseHeader + validateToken）——可读性和维护成本的损失，常远超那几纳秒。
真正关键的是：先用 go tool compile -l=4 -m=2 确认热路径上哪些函数没被内联，再对照失败原因逐条排查；而不是一上来就加 pragma、改签名、删 defer —— 很多时候，问题不在函数本身，而在它所处的调用上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
