Go底层系统调用直接按ABI装入寄存器，不进行Go值拷贝；传指针仅传递地址数值，修改原内存依赖内核读写；uintptr需配合unsafe.Pointer和runtime.KeepAlive确保GC安全。
Go 语言底层系统调用（如 syscall.Syscall、syscall.RawSyscall 及其变体）不走 Go 的普通函数调用路径，而是直接对接操作系统 ABI。它绕过 Go 运行时的栈帧管理与参数传递规则，**不涉及 Go 层面的“值拷贝”语义**——你传进去的整数、指针，是直接按平台 ABI 要求塞进寄存器或栈槽的原始位模式，没有副本创建过程。
系统调用函数本身不进行 Go 式参数拷贝
Go 的 syscall.Syscall 等函数本质是 tiny wrapper，最终调用的是汇编 stub（如 sys_linux_amd64.s），它只做三件事：把传入的参数按顺序装入 RAX（syscall number）、RBX、RCX、RDX、RSI、RDI（Linux amd64），然后执行 SYSCALL 指令。这些参数是原始值，不是 Go 变量的副本。
-
syscall.Syscall(123, uintptr(0), uintptr(0), uintptr(0))中的三个uintptr值，直接被 mov 到寄存器，没经过任何 Go runtime 的复制逻辑 - 传指针（如
&buf[0]）时，传的是该地址的数值，不是“指针变量的副本”，更不是对底层数组的拷贝 - 即使你传一个大结构体的地址（
unsafe.Pointer(&s)），也只传一个指针值（8 字节），不会触发结构体内容拷贝
为什么传指针能修改原数据？和函数传参无关
这不是因为“系统调用函数支持引用传递”，而是因为：你显式传了一个内存地址过去，内核根据这个地址去读写用户空间内存。Go 层面的 copy、结构体赋值、函数参数传递等机制，在这里完全不生效。
- 错误认知：“
syscall.Read(fd, buf)修改了buf，所以是引用传递” —— 实际上buf是切片，syscall.Read内部取的是buf[0]地址（即uintptr(unsafe.Pointer(&buf[0]))），然后把这个地址交给内核；内核写内存，自然改的是原底层数组 - 如果你传一个未初始化的 nil 切片（
nil），syscall.Read会因传入非法地址而返回EINVAL或 panic，不会静默失败 - 传
unsafe.Pointer时，必须确保目标内存生命周期覆盖整个系统调用周期，否则可能访问已释放内存
寄存器使用与平台 ABI 绑定，不抽象、不可移植
Go 的 syscall 封装严格遵循目标平台的 ABI（Application Binary Interface）。这意味着：
- amd64 Linux：前 6 个参数进寄存器（
RAX~RDI），多余参数压栈；RAX返回 syscall number，RAX和RDX返回结果 - arm64 Linux：用
X0~X7，X0放 syscall number，X0和X1返回结果 - Windows amd64：用
RCX、RDX、R8、R9传前 4 参数，其余压栈；RAX返回状态 - Go 不做跨平台参数重排或转换 —— 你写的
Syscall(trap, a, b, c)在不同平台生成的汇编完全不同，但行为一致（只要 ABI 定义一致）
容易被忽略的坑：uintptr 与 GC 安全边界
当你把指针转成 uintptr 传给 syscall，Go 编译器无法跟踪该地址是否仍被引用。如果此时发生 GC，且该内存没有其他强引用，可能被回收 —— 即使 syscall 还没执行完。
- 正确做法：用
unsafe.Pointer保持引用，再转uintptr，并在 syscall 调用前后用runtime.KeepAlive显式延长生命周期 - 例如：
p := &data; ret := syscall.Syscall(trap, uintptr(unsafe.Pointer(p)), 0, 0); runtime.KeepAlive(p) - 切片传参（如
buf）内部已隐含处理了KeepAlive（标准库实现中会 pin 底层数组），但自定义指针必须手动处理 - 不要在 syscall 前把指针存到全局变量再转
uintptr—— GC 可能在中间清理掉它
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
