唯一可靠确认函数被内联的方式是使用go build -gcflags="-m=2"并查找inlining call to日志，或加-l禁用内联后对比汇编是否消失；-m或-m=1仅表示“可内联”，不保证实际内联。
怎么确认函数真的被内联了
看到 can inline 不等于它真被插进去了。编译器在 SSA 阶段还会按成本模型二次筛选，很多函数“过审”但最终没落地。
唯一可靠方式是加 -m=2 并找 inlining call to 这条日志：
-
go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"—— 出现即实锤 -
go build -gcflags="-l -m=2" main.go—— 加-l禁用内联后对比，看是否从CALL消失 - 别信
-m或-m=1：它们只报“能内联”，不报“已内联”，漏掉闭包、接口参数等关键失败线索
哪些写法会让内联直接失败
编译器有硬性规则，命中任意一条就放弃，//go:inline 也救不了。
- 函数里有
defer、panic、recover—— 即使只有一行defer log.Println() - 用了闭包且捕获外部变量，比如
func() int { return x + y }()（x、y来自外层） - 返回值是
interface{}或含非空方法集的结构体 —— 类型擦除开销让编译器绕道 - 函数递归调用自身，或调用了带
//go:noinline的函数 - 含
reflect、unsafe，或调用汇编实现的函数（如runtime.memmove）
//go:inline 怎么写才生效
它不是开关，是 pragma 指令，位置和格式错一点就失效。
- 必须紧贴函数声明正上方，中间不能有空行、不能有其他注释隔开
- 正确：
//go:inline func add(a, b int) int { return a + b } - 错误：
//go:inline func add(a, b int) int { ... }（空行）或//go:inline // some doc func add(...) { ... }（中间有别的注释） - 对接收者是接口类型的方法无效，比如
func (i MyInterface) Foo()加了也没用
内联后体积变大但性能提升有限
内联把函数体复制到每个调用点，二进制可能明显膨胀，而收益常被高估。
- 一个被调用 10 次的小函数，会生成 10 份指令副本；若它调了
json.Marshal，整个encoding/json包符号链都会拖进来 - 真实收益通常在纳秒级，比如
BenchmarkInline-80.255 ns/op vsBenchmarkNoInline-81.47 ns/op - 比起内联，减少一次
interface{}类型断言、避免一次切片append扩容，效果更实在 - 跨包调用默认不内联，哪怕函数体只有一行
return a + b—— 别为“看起来短”就拆包
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
