直接调用syscall需手动处理系统调用号、参数布局、平台差异及内存稳定性，指针须转uintptr且确保生命周期，syscall让出m而rawsyscall锁死m，应优先使用golang.org/x/sys。
直接调用 Syscall 函数不是“写个函数名就能跑”，它要求你清楚系统调用号、参数布局、返回值语义，且必须处理平台差异和运行时干扰。不推荐在业务代码中直接用，仅限极少数绕过标准库的场景（如定制信号处理、实现 strace 类工具、调试运行时）。
为什么不能直接传 Go 变量给 Syscall
Go 的内存由运行时管理，栈可能被移动，而系统调用需要稳定地址。所以：
- 所有指针参数必须先转成
uintptr，常用模式是uintptr(unsafe.Pointer(&x[0]))（对切片）或uintptr(unsafe.Pointer(&v))（对单变量） - 不能传 Go 字符串字面量（如
"hello"）直接转指针——它底层是只读的，且生命周期不可控；应改用C.CString或显式分配可写内存 - 整数参数（如文件描述符、标志位）可直接转
uintptr，但注意符号扩展：int32转uintptr在 64 位系统上会补零，一般安全；但负值需确认目标系统是否接受
Syscall 和 RawSyscall 的关键区别在哪
两者都触发内核，但行为完全不同：
-
Syscall会在进入系统调用前让出当前 M（OS 线程），允许调度器将其他 G 迁移到空闲 M 上运行；适合常规阻塞调用（如read、accept） -
RawSyscall完全不干预调度器，M 会被锁死直到系统调用返回；适用于极短、绝不阻塞的调用（如getpid、gettimeofday），否则会导致调度器饥饿 - 错误判断方式一致：检查返回的
err是否非零；但RawSyscall不保证 errno 被正确设置（尤其在信号中断时），而Syscall会重试并标准化错误码
Linux 下怎么查系统调用号和参数顺序
别靠猜或硬编码，依赖 Go 自带定义或权威文档：
- 系统调用号定义在
syscall包里，如syscall.SYS_getpid、syscall.SYS_openat；不同架构（amd64/arm64）值不同，必须用这些常量 - 参数顺序严格按 ABI：Linux x86_64 是
rdi, rsi, rdx, r10, r8, r9；Go 的Syscall系列函数自动映射前 3 个参数到寄存器，第 4–6 个需用Syscall6 - 查手册最准：运行
man 2 getpid看原型，man 2 openat看 flag 含义（如O_RDONLY是0，O_CLOEXEC是0x80000）；不要从 C 头文件里抄数值
为什么现在应该用 golang.org/x/sys 而不是 syscall
syscall 包已冻结，不再新增功能，且部分类型（如 SysProcAttr）在 x/sys 中尚未完全替代，但新项目必须迁移：
-
x/sys/unix提供跨平台封装，比如unix.Getpid()就是安全封装，不用自己拼Syscall - 它支持更多现代系统调用（如
memfd_create、copy_file_range），而syscall包里根本没有 - 错误处理更统一：
x/sys返回error接口，可直接用errors.Is(err, unix.EINTR)判断中断，而原生Syscall返回裸Errno - 真正麻烦的是：
syscall在 Windows 上用的是 Win32 DLL 调用，x/sys/windows才是其演进版；混用会导致链接失败或运行时 panic
最易被忽略的一点：即使你用了 Syscall，只要参数里有指针，就必须确保对应内存在整个系统调用期间有效——切片底层数组不能被 GC 回收，也不能是局部变量逃逸后被复用。这不是“能编译”就代表“能正确运行”的问题，而是典型的偶发 crash 根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
