必须加-l -m，否则go tool compile -s输出的是未经ssa优化的原始汇编，无法观察内联、逃逸分析、寄存器分配等关键优化行为；-l禁用内联便于定位内联失败原因，-m打印逃逸与内联决策，-m -m则展示ssa阶段详细优化步骤。
go tool compile -S 看汇编前必须加 -l -m
不加 -l -m，go tool compile -S 输出的只是原始汇编，完全没经过 SSA 优化，看不出内联、逃逸、寄存器分配等关键信息。真正想观察编译器做了什么优化，至少要带上 -l（禁用内联）和 -m（打印优化决策），通常还要叠加使用。
-
-l单独用会禁掉所有函数内联，方便定位哪些调用本该被内联却没成功 -
-m打印逃逸分析结果和内联决策，比如can inline xxx或xxx escapes to heap -
-m -m（两个-m）开启更详细日志，显示 SSA 阶段的优化步骤，如deadcode、looprotate、boundscheckelim - 配合
-gcflags在go build中使用更实用：例如go build -gcflags="-l -m -m" main.go
为什么 -m 输出里看不到内联成功，但函数体又没调用指令？
这是常见误解：不是所有 can inline 都等于最终内联发生。编译器在 SSA 后端还会根据成本模型二次筛选，尤其当函数含闭包、接口调用、或逃逸变量时，即使标记了 can inline，也可能在生成代码阶段放弃。
- 检查是否含
func() {}字面量——闭包几乎必然阻止内联 - 看是否有
interface{}参数或返回值——类型擦除导致无法静态判定行为 - 用
go tool compile -S -l -m main.go 2>&1 | grep "inline.*your_func"确认实际是否生成了内联代码 - 对比加
-l和不加-l的-S输出：若不加-l的汇编里已无CALL your_func，说明它已被内联；加了-l后出现CALL，才说明原本依赖内联优化
go tool compile -S 输出汇编看不懂，关键要看哪几行？
Go 的汇编不是 AT&T 或 Intel 风格，而是 Plan 9 汇编（但已逐步向 GNU 风格靠拢）。重点不是逐行翻译，而是抓信号：
- 找
TEXT main.your_func(SB)段——这是函数入口，看它是否包含大量MOVQ/ADDQ而没有CALL，大概率已内联 - 找
CALL runtime.newobject(SB)或CALL runtime.mallocgc(SB)——说明有堆分配，对应逃逸分析失败 - 找
PCDATA/FUNCDATA行——这些是调试/垃圾回收元数据，可忽略 - 对比两个版本输出时，用
diff -u 直接看差异点
想验证 bounds check 消除或 nil check 消除，怎么写测试代码？
编译器只在确定索引安全时才消除边界检查，不能靠“看起来安全”的代码触发。必须构造能被静态证明的场景：
- 切片遍历用
for i := 0; i —— 编译器能证明 <code>i始终，通常消除 <code>bounds check - 避免
s[i+1]这类跨步访问，除非明确i+1 且 <code>i有上界约束 - nil check 消除需要指针解引用前有显式非空判断：比如
if p != nil { return *p }，此时*p后续不会生成testq检查 - 用
go tool compile -S -l -m -m main.go 2>&1 | grep -E "(bounds|nil) check"直接搜索关键词，比肉眼看汇编更快
-m -m 日志比汇编更直接；而真正卡性能的点，往往藏在逃逸分析失败导致的隐式堆分配里——那才是 -m 最该盯住的地方。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
