go 1.17起amd64架构默认启用寄存器传参，旨在规避栈访问延迟与缓存压力；确认方式是用go tool compile -s查看汇编，若见movq ax, cx等寄存器间操作即为寄存器路径，若见movq 8(sp), ax则已降级至栈传递。
Go 1.17 起在 amd64 架构上默认用寄存器传参，不是“更高级”，而是实打实为了避开栈访问延迟和缓存压力——尤其在高频小函数调用场景下，寄存器路径能稳压栈路径一头。
怎么确认你的函数真正在走寄存器传参？
别靠猜，看汇编。最直接的方式是用 go tool compile -S 输出汇编，再搜函数名定位参数加载逻辑：
- 看到类似
MOVQ AX, CX、ADDQ BX, CX这种操作，说明a在AX、b在BX，全程没碰SP，就是寄存器路径 - 如果出现
MOVQ 8(SP), AX或MOVQ 16(SP), BX，说明参数被降级到栈了——常见于禁用了内联（-gcflags="-l"）或参数超限 - 注意：加
-l会强制关闭内联，可能掩盖真实优化效果；性能验证务必用默认构建（即不加-l）
哪些情况会让寄存器传参失效？
寄存器红利不是自动到账的，以下情形会触发回退到栈或额外内存操作：
-
[1024]byte这类大数组：不可寻址，编译器静默转为指针传递，但调用前得先复制到临时栈空间再取地址 - 含可变参数的函数（
func f(x int, y ...string)）：y总是落栈，且调用方需构造切片头，开销陡增 - CGO 边界函数（
import "C"）：必须服从 C ABI，全部参数走栈，Go 的寄存器约定在此彻底中断 - 值接收者过大（如
func (v VeryLargeStruct) M()）：即使内联成功，复制成本仍在，无法规避
amd64 和 arm64 的寄存器分配差异大吗？
非常大，不能套用同一套经验：
- amd64 下前 15 个整型/指针参数走
AX/BX/SI/DI等通用寄存器；浮点走X0–X14 - arm64（
GOARCH=arm64）只给前 8 个参数分配R0–R7，超出部分立刻落栈；浮点用S0–S7，规则完全不同 - 结构体传参也不同：amd64 下 ≤ 2 个机器字（如
struct{a,b int64}）整体进寄存器；arm64 对齐和拆分逻辑更复杂，建议实测-S输出
寄存器传参的边界很实在——它只对“小而多”的参数友好；一旦涉及大值、可变长、跨语言边界，就得老老实实面对栈或指针间接访问。真正容易被忽略的，是交叉编译时寄存器数量骤减带来的性能落差，不是所有平台都配得上“前15个”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
