Go汇编是对接Go运行时ABI的Plan9语法桥梁，需Go代码主动声明符号、正确命名文件、使用Unicode中点、严格匹配TEXT契约及FP参数寻址，且AVX指令须配VZEROUPPER并确保内存对齐。
Go 汇编不是“写机器码”，而是用 Plan 9 风格语法对接 Go 运行时 ABI 的桥梁。它不能脱离 Go 代码单独存在，也不能靠查 Intel 手册直接套用——写错一个符号前缀、栈帧大小或寄存器映射，undefined 或静默跳过就是最常见反馈。
为什么 Go 汇编函数总报 undefined
根本原因：Go 编译器不扫描 .s 文件自动注册符号，必须由 Go 源码“主动认领”。它不像 C 那样靠链接器合并目标文件，而是靠声明驱动查找。
- 没在同包
.go文件里写对应函数签名（哪怕空实现），例如func add(a, b int64) int64—— 编译器根本不知道要找·add - 汇编文件名不是
xxx_amd64.s（或匹配当前GOARCH），比如错写成add.s，会被构建系统忽略 - 函数在汇编中用了英文点
.add(SB)，但正确写法是 Unicode 中点·add(SB)（U+00B7），否则符号无法导出 - 函数定义在子目录或
internal/下，Go 规则禁止跨包调用汇编符号
TEXT ·foo(SB), NOSPLIT, $0-32 这行到底在说什么
这是 Go 汇编的“契约头”，每个字段都绑定运行时行为，改错就可能栈溢出、GC 崩溃或调度异常。
-
TEXT是伪指令，表示代码段开始；·foo(SB)中SB是静态基址，·表示包级私有（等价于小写函数名） -
NOSPLIT必须加：告诉 runtime 不要在此函数内插入栈分裂检查点，因为手写汇编没做栈增长适配 -
$0-32是关键参数：前面0是局部变量栈空间字节数（这里为 0），后面32是“参数 + 返回值总大小”（如两个int64输入 + 一个int64输出 = 24 字节，但需按 8 字节对齐，所以写$0-32） - 漏掉
NOSPLIT可能在 goroutine 栈快耗尽时 panic；$0-32写成$0-24会导致后续参数偏移错位，读到脏数据
参数怎么传？为什么用 a+0(FP) 而不是 MOVQ 0(SP), AX
Go 不用传统 SP 基址寻址，而是用伪寄存器 FP（Frame Pointer）统一描述参数布局。它和 C 的 rbp 不同，是编译器维护的逻辑指针，不随栈移动而变。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
FP始终指向第一个参数起始位置，0(FP)是第 1 个参数，8(FP)是第 2 个（64 位平台），依此类推 - 参数名必须和 Go 声明一致，例如 Go 里写
func add(x, y int64)，汇编里就得用x+0(FP)和y+8(FP)，不能只写+0(FP) - 直接操作
SP极危险：Go 的 SP 是动态栈顶，且 runtime 会重定位栈，手算偏移大概率踩内存 - 返回值也通过
FP偏移写回，如~r2+16(FP)（第三个返回值，16 字节后），不靠寄存器隐式约定
AVX2 或 vpaddd 为什么一用就 panic
不是指令写错了，而是破坏了 Go 运行时对 FPU 状态的假设。AVX 指令会污染 YMM/ZMM 寄存器高半部分，而 Go 的 GC 和调度器依赖 SSE 寄存器干净状态。
- 必须在函数末尾加
VZEROUPPER，清空 YMM 寄存器高 128 位，否则后续调用time.Now()等 runtime 函数会触发illegal instruction - 内存地址必须 32 字节对齐，
vpaddd对未对齐地址会触发 #GP 异常，得先用ANDQ $-32, AX截断，再手动处理头尾 - 不能假设 CPU 支持：Go 不做运行时 CPUID 分发，
GOAMD64=v3只保证 AVX2 可用，AVX-512 必须显式检测cpuidbit 16/17 后再跳转，否则在老 CPU 上直接崩溃 - 小数据量（
真正卡住人的从来不是指令怎么写，而是 ABI 细节和运行时契约——比如 FP 偏移是否对齐、NOSPLIT 是否遗漏、VZEROUPPER 是否忘记。这些点不靠调试器看不出来，只能靠 go tool compile -S 对照生成汇编反复验证。
