go汇编函数报undefined是因为未在同包go文件中声明原型，且汇编文件名、符号前缀（·）、text声明、nosplit及参数栈帧（如$0-16）等必须严格匹配。
Go 汇编函数为什么总报 undefined: myasm
Go 汇编不是独立编译的，它必须和 Go 源码配对使用，且文件名、函数签名、符号导出规则都要严格匹配。最常见的情况是：写了 func_myasm.s，但没在同包的 .go 文件里声明对应函数原型。
- 汇编函数必须在 Go 文件中用
extern声明（或更常见的是直接写func myasm() int空实现，让go build知道这个符号要从汇编找） - 汇编文件名必须以
.s结尾，且和 Go 文件在同一包、同一目录下；不能放在internal/或子包里跨调用 - 函数名在汇编中必须加前缀：
TEXT ·myasm(SB), NOSPLIT, $0-0，其中·是 Unicode 中点，不是英文点，表示包级私有符号 - 如果用了
GOOS=linux GOARCH=amd64 go build，但汇编里写了MOVQ却跑在 ARM64 上，会静默跳过汇编文件——不会报错，但实际调用的是 Go 的空实现
怎么写一个能被 Go 调用的加法汇编函数
目标很实际：替代 a + b，不为炫技，只为确认流程走通。关键是寄存器映射、栈帧大小、参数传入方式这三点。
- Go 使用寄存器传参（
AX,BX等），但具体哪个寄存器由 ABI 决定；AMD64 下前两个整数参数在AX和BX，返回值放AX -
$0-16表示“栈帧大小 0 字节，参数+返回值共 16 字节”（两个int64输入 + 一个int64输出） - 必须加
NOSPLIT，否则 runtime 可能在栈增长时插入调度点，而汇编里没做栈检查 - 示例汇编片段（
add_amd64.s）：TEXT ·add(SB), NOSPLIT, $0-16 MOVQ a+0(FP), AX MOVQ b+8(FP), BX ADDQ BX, AX RET
对应 Go 声明：func add(a, b int64) int64
ARM64 或 Windows 上写汇编容易漏掉什么
Go 汇编不是 AT&T 或 NASM，它是 Plan 9 风格，语法统一但平台差异藏在细节里——尤其指针运算、常量加载、调用约定。
- ARM64 没有直接的
MOVZ加立即数到寄存器指令？得用MOVD $123, R0，Go 汇编会自动选合适指令，别手写裸指令 - Windows AMD64 要求调用
syscall前保存所有非易失寄存器（RBX,RBP,R12–R15），但 Go 汇编默认不帮你保，得手动PUSHQ/POPQ - 所有平台都禁用浮点寄存器直接操作；想用
AVX？不行。Go runtime 不保证 FPU 状态，MOVAPS类指令可能触发 panic -
GOARCH=arm64 go tool compile -S main.go可看 Go 编译器生成的汇编，对比你写的，能快速发现参数偏移或栈对齐问题
什么时候真该写 Go 汇编，而不是信 benchmark
绝大多数场景不该碰汇编。它不提速，只在极少数确定瓶颈且编译器无法优化的地方才有意义——比如字节序转换、CRC32 手动展开、SIMD 加速的 base64 解码。
立即学习“go语言免费学习笔记（深入）”；
- 用
go test -bench=. -benchmem -cpuprofile=prof.out确认热点在某个纯计算函数里，且go tool pprof显示该函数占 CPU >30% - 先尝试用
unsafe.Pointer+reflect.SliceHeader零拷贝改写，比汇编更容易维护、也常够用 - 汇编函数无法内联，每次调用都有函数跳转开销；如果原函数本身很短（如 3 行 Go 代码），汇编反而更慢
- CI 构建必须显式支持对应
GOOS/GOARCH，否则汇编文件被忽略，线上跑的其实是 Go 版本——这种 bug 很晚才暴露
汇编不是性能开关，是最后一层薄薄的、带版本锁和平台锁的手动挡。写之前，先确认你真的踩到了编译器和硬件之间的那条缝。
