go 反射无法直接操作汇编函数
反射在 Go 中只能作用于 Interface{} 包装后的值，且仅能访问导出字段、方法和类型元信息；它完全不感知底层汇编实现。哪怕一个函数内部用 ADDQ 手写汇编，reflect.Value.Call 也只按 Go 的 ABI 调用它，不会“看到”或“修改”汇编指令。
常见错误现象：panic: reflect: Call using zero Value 或调用后行为异常，往往是因为反射传参类型不匹配——而这不是汇编的问题，是 Go 类型系统在拦截你。
- 反射调用前必须确保目标函数是导出的（首字母大写），否则
reflect.ValueOf(fn).Call拿到的是零值 - 汇编函数若未通过
//go:nosplit或//go:noescape显式标注，可能被编译器内联或逃逸分析干扰，此时反射拿到的“函数值”实际已失效 - 不要试图用
reflect.typeof判断某个函数是否“由汇编实现”——返回的只是func(...)类型，和纯 Go 函数一模一样
汇编函数必须遵循 Go 的调用约定才能被 Go 代码安全调用
Go 汇编（plan9 风格）不是独立运行的机器码，而是要嵌入 Go 的调度与 GC 生态。任意手写汇编若破坏栈帧布局、未正确保存 callee-save 寄存器、或绕过 write barrier，就会在 GC 时触发 fatal Error: morestack on g0 或堆损坏。
使用场景：仅在 runtime、sync/atomic 等极少数对性能/控制力要求严苛的模块中出现；业务代码几乎不该碰。
立即学习“go语言免费学习笔记（深入）”；
- 必须以
TEXT ·funcname(SB), NOSPLIT, $0-32开头，其中$0-32表示栈帧大小（参数+局部变量总字节数），错一点就栈溢出或踩内存 - 所有参数和返回值都通过寄存器（
AX,BX）或栈偏移传递，不能假设SP位置和 C 一样；Go 的SP是“栈顶指针”，不是“栈底基址” - 调用
runtime·gcWriteBarrier或读写指针字段前，必须插入CALL runtime·wbwrite(SB)，否则 GC 会漏掉对象
看汇编输出比手写更实用：用 go tool compile -S 理解真实调用链
与其猜某个 sync/atomic.LoadUint64 是不是汇编实现，不如直接看编译器生成的汇编——它告诉你 Go 代码最终怎么跑，包括内联、寄存器分配、是否调用 runtime stub。
执行 go tool compile -S main.go 输出里，你会看到类似：
TEXT "".main(SB) /tmp/main.go MOVQ "".x+8(SP), AX CALL runtime·nanotime(SB)这说明 time.Now() 被展开为对 runtime·nanotime 的调用，而后者才是汇编实现的函数（位于 src/runtime/time_nofake.go 对应的 time.s 文件中）。
-
-S默认只输出当前包，加-l禁用内联，更容易看清调用边界 - 搜索
TEXT.*·funcname可定位函数入口；搜索CALL.*runtime·能快速识别哪些是 runtime 汇编桩 - 注意
go tool objdump -s funcname binary看的是链接后二进制，含符号重定位，不如compile -S直观反映 Go 层语义
反射与汇编的交叉点只存在于 runtime 底层，业务层无需也不该感知
真正把两者串起来的地方，是 runtime.reflectcall 和 runtime.gogo 这类函数——它们用汇编实现函数调用跳转，同时支撑 reflect.Value.Call。但这些全是 runtime 内部契约，对外暴露的只有 Go 类型接口。
容易踩的坑：有人想用反射“热替换”汇编函数，或通过 unsafe.pointer 把汇编函数地址转成 func() 调用。这在 Go 1.20+ 几乎必然失败，因为：
- 函数地址可能被
plugin加载机制隔离，或受memory sanitizer保护 - 汇编函数若带
NOSPLIT标签，而反射调用路径需要 grow stack，会直接 panic -
unsafe.Pointer转函数类型属于未定义行为（UB），Go 编译器不保证其可移植性
如果你在 profile 里看到某个反射调用占 CPU 很高，问题从来不在汇编——而在反复创建 reflect.Value、类型检查开销、或参数拷贝。优化方向永远是缓存 reflect.Value、改用代码生成（go:generate）、或干脆别用反射。