使用 go build -gcflags="-m=2" 可查看编译器内联决策，如“can inline foo”表示成功，“foo not inlined”说明未满足门槛；内联需避开 defer、闭包、interface 调用；//go:inline 仅为请求，不保证生效。
看编译器是否真的内联了 go build -gcflags="-m=2"
Go 编译器对内联有严格策略，不会盲目展开。最直接的办法是让编译器“自己说”：用 go build -gcflags="-m=2" 构建，它会逐行输出内联决策。重点盯住类似这样的日志：
can inline foo with cost 15 (threshold 80) → 满足条件，已内联
foo not inlined: function too large → 超过成本阈值，放弃
foo not inlined: unhandled op CALL → 含无法分析的调用（如 interface 方法、闭包、recover）
注意：-m=2 输出非常 verbose，建议配合 grep 过滤，例如 go build -gcflags="-m=2" main.go 2>&1 | grep "inline"
热路径函数内联的三个硬门槛
即使你写了短小函数，Go 也不会无条件内联。以下任一条件不满足，go tool compile 就会跳过：
- 函数体不能含
defer、recover、panic（它们破坏栈帧结构） - 不能有闭包引用外部变量（会生成额外 closure 结构）
- 不能是 interface 方法调用（动态分发，编译期无法确定目标）
比如这个看似简单的函数：func add(a, b int) int { return a + b } 会被内联；但改成 func add(a, b int) int { defer func(){}(); return a + b } 就不会——哪怕只加了一行 defer。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
内联收益明显时才值得干预：避免虚假热点
别为了“看起来快”而强行诱导内联。真实热路径通常具备这些特征：
- 被高频调用（如循环体内、HTTP handler 中间件链、LRU 缓存的
Get/Put） - 函数体极短（≤10 行逻辑，无分支或仅单 if）
- 参数和返回值都是值类型（
int、string、小 struct），避免指针逃逸带来 GC 压力
反例：一个处理 Markdown 渲染的 renderBlock 函数，哪怕只调用一次，也不适合内联——它内部有大量字符串拼接、正则匹配、递归调用，内联后反而增大二进制体积、降低 CPU 指令缓存命中率。
用 //go:noinline 和 //go:inline 主动控制（慎用）
Go 提供两个编译指示，但它们不是“开关”，而是“请求”：
//go:noinline 几乎总生效，常用于测试场景（比如想单独测量某个函数耗时，防止被内联后消失在 profile 中）
//go:inline 不保证成功，编译器仍会校验成本模型；若失败，只会静默忽略，不会报错
真正需要人工干预的典型场景极少，比如你在写一个极致性能敏感的 ring buffer 的 Push，且确认它被 hot loop 调用上千次/秒，又恰好满足所有内联门槛——这时加 //go:inline 才有意义。其他情况，优先信任编译器的 -m=2 输出和 pprof 火焰图定位。
内联不是银弹。最常被忽略的是：过度内联会让 pprof 的调用栈扁平化，掩盖真实瓶颈位置；而一个没被内联的函数，如果本身就在火焰图顶部占 40% 时间，那它才是真正该优化的对象，而不是纠结它“为什么没被内联”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
