内联是编译器基于成本模型的静态决策，非运行时机制；唯一确认方式是go build -gcflags="-m=2" | grep "inlining call to"，仅can inline不表示实际发生；//go:inline仅为提示，//go:noinline需紧贴函数声明且对跨包无效。
内联是编译器自动决策，不是你加个注释就能生效
Go 没有 inline 关键字，也没有运行时内联机制。所谓“内联”，是 go build 阶段编译器根据成本模型静态判断的结果：满足条件就展开，不满足就跳过，//go:inline 只是轻微增强倾向的 pragma，不是开关。
它发生在 SSA 构建之后、机器码生成之前，属于前端优化环节；一旦决定内联，函数体就被直接复制进调用点，参数按值/指针传递规则重写，返回逻辑被合并进父函数控制流——整个过程不涉及运行时、不改变语义、也不影响 goroutine 栈行为。
常见误解是“短函数一定内联”，但实际中：func add(a, b int) int { return a + b } 在跨包调用时默认不内联；而一个 30 行但无 defer、无闭包、无接口参数的同包函数，反而可能被选中。
哪些写法会直接让内联失败（//go:inline 也救不了）
编译器有一套硬性拦截规则，命中任意一条就放弃，不讲情面：
立即学习“go语言免费学习笔记（深入）”；
-
defer、panic、recover—— 即使只有一行defer mu.Unlock() - 闭包捕获外部变量，例如
func() int { return x + y }（x、y来自外层作用域） - 返回值是
interface{}，或结构体含非空方法集（如带String() string） - 函数体调用
reflect、unsafe，或任何标有//go:noinline的函数 - 递归函数，或调用链中某环含接口方法（如参数是
io.Reader） - 跨包调用导出函数（如
strings.TrimSpace），无论多简单，默认不内联
怎么确认函数真被内联了，而不是你以为它被内联了
唯一可信的方式是看编译器输出，不是数行数、不是看 IDE 高亮、也不是跑 benchmark。
运行：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"
如果出现类似 ./main.go:42:15: inlining call to parseHeader，说明它真被展开了；只看到 can inline parseHeader 不代表成功——那只是编译器“觉得可以”，但后续成本模型可能否决它。
注意：-m=2 必须带等号；go test -bench=. 默认强制加 -gcflags="-l"（禁用所有内联），你在 bench 里测不到真实效果。
//go:noinline 和 //go:inline 的生效前提很苛刻
两者都必须紧贴函数声明正上方，中间不能有空行、不能有其他注释隔开：
✅ 正确写法：
//go:noinline
func debugLog(msg string) { fmt.Println(msg) }
❌ 错误写法（编译器直接忽略）：
//go:noinline
// some doc
func debugLog() { ... }
//go:noinline 对接收者是接口类型的方法无效（如 func (r io.Reader) Read()）；//go:inline 在 Go 1.19+ 引入，但它只是提示，不是强制命令，且对跨包调用无影响。
真正难的是：很多开发者花时间加注释、改函数签名，却从不运行 -m=2 验证结果。内联只在极窄场景下有意义——每秒调用上万次、函数体极小、无内存分配。其它时候，它更像一个调试信号：提醒你该用 pprof 看看真正的瓶颈在哪。
