Go函数栈帧由编译期确定frame size，通过SUBQ一次性调整SP分配；参数≤2个且总长≤24字节走寄存器，否则压栈；局部变量逃逸决定栈/堆存放；CALL压返回地址、RET弹跳转地址；无传统帧指针，偏移全基于SP；栈满时runtime.growstack静默扩容。
Go 函数调用时栈帧怎么分配？
Go 编译器（gc）在编译期就决定每个函数需要多少栈空间，不依赖运行时动态计算。这个大小叫 frame size，记录在函数元信息里，由 go tool objdump -s main.main 可查到。它包含：参数区、局部变量区、返回地址占位（如有）、对齐填充。
- 参数和返回值若 ≤ 2 个且总长 ≤ 24 字节，通常走寄存器（
AX/DX 等），不进栈；否则全部压栈
- 局部变量是否逃逸决定它们落在栈上还是堆上：
go build -gcflags="-m" main.go 能看到逃逸分析结果
- 栈帧不是“创建”出来的，而是通过调整
SP（栈指针）一次性划出一块连续内存，没有显式“构造函数”过程
汇编里 CALL 和 RET 到底干了啥？
Go 的 CALL 指令本质是：把下一条指令地址（即返回地址）压栈，然后跳转到目标函数入口。它不自动保存通用寄存器 —— Go 使用“caller-save”约定，调用方负责在需要时自己保存 AX/BX 等。
-
RET 只做一件事：从栈顶弹出一个值作为跳转地址，SP 自动+8（amd64）
- 你不会在 Go 汇编里看到
PUSH BP; MOV BP, SP 这类传统帧指针 setup —— Go 默认禁用帧指针（-no-frame-pointer），所有偏移都基于 SP 直接计算
- 若函数有 defer、recover 或闭包捕获变量，编译器可能插入额外栈操作（比如写入
gobuf 或保存寄存器现场），但这些不属于“栈帧本体”
为什么 runtime.growstack 会触发？
Go 的 goroutine 栈初始只有 2KB（小对象场景）或 8KB（大对象/递归深场景），当当前栈帧所需空间超过剩余可用栈时，运行时会调用 runtime.growstack 分配新栈并复制旧数据。
- 常见触发点：深度递归、大数组局部变量（如
var buf [8192]byte）、未逃逸但尺寸超限的结构体
- 注意：这不是“栈溢出 panic”，而是静默扩容 —— 所以你很少看到
stack overflow 错误，但可能遇到 runtime: out of memory（新栈申请失败）
- 可用
GOROOT/src/runtime/stack.go 查看 grow 逻辑；调试时设 GODEBUG=gctrace=1 能观察栈复制行为
想看真实栈操作？从 go tool compile -S 入手
直接看汇编最可靠。例如：
go tool compile -S main.go | grep -A5 "main\.add"
AX/DX 等），不进栈；否则全部压栈go build -gcflags="-m" main.go 能看到逃逸分析结果SP（栈指针）一次性划出一块连续内存，没有显式“构造函数”过程CALL 和 RET 到底干了啥？
Go 的 CALL 指令本质是：把下一条指令地址（即返回地址）压栈，然后跳转到目标函数入口。它不自动保存通用寄存器 —— Go 使用“caller-save”约定，调用方负责在需要时自己保存 AX/BX 等。
-
RET只做一件事：从栈顶弹出一个值作为跳转地址，SP自动+8（amd64） - 你不会在 Go 汇编里看到
PUSH BP; MOV BP, SP这类传统帧指针 setup —— Go 默认禁用帧指针（-no-frame-pointer），所有偏移都基于SP直接计算 - 若函数有 defer、recover 或闭包捕获变量，编译器可能插入额外栈操作（比如写入
gobuf或保存寄存器现场），但这些不属于“栈帧本体”
为什么 runtime.growstack 会触发？
Go 的 goroutine 栈初始只有 2KB（小对象场景）或 8KB（大对象/递归深场景），当当前栈帧所需空间超过剩余可用栈时，运行时会调用 runtime.growstack 分配新栈并复制旧数据。
- 常见触发点：深度递归、大数组局部变量（如
var buf [8192]byte）、未逃逸但尺寸超限的结构体
- 注意：这不是“栈溢出 panic”，而是静默扩容 —— 所以你很少看到
stack overflow 错误，但可能遇到 runtime: out of memory（新栈申请失败）
- 可用
GOROOT/src/runtime/stack.go 查看 grow 逻辑；调试时设 GODEBUG=gctrace=1 能观察栈复制行为
想看真实栈操作？从 go tool compile -S 入手
直接看汇编最可靠。例如：
go tool compile -S main.go | grep -A5 "main\.add"
var buf [8192]byte）、未逃逸但尺寸超限的结构体stack overflow 错误，但可能遇到 runtime: out of memory（新栈申请失败）GOROOT/src/runtime/stack.go 查看 grow 逻辑；调试时设 GODEBUG=gctrace=1 能观察栈复制行为go tool compile -S 入手
直接看汇编最可靠。例如：
go tool compile -S main.go | grep -A5 "main\.add"
你会看到类似：
0x0012 00018 (main.go:5) SUBQ <p><code>0x0012 00018 (main.go:5) SUBQ $0x28, SP0x0017 00023 (main.go:5) MOVQ AX, 16(SP)0x001c 00028 (main.go:5) MOVQ DX, 24(SP)
0x0017 00023 (main.go:5) MOVQ AX, 16(SP)0x001c 00028 (main.go:5) MOVQ DX, 24(SP)
-
SUBQ $0x28, SP就是栈帧分配（40 字节），含参数+局部变量+对齐 - 所有
SP偏移都是负数（向下增长），且必须是 16 字节对齐（SSE 指令要求） - 如果某行出现
LEAQ或MOVQ操作SP本身，说明在手动管理栈（如 syscall 或汇编内联），这时极易出错：漏恢复SP会导致后续栈混乱，panic 信息里常带invalid stack map
栈帧的边界模糊点在于：它没有元数据头，也不像 C 那样有明确 rbp 链；它的“存在”完全靠编译器生成的偏移和运行时的 g.stack 范围约束。一旦内联、逃逸分析或 gc 标记出错，问题往往表现为难以复现的栈损坏。
