go汇编文件名必须带架构后缀（如add_amd64.s），否则构建系统静默忽略；函数符号须用·add(sb)格式并匹配go签名；性能关键路径才用汇编，其余用go实现。
Go 汇编文件名必须带架构后缀，否则构建会静默忽略
Go 的构建系统靠文件名识别汇编代码的适用架构，不是靠内容或注释。如果你写了 add.s 却想在 arm64 上用，go build 根本不会把它编译进去——也不会报错，只会当它不存在。
正确做法是严格按 name_$(GOARCH).s 命名，比如：
-
add_amd64.s→ 仅用于GOARCH=amd64 -
add_arm64.s→ 仅用于GOARCH=arm64 -
add_386.s→ 仅用于GOARCH=386
不支持通配（如 add_*.s），也不支持在文件里写条件编译指令（Go 汇编没有 #ifdef）。命名错了，就是“看不见”，不是“报错”。
函数符号必须用 Go 可导出名，且需匹配 Go 函数签名
Go 汇编里写的函数，要被 Go 代码调用，名字不能随便起。它必须和 Go 中声明的函数名完全一致，并加前导点（·），比如 Go 里写 func Add(a, b int) int，汇编里就得定义 TEXT ·Add(SB), NOSPLIT, $0-24。
立即学习“go语言免费学习笔记（深入）”；
常见错误：
- 漏掉
·（写成TEXT Add(SB)）→ 链接时报undefined: Add - 参数大小算错（
$0-24表示栈帧 0 字节，参数+返回值共 24 字节）→ 运行时栈损坏或结果错乱 - 没加
NOSPLIT又在函数里用了可能触发栈分裂的操作（如调用其他函数）→ 崩溃或死锁
Go 1.17+ 默认启用 framepointer，如果汇编里手动改了 FP 或 SP，得同步维护帧指针，否则 panic 信息会错位。
跨架构共享逻辑？用 Go 实现兜底，汇编只做性能关键路径
别试图用一堆 _amd64.s、_arm64.s 覆盖所有路径。真正需要手写汇编的场景极少：比如密码学轮函数、向量化内存拷贝、原子操作扩展。其余一律用 Go 写，让编译器自己优化。
推荐结构：
- 主逻辑写在
add.go，含完整函数签名和基础实现 - 性能敏感路径用
//go:build amd64 || arm64+// +build amd64 arm64控制，再配对应add_amd64.s和add_arm64.s - 确保每个
.s文件开头有//go:build注释，否则go list -f '{{.GoFiles}}' .可能漏掉它
Go 不支持一个函数在不同架构下“自动选”汇编实现；它靠构建时文件存在性决定是否链接。没对应 .s 文件，就退回到 Go 版本——这是设计使然，不是 bug。
调试汇编函数最有效的三件事
汇编出问题，别先翻 ABI 文档。先做这三步：
- 用
go tool compile -S pkg/file.go看 Go 编译器是否真的引用了你的汇编函数（搜TEXT.*·Add） - 用
go tool objdump -s 'main\.Add' ./binary确认目标二进制里确实嵌入了该符号，且指令对得上 - 在汇编函数开头插
CALL runtime·breakpoint(SB)（注意是runtime·breakpoint，不是 C 的int3），然后用dlv跟进去单步
容易被忽略的是：Go 汇编的寄存器命名（AX, BX）和实际 CPU 寄存器一致，但栈帧布局、参数传递顺序（从左到右压栈，返回值在栈顶）和 Go 的调用约定强绑定。偏离一点点，就不是“结果不对”，而是“直接 crash”。
