是的，内联会彻底消除被内联函数的栈帧，编译后该层调用在机器码中不生成call指令，而是直接嵌入指令；runtime/debug.Stack()或pprof中将不可见该函数，加//go:noinline可验证。
内联不会改变调用栈的逻辑结构，但会彻底消除被内联函数的栈帧——这不是“压平”或“合并”，而是让那层调用在编译后根本不存在。
内联后栈帧真的消失了吗
是的。只要编译器决定内联 max，那么 max(a, b) 这行代码在生成的机器码里就不再是一次 call 指令，而是直接嵌入了比较和返回的指令。你用 runtime/debug.Stack() 或 pprof 查栈时，永远看不到 max 这一层。
- 验证方式：加
//go:noinline后再跑 pprof，对比两次 goroutine stack trace 输出，有无该函数名就是最直接证据 - 注意：内联只发生在编译期，运行时无法动态开启/关闭；
go tool compile -gcflags="-m=2"输出中出现can inline才算真正生效 - 跨包函数默认不内联，即使函数体极简——除非加
//go:inline（Go 1.19+）且满足其他条件
为什么有些函数死活不被内联
编译器不是按“行数少”就放行，而是基于 AST 复杂度、控制流结构和逃逸行为综合判断。常见拦路虎包括：
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
defer、recover、go、select：这些语句强制生成额外状态机代码，AST 节点数暴增，直接触发cannot inline xxx: too complex - 含闭包的函数：闭包本身是 heap 分配对象，且调用目标无法静态确定，编译器放弃内联
- 返回大 struct（如超过 32 字节）或 interface{}：可能触发逃逸，同时增加内联膨胀成本，编译器倾向于保守处理
- 函数参数含 slice、map、chan：底层指针易逃逸，且 ABI 传参开销变大，内联收益被抵消
内联对栈深度的实际影响有限
它只减少“单次调用”的栈帧，不解决深层递归问题。比如树遍历中反复调用 visit(node)，就算 visit 被内联，每次迭代仍要压入新栈帧——因为那是循环体内的新调用，不是原地展开。
立即学习“go语言免费学习笔记（深入）”；
- 真正降低栈深度的方式只有：把递归改迭代、用显式栈（
[]*Node）、拆分 goroutine（但会引入调度开销） - 内联对栈的“减负”仅体现在热路径上高频小函数，例如
bytes.Equal、strings.HasPrefix这类标准库函数，它们被内联后能省掉纳秒级压栈，但对整体栈大小几乎无感 - 别指望靠内联避免
stack overflow：goroutine 初始栈 2KB，1000 层递归就大概率扩容失败，而内联连第一层都救不了
内联是个安静的优化，它不声不响抹掉某些函数的踪迹，但也不会帮你扛住真正的栈压力。最容易被忽略的是：你以为自己写了个可内联的小函数，结果因为传了 map[string]interface{} 或加了 defer，它早被编译器悄悄拒之门外了。
