go编译器会条件内联函数，仅对小且简单的函数默认内联；可用-gcflags="-m=2"查看内联情况，//go:inline和//go:noinline需紧贴函数声明且无空行，跨包调用默认不内联。
Go 编译器会不会自动 inline func？
不会无条件 inline，得看函数体大小、调用上下文和编译器版本。Go 的 inline 是保守策略：默认只对「小且简单」的函数触发，比如 1–2 行、无闭包、无 defer、无 recover 的函数。
实操建议：
-
go build -gcflags="-m=2"可查看哪些函数被 inline（输出里出现can inline xxx或cannot inline xxx: too complex） - Go 1.19+ 默认开启 inline；旧版需确保未加
-gcflags="-l"（禁用 inline） - 函数内联与否不取决于是否加
//go:noinline—— 这是强制禁止，不是开关
//go:inline 和 //go:noinline 怎么用才生效？
这两个是编译器指令（pragmas），必须写在函数声明正上方，且中间不能有空行或注释隔开，否则完全失效。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 写了
//go:inline但没 inline → 很可能因格式不对被忽略（比如上面隔了空行，或写成了//go:inline()） - 函数用了
defer或reflect.Value.Call→ 即使加了//go:inline也必然失败（编译器直接拒绝） -
//go:noinline对方法接收者为接口类型的方法无效（Go 不支持内联接口方法调用）
正确写法示例：
//go:inline
func add(a, b int) int {
return a + b
}
inline 后代码体积反而变大？为什么
因为 inline 把函数体复制到每个调用点，如果一个函数被调用 10 次，就可能生成 10 份相同指令 —— 尤其当函数含常量字符串、大数组字面量或冗余类型转换时，体积增长明显。
性能 / 兼容性影响：
- 小函数 inline 通常提升性能（省去 call/ret 开销、利于寄存器分配）
- 但若函数含
fmt.Sprintf或json.Marshal，inline 后会把整个标准库相关符号链都拉进来，静态链接体积激增 - 交叉编译时（如 linux/amd64 → darwin/arm64），inline 行为一致，但最终二进制大小差异可能放大
什么时候该主动干预 inline？
多数时候不用管，但遇到以下场景值得检查：
- 热路径上反复调用的纯计算函数（如
abs,min,isPowerOfTwo）→ 加//go:inline明确提示 - 调试时发现某函数调用开销异常高（pprof 显示大量
runtime.call*）→ 用-gcflags="-m=2"看是否被拒 inline，再排查原因 - 发布版二进制超限（如嵌入式环境限制 5MB）→ 用
go tool objdump -s main\.main your_binary找出被 inline 膨胀的函数，针对性加//go:noinline
最易被忽略的一点：inline 是 per-package 的决策，跨包调用默认不 inline（除非被调用方用 //go:inline 且满足所有条件），所以工具函数放错包，优化就白做了。
