go函数调用默认用寄存器传参而非栈传参，因栈操作开销大；前15个整型/指针参数走通用寄存器，浮点走x0–x14，超限或大结构体才落栈或传地址。
Go 函数调用为什么不用栈传参？
Go 编译器（gc）在 amd64 架构下默认启用寄存器传参，不是因为“高级”，而是因为栈传参在函数频繁调用场景下会明显拖慢性能——压栈/弹栈、栈帧扩张、缓存不友好都是实打实的开销。
实际效果取决于参数数量和类型：前 15 个整型或指针类参数（int、*T、uintptr 等）优先走 AX、BX、SI、DI 等通用寄存器；浮点参数走 X0–X14；超过部分才落栈。
- 结构体传参时，若大小 ≤ 2 个机器字（如
struct{a,b int64}），通常整体进寄存器；更大的结构体直接传地址（即隐式转为*T） -
interface{}是两词结构（type ptr + data ptr），固定占两个寄存器，不因底层值变大而多占 - 闭包捕获变量不参与该约定——它们被分配在堆或函数栈帧上，通过闭包对象指针间接访问
怎么确认某个函数真正在用寄存器传参？
别猜，看汇编。Go 提供 go tool compile -S 是最直接的方式，重点关注参数加载指令是否来自寄存器而非 [SP+...] 偏移。
例如对函数 func add(a, b int) int，编译后常见片段：
立即学习“go语言免费学习笔记（深入）”；
MOVQ AX, CX ADDQ BX, CX
说明 a 在 AX、b 在 BX，结果存在 CX —— 全程无栈访问。如果看到 MOVQ 8(SP), AX 这类指令，说明参数被降级到栈了（比如内联失败 + 大量参数 + 开启了 -gcflags="-l" 关闭内联时）。
- 用
go build -gcflags="-S" main.go查看完整汇编，搜索函数名即可定位 - 注意：开启
-l会禁用内联，可能掩盖寄存器优化效果；真实性能应以未禁用内联的构建为准 - 交叉编译（如
GOARCH=arm64）寄存器分配逻辑不同，R0–R7承担前 8 个参数，需单独验证
哪些情况会让寄存器传参“失效”？
不是所有函数都能享受寄存器红利。以下情况会导致参数被迫入栈，甚至引发额外内存操作：
- 参数含不可寻址类型（如大数组
[1024]byte）：编译器会静默转为指针传递，但调用前需先将数组内容写入临时栈空间再取地址 - 函数有可变参数（
...T）：...部分总是分配在栈上，且调用方需构造切片头，开销陡增 - CGO 边界函数（
import "C"）：必须遵循 C ABI，全部参数走栈，Go 的寄存器约定在此中断 - 方法调用中接收者是大值类型（如
func (v VeryLargeStruct) M()）：即使方法内联，复制成本仍在，且无法规避
性能影响到底有多大？
微基准下，纯寄存器传参的函数比等价栈传参快 10%–30%，但这只是冰山一角。真正关键的是它缓解了 CPU 缓存压力——避免频繁访问栈内存能显著提升 L1d 缓存命中率，尤其在 hot path（如调度循环、网络包处理）中效果放大。
不过别过早优化：只有当 pprof 显示 runtime.callN 或栈操作相关采样占比异常高时，才值得回溯参数布局。多数业务代码里，结构体字段设计、内存分配模式、GC 压力的影响远大于传参方式。
一个常被忽略的点：寄存器传参让逃逸分析更“宽松”。比如 func f() *int { x := 42; return &x } 中，x 必须逃逸到堆；但如果改成 func f(x int) *int { return &x }，参数 x 本就在寄存器（或调用栈顶端），其地址仍可能被安全返回——取决于具体上下文，这点连很多资深 Go 开发者都会误判。
