唯一可靠方式是运行go build -gcflags="-m=2"并查找inlining call to xxx输出；仅can inline xxx不表示真内联，跨包调用默认不内联，含defer/闭包/接口返回等任一情况即失败。
怎么确认函数到底有没有被内联
只看 can inline 不等于真内联了——这是最常踩的坑。编译器会先标记“可内联”，但最终是否展开，得看 SSA 后端的成本模型是否放行。
唯一可靠方式是加 -m=2 并 grep inlining call to：
go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"
输出类似 ./main.go:42:15: inlining call to parseHeader 才算落地。如果只看到 can inline parseHeader，但没后续，说明它被筛掉了。
- 跨包调用默认不内联，哪怕函数体就一行
return a + b -
//go:inline必须紧贴函数声明上一行，中间不能有空行或其它注释 - 加了
//go:inline但函数里有defer或闭包，编译器直接无视 pragma
哪些写法会让内联立刻失败
不是函数短就一定能内联。编译器有一套硬性拦截规则，命中任意一条就放弃，不讲情面。
-
defer、recover、panic：哪怕只有一行defer log.Println("done") - 闭包捕获外部变量：比如
func() int { return x }中的x来自外层作用域 - 返回值是接口类型（如
interface{}）或方法集非空的结构体 - 含
reflect、unsafe，或调用了标有//go:noinline的函数 - 递归函数：编译器连试都不试
这些限制和函数行数无关，也和你加没加 //go:inline 无关。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
基准测试里为什么看不到内联效果
go test -bench=. 默认强制加了 -gcflags="-l"，也就是全局关内联——这不是你漏配，是 Go 测试框架硬编码行为，从 Go 1.10 开始就没变过。
所以你在 benchmark 里测出的性能，根本不是线上真实路径。想验证真实内联效果，得绕开 go test：
- 写个
main.go，把testing.B的逻辑手动跑起来 - 用
go build -gcflags="" main.go构建（空字符串覆盖掉 test 的默认-l） - 运行
./main -test.bench=. - 加
-gcflags="-m=2"确认目标函数确实出现inlining call to
否则，你对比的其实是“禁用内联 vs 禁用内联”，完全失真。
内联真能提多少性能
通常就几纳秒，只对每秒调用上万次的热路径有意义。比如 HTTP handler 里一个 if err != nil { return err } 被内联，可能省下一次跳转和栈帧开销；但如果你因此把 parseRequest 拆成五个小函数只为“方便内联”，反而破坏可读性，还可能因逃逸分析恶化导致堆分配增多。
- 内联后二进制体积可能明显变大：一个被调用 10 次的函数，可能复制出 10 份指令
- 若该函数调用了
json.Marshal，整个encoding/json符号链会被拖进来 - 真实服务中，减少一次
interface{}类型断言，或避免一次切片append扩容，收益远大于内联
别为内联改代码结构。它是个编译器自动决策的副作用，不是你要主动追求的目标。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
