唯一可靠方式是用go build -gcflags="-m=2"查看编译器输出，出现“can inline”或“inlining call to”即成功，含“cannot inline”及原因则失败；跨包调用默认不内联，defer、闭包、递归等硬性规则命中即拒。

内联不是性能银弹，它只对极少数热路径有效；盲目加 //go:inline 不但无效，还可能让二进制变大、编译变慢。

怎么确认函数是否被内联了

唯一可靠方式是用 go build -gcflags="-m=2" 看编译器输出。别信 IDE 高亮、别数行数、别猜。

• 看到 can inline xxx 或 inlining call to xxx，说明成功内联
• 看到 cannot inline xxx: contains closure 或 cannot inline xxx: function too complex，说明被拒，原因写得清清楚楚
• -m=2 必须加，-m 或 -m=1 只显示基础信息，看不到内联决策
• 跨包调用（如 github.com/some/pkg.Foo）默认不内联，即使函数体只有一行 return a + b

哪些写法会让内联直接失败

编译器有硬性规则，命中任意一条就放弃，//go:inline 也救不了。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

• 函数里有 defer、panic、recover ——哪怕只有一行 defer log.Printf("done")
• 用了闭包且捕获外部变量，例如 func() int { return x + y }()（x、y 来自外层作用域）
• 返回值是接口类型（如 interface{}）或含非空方法集的结构体——类型擦除开销让编译器绕道走
• 函数是递归的，或者调用了带 //go:noinline 的函数
• 含 reflect 或 unsafe 操作

//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() 加了也没用

内联真能提升性能吗

能，但只在极窄场景下有意义：每秒调用上万次、函数体极小（如 max、clamp）、且无内存分配。

• 典型收益在纳秒级，比如 BenchmarkInline-8 0.255 ns/op vs BenchmarkNoInline-8 1.47 ns/op
• 真实服务中，一次 http.Handler 调用里内联一个 parseHeader，收益远不如避免一次 interface{} 类型断言或一次切片扩容
• 内联后二进制体积可能明显增大——被调用 10 次的小函数，会复制出 10 份指令；若函数里调了 json.Marshal，整个 encoding/json 符号链都会被拖进来
• 别为内联拆函数：把逻辑硬切成 validateToken、buildResp 等多个小函数，反而破坏可读性，且大概率编译器仍不内联

真正影响框架性能的，通常是连接池配置、缓存策略、逃逸分析结果和 goroutine 泄漏——这些比盯着 //go:inline 实际得多。

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