syscall.Syscall 不跨平台：Linux 用 Syscall/Syscall6，Windows 用 NewLazySystemDLL+Proc.Call 或 x/sys/windows，macOS 推荐 x/sys/unix；官方弃用标准 syscall，推荐 x/sys 下平台专用子包。
syscall.Syscall 在 Linux 和 Windows 上根本不能通用
Go 的 syscall 包不是跨平台抽象层，而是对底层 C syscall 的薄封装。Linux 用 syscall.Syscall（三个参数），Windows 用 syscall.SyscallN（可变参数），macOS 则多数系统调用需通过 syscall.Syscall6 或更高级的 unix 子包。直接写 syscall.Syscall(123, a, b, c) 在 Windows 上会编译失败，在 macOS 上可能传参错位。
- Linux：
syscall.Syscall/syscall.Syscall6对应不同参数个数的 syscall 号调用 - Windows：必须用
syscall.NewLazySystemDLL+Proc.Call，或直接用golang.org/x/sys/windows - macOS：推荐用
golang.org/x/sys/unix，它封装了syscall的平台差异，比如unix.Kill、unix.Mmap
用 golang.org/x/sys 替代原生 syscall 包才是实际做法
官方明确建议弃用标准库的 syscall，改用 golang.org/x/sys 下的 unix（Linux/macOS）或 windows（Windows）子包。它们提供类型安全、参数命名清晰、错误处理统一的接口。
-
unix.Open("/tmp/foo", unix.O_RDONLY, 0)比syscall.Syscall(syscall.SYS_OPEN, ...)易读且不易错 -
windows.CreateFile返回windows.Handle而非裸整数，避免误传给 Unix 函数 - 所有函数都返回
error，不再需要手动比对errno - 交叉编译时，未导入的平台子包不会参与构建（如只 import
unix，Windows 构建会跳过）
直接调用 syscall 时如何避免 errno 解析错误
即使用了 golang.org/x/sys，某些场景仍需检查原始 errno（比如判断是否为 EAGAIN 或 EINTR）。但注意：err 不等于 errno —— 它是包装后的 *syscall.Errno，需类型断言。
- 正确方式：
if e, ok := err.(*syscall.Errno); ok && *e == syscall.EINTR { ... } - 错误方式：
err == syscall.EINTR（永远不成立，因为syscall.EINTR是 int，而err是接口） - 在
unix包中，应使用unix.Errno类型：if e, ok := err.(unix.Errno); ok && e == unix.EAGAIN - Windows 下对应的是
windows.Errno，值与 Unix 不同，不可混用
syscall.Exec 的坑：它不会返回，且当前 goroutine 会被替换
syscall.Exec（或 unix.Exec）执行成功后，**当前进程镜像被完全替换，Go 运行时终止，所有 goroutine 销毁**。这不是 fork+exec，没有父进程等待逻辑 —— 它等价于 C 的 execve。
立即学习“go语言免费学习笔记（深入）”；
- 调用后代码不会继续执行，所以
defer、recover、日志打印全部失效 - 若想实现类似 shell 的 exec 行为（替换当前进程），必须确保参数全为绝对路径，且
argv[0]与可执行文件名一致 - 若只是想启动子进程，应该用
os/exec.Command，它内部自动 fork+exec，保留 Go 环境 - 在 CGO disabled 模式下，
unix.Exec可能不可用，需检查构建约束
真正难的不是调用 syscall，而是理解每个平台对“系统调用”语义的定义差异 —— 比如 Windows 的句柄 vs Unix 的 fd，或者 macOS 的 Mach-O 特定调用。别试图写一次代码跑三端，按平台拆分逻辑、用 build tag 控制，反而更稳。
