go无内联关键字，编译器自动决策；用-go build -gcflags=”-m=2″验证，含“can inline”即成功；禁用场景包括defer/recover、闭包、reflect、递归等；性能影响微小，勿过早优化。
Go 里没有真正意义上的“内联函数”
Go 编译器（gc）会自动对符合条件的函数做内联（inlining），但你不能像 C/c++ 那样用 inline 关键字强制声明。是否内联由编译器根据函数体大小、调用频次、是否有闭包/反射/recover 等因素综合判断，开发者无法直接控制。
如何确认某个函数被内联了
使用 go build -gcflags="-m=2" 查看编译器决策。输出中出现 can inline xxx 或 inlining call to xxx 表示成功内联；若看到 cannot inline xxx: function too complex，说明被拒绝。
- 函数体不能含
defer、recover、panic - 不能有闭包捕获外部变量（哪怕只是读取）
- 不能调用
reflect、unsafe或带go:noinline标记的函数 - 递归函数永远不会被内联
func add(a, b int) int { return a + b } // 这个大概率会被内联 —— 简单、无副作用、无复杂控制流内联失效的常见坑
看似 trivial 的改动就可能让内联失败，比如：
- 给参数加指针类型：从
func f(x int)改成func f(x *int)，即使只读，也可能因逃逸分析变复杂而禁用内联 - 返回值是接口类型（如
Interface{}）或含方法集的结构体，触发类型转换开销，编译器倾向不内联 - 函数定义在非主模块（比如第三方包），且未开启
-gcflags="-l=0"（关闭内联优化），默认不跨包内联
验证方式始终是加 -m=2，而不是凭经验猜测。
立即学习“go语言免费学习笔记（深入）”；
性能影响其实很有限，别过早优化
内联主要消除的是函数调用的栈帧开销（几纳秒级），在绝大多数业务逻辑中远不如算法选择、内存分配、GC 压力或锁竞争影响大。
- 微基准测试（
go test -bench）中看到 5% 左右差异，放到真实 http handler 或 DB 查询链路里基本不可测 - 过度追求内联可能导致代码可读性下降，比如把逻辑硬拆成多个小函数只为“方便内联”，得不偿失
- 真正值得花时间的地方：减少
interface{}使用、避免频繁append切片、复用对象池（sync.Pool）
只有当你用 -cpuprofile 定位到某处函数调用本身成了热点（比如 tight loop 里每轮都调一个 2 行函数），再回头检查内联状态才合理。