确认函数是否被内联，唯一实证是 go build -gcflags="-m=2" 输出中出现“inlining call to”；仅“can inline”不代表成功，因ssa阶段成本模型会二次淘汰，且-m或-m=1不报告实际内联结果。

Go 编译器是否内联某个函数，不取决于你“觉得它小”或“写了 //go:inline”，而只取决于 go build -gcflags="-m=2" 输出里有没有 inlining call to 这一行。

怎么确认函数真的被内联了

看到 can inline 不代表它真被插进去了。编译器在 SSA 阶段还会按成本模型二次筛选，很多函数“过审”但最终没落地。

• 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 也救不了。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

• 函数里有 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
  // some doc
  func add() { }

• 对接收者是接口类型的方法无效，比如 func (i MyInterface) Foo() 加了也没用

跨包调用和性能影响容易被忽略

函数定义不在当前包，//go:inline 完全不生效；内联后二进制可能明显膨胀，而收益常被高估。

• 外部包函数（如 github.com/some/pkg.Foo()）默认不内联，编译器根本不检查你的 //go:inline
• 一个被调用 10 次的小函数，内联后可能复制出 10 份指令；若它调用了 json.Marshal，还会把整个 encoding/json 符号链拖进来
• 纳秒级收益只对每秒调用上万次的热路径有意义；真实服务中，减少一次 interface{} 类型断言，往往比内联更有效

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！