确认函数是否真被内联，唯一可靠方式是go build -gcflags="-m=2"并查看输出中是否有inlining call to xxx；仅can inline不代表实际发生，因编译器后续成本模型可能否决。
Go 编译器优化不是靠猜的，必须用 go build -gcflags 系列命令实测验证。默认开启的内联、逃逸分析等行为，不看输出日志就等于没调优。
怎么看函数是否真被内联了？用 -m=2，别只写 -m
单个 -m 只会告诉你 “can inline foo”，但实际有没有 inline，得看 -m=2 输出的 inlining call to xxx 这一行。
-
go build -gcflags="-m=2" main.go 2>&1 | grep "inline"是最常用组合 - 看到
./main.go:42:6: inlining call to parseJSON→ 成功内联 - 看到
./main.go:45:10: cannot inline handleRequest: uses defer→ 明确失败原因 - 如果函数用了
defer、recover、闭包捕获变量或太大（超过 budget），编译器会直接拒绝内联
怎么确认变量有没有逃逸到堆上？必须双 -m，即 -m -m
单 -m 只显示粗略结论，双 -m 才暴露关键线索，比如参数是否“leaking”、闭包是否隐式分配。
-
go build -gcflags="-m -m" main.go输出中关注这几类提示： -
&x escapes to heap→ x 的地址被返回或存入 map/slice/goroutine，强制堆分配 -
leaking param: s to result ~r0 level=0→ 参数 s 直接作为返回值传出，几乎必然逃逸 -
&x does not escape→ x 可安全驻留栈上，这是理想状态 - 注意：
sync.Pool.Put(x)因接收interface{}，即使 x 很小也会触发装箱和堆分配
怎么验证 SSA 阶段优化生效？用 go tool compile -S -l -m
go tool compile -S 默认输出的是未优化汇编；不加 -l 和 -m，你看到的可能是“假优化”结果。
立即学习“go语言免费学习笔记（深入）”；
- 正确命令：
go tool compile -S -l -m main.go -
-l禁用内联，让汇编对应源码结构更清晰（便于比对） -
-m同时输出逃逸信息，和汇编指令交叉对照 - 重点观察：边界检查是否消失（如
MOVQ AX, (DX)而非带CALL runtime.panicindex的版本）、寄存器复用是否密集、函数调用是否被展开
调试时想关掉优化？别只用 -l，要配 -N
-l 只禁用内联，但逃逸分析、死代码消除等仍在运行，断点可能仍不准。真要调试，得关全。
-
go build -gcflags="all=-N -l" main.go→ 彻底关闭所有优化，保留完整调试符号 -
all=前缀确保子包也受控，避免某些依赖包仍被优化干扰堆栈 - 生产构建千万别用这个组合；它会让二进制变大、执行变慢，且逃逸行为失真
- 日常开发中，
-N -l适合定位“为什么断点跳过了”或“为什么变量值看不到”这类问题
真正难的不是记命令，而是把 -m=2、-m -m、-S -l -m 三组输出串起来看：一个函数是否内联，直接影响它内部变量是否逃逸；而逃逸结果又决定最终汇编里有没有堆分配指令。漏掉任一环，优化分析就是盲人摸象。
