Go汇编仅在pprof显示函数占CPU≥30%且算法无优化空间时才值得使用；必须在同包Go文件声明原型、汇编文件名用_平台.s、函数名加Unicode中点、参数偏移和栈帧严格按ABI约定，否则符号不可见或失效。
go 汇编不能“自动加速”，它只在 pprof 显示某个函数占 cpu ≥30%、且算法已无优化空间时才值得投入——否则纯 go + 标准库 + 编译期优化更稳、更可维护。
汇编函数报 undefined 是最常见拦路虎
这不是链接失败，是 Go 编译器压根没认出你要导出的符号。根本原因就一条：Go 文件里没声明函数原型，或者声明了但签名/名字/包名和汇编文件不一致。
- 必须在同包
.go文件中写一个空实现（哪怕只有func add(a, b int64) int64 { return 0 }），让go build知道这个符号要从汇编找 - 汇编文件名必须是
xxx_amd64.s或xxx_arm64.s，后缀.s且和 Go 文件同目录、同包；不能放在internal/或子包里 - 函数名在汇编中必须加 Unicode 中点前缀：
TEXT ·add(SB), NOSPLIT, $0-16—— 这里的·是 U+00B7，不是英文点.，复制错就彻底失效 - 如果用了
GOOS=linux GOARCH=arm64 go build，但汇编里写了MOVQ（x86 指令），Go 会静默跳过该汇编文件，调用的是 Go 的空实现，不报错但性能归零
参数传入和栈帧大小必须严格匹配 ABI
Go 不用栈传参（像 C 那样），而是寄存器传参，但具体哪个寄存器由平台 ABI 决定；<p>Go 不用栈传参（像 C 那样），而是寄存器传参，但具体哪个寄存器由平台 ABI 决定；<code>$0-16 这类栈帧声明不是可选配置，是强制约定。
- AMD64 下，前两个
int64参数默认进AX和BX，返回值也放AX；但你不能直接写MOVQ a(FP), AX，得按偏移算：a+0(FP)和b+8(FP)（因为每个int64占 8 字节） -
$0-16表示“栈帧大小为 0 字节，参数 + 返回值共占用 16 字节”——两个输入各 8 字节，输出 8 字节；写成$0-24就会导致栈对齐错误，运行时 panic - 必须加
NOSPLIT：否则 runtime 可能在栈增长时插入调度点，而你的汇编里没做栈检查，会 crash - ARM64 上没有
MOVZ $123, R0这种指令，得靠 Go 汇编自动选合适指令；别手写裸指令，否则跨平台构建直接失败
验证是否真走汇编，别信直觉
写了汇编不等于被调用，更不等于生效。唯一可靠方式是反汇编对比，看最终生成的机器码是不是你写的那几条。
- 用
GOARCH=amd64 go tool compile -S main.go查看 Go 编译器为你的函数生成的汇编，确认它调用的是·add而不是内联或 runtime 实现 - 再用
objdump -d your_binary | grep -A10 'add'看实际二进制里有没有你写的ADDQ或MOVD指令 - 如果 benchmark 结果和纯 Go 版本几乎一样，大概率汇编根本没被链接进去——先查
undefined错误，再查平台匹配，最后看反汇编 - Yaegi 这类 Go 解释器明确不支持
.s文件，所有汇编路径都会 fallback 到 Go 实现，这种场景下强行写汇编毫无意义
真正卡住人的从来不是指令怎么写，而是符号导出规则、FP 偏移计算、ABI 差异这些“看不见的协议”。哪怕只差一个字节的偏移或一个错位的中点，整个函数就变成不可见的幽灵——它编译通过，运行不报错，但永远不执行。
