编译器自动内联会静默丢弃defer；逃逸分析保守导致意外堆分配；常量传播可彻底消除调试代码；循环展开仅适用于编译期长度确定的数组。
编译器自动内联函数会绕过 defer 执行逻辑
Go 编译器在 -gcflags="-l" 关闭内联或高优化等级下，可能将小函数（如空 func() {}、单行返回）直接展开。若该函数含 defer，内联后 defer 语句会被提升到调用方作用域，但实际执行时机仍绑定原函数退出点——而原函数已不存在，导致 defer 被静默丢弃。
- 典型触发场景：
defer写在仅被调用一次、且函数体极简的辅助函数中 - 验证方式：用
go build -gcflags="-l -m" main.go查看内联报告，搜索inlining call to和cannot inline - 规避方法：给函数加
//go:noinline注释，或确保defer所在函数有至少两个非平凡语句（如额外变量声明 + return）
逃逸分析不准会导致意外堆分配和 GC 压力
Go 编译器通过逃逸分析决定变量分配在栈还是堆。但该分析是保守的：只要存在任何可能逃逸的路径（哪怕 runtime 不会走），就强制堆分配。常见误判包括：
- 将局部切片传给接受
interface{}的函数（如fmt.Println(s)），即使该切片生命周期明显短于调用 - 闭包捕获了本可栈存的变量，尤其当闭包被赋值给全局变量或返回给上层时
- 使用
reflect.Value或unsafe.Pointer间接引用局部变量，逃逸分析无法跟踪
检查方式：用 go build -gcflags="-m -l" main.go，关注 ... escapes to heap 行。注意：-l 关闭内联后逃逸结果更接近真实运行时行为。
常量传播与死代码消除让部分日志/调试代码彻底消失
当条件判断基于编译期可知常量（如 const debug = false），且分支内无副作用（如不调用 println、不修改全局状态），Go 编译器会在 SSA 阶段直接删掉整个分支。这意味着：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
if debug { log.Println("x =", x) }在debug = false时，不仅日志不打，连x的读取、字符串拼接等操作全被移除 - 若
x是函数调用（如getExpensiveData()），该调用也不会执行——这和“条件断点”预期不符 - 使用
log.Printf代替log.Println不影响消除，因为格式化本身也是纯计算（无副作用）
保留调试逻辑的方法：用 if debug == true { ... } 无帮助；必须引入运行时变量（如 var debug = flag.Bool(...)）或显式副作用（如 _, _ = x, debug）阻止优化。
循环展开只对确定长度数组生效，slice 永远不展开
Go 编译器仅对长度已知的数组（[4]int）在循环中做展开，且需满足：循环次数 ≤ 8、循环体简单、未启用 -gcflags="-l"（内联关闭会抑制展开）。slice（[]int）无论 len 是否编译期已知，都不会被展开。
func sumArray(a [4]int) int {
s := 0
for i := 0; i < len(a); i++ {
s += a[i]
}
return s
}
// 编译后实际生成类似：
// s += a[0]; s += a[1]; s += a[2]; s += a[3];
而相同逻辑作用于 func sumSlice(s []int) int，始终保留循环结构。想强制展开 slice 循环？只能手写展开，或改用 for range 配合编译器自动向量化（仅限简单算术，且需 CPU 支持 AVX/SSE）。
真正难处理的是逃逸分析与内联的耦合效应：一个函数是否内联，直接影响其内部变量是否逃逸。没有工具能一键可视化整条优化链路，只能靠 -m 多次迭代+最小复现样例交叉验证。
