必须通过 go build -gcflags="-m=2" 输出中出现 inlining call to 才能确认函数被内联；仅函数短小、无参数或命名简洁无效，且 defer、闭包捕获变量、interface{} 返回值、reflect/unsafe 调用、递归或接口方法调用等均直接禁用内联。
Go 编译器不会因为函数“短小”就自动内联它——它只在满足一整套硬性条件时才内联，且你无法靠肉眼判断是否成功；唯一可信的是 go build -gcflags="-m=2" 的输出里出现 inlining call to。
怎么确认函数真的被内联了
别信函数只有三行、没参数、名字叫 min 或 clamp ——这些都不算数。编译器先标记“can inline”，再按成本模型二次否决，很多函数卡在最后一关。
- 运行
go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"，出现该日志才实锤内联成功 -
-m=2必须带等号，-m或-m=1只显示“可内联”，不反映最终决策 - 跨包调用（如
strings.TrimSpace）默认不内联，哪怕它只有一行return strings.Trim(s, " ") -
go test -bench=.默认强制加-gcflags="-l"（禁用所有内联），你在 benchmark 里测的永远是“无内联”路径
哪些写法会让内联直接失败（加 //go:inline 也救不了）
编译器有硬拦截规则，命中任意一条就跳过，不讲情面：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 函数里有
defer、panic、recover—— 即使只有一行defer mu.Unlock() - 用了闭包且捕获外层变量，例如
func() int { return x + y }中的x、y来自外层作用域 - 返回值是
interface{}，或结构体含非空方法集（如带String() string） - 函数体调用
reflect、unsafe，或任何标有//go:noinline的函数 - 是递归函数，或调用链中某环含接口方法（如参数是
io.Reader）
//go:inline 怎么写才生效
它不是开关，只是增强倾向的 pragma，且语法和位置极其敏感：
立即学习“go语言免费学习笔记（深入）”；
- 必须紧贴函数声明正上方，中间不能有空行、不能有其他注释隔开
- 正确写法：
//go:inline后紧跟func add(a, b int) int { ... } - 错误写法：上面有空行，或写成
//go:inline // some doc再换行写函数 - 对方法接收者是接口类型的方法无效，例如
func (r io.Reader) Read()加了也白加 - 它只约束定义处的行为，对跨包调用方无影响
真正要盯的不是函数长度，而是逃逸分析结果和 SSA 阶段的内联日志；盲目拆分函数、加 //go:inline、删空行，反而可能让二进制变大、调试变难、构建变慢——而性能收益常被高估到纳秒级，还未必压得过一次切片扩容或 interface{} 类型断言。
