必须用 syscall 而非 os 的场景包括：调用未封装的系统调用（如 memfd_create）、精确控制 fd 标志、fork-exec 间 fd 操作、自定义信号处理；Syscall 允许 goroutine 调度，RawSyscall 绕过调度仅用于 fork/exit 等不可中断调用。
Go 的 syscall 包不是跨平台安全的抽象层，而是对操作系统原生系统调用的薄封装；直接使用它意味着你主动承担平台差异、ABI 变更和 ABI 兼容性风险——除非你在写 cgo 替代方案、容器运行时底层、或需要绕过 runtime 的极少数场景，否则优先用 os、os/exec、net 等标准库高层 API。
什么时候必须用 syscall 而不是 os？
只有当你要触发 os 包明确不暴露、也不打算暴露的底层行为时才需要。典型场景包括：
- 调用未被 Go 标准库封装的系统调用（如 Linux 的
memfd_create、pidfd_open） - 精确控制文件描述符标志（如
O_CLOEXEC与O_NONBLOCK组合，且不能被os.OpenFile自动覆盖） - 在 fork 后 exec 前做 fd 操作（如关闭特定 fd、设置
setpgid），避免os/exec.Cmd的封装干扰 - 实现自定义信号处理逻辑（比如用
syscall.Signalfd接收信号事件流，而非阻塞signal.Notify）
syscall.Syscall 和 syscall.RawSyscall 的区别在哪？
两者都用于发起系统调用，但关键差异在于是否让 runtime 插手调度：
-
syscall.Syscall：会先让 goroutine 进入系统调用状态（runtime 知道你在等内核），允许其他 goroutine 在此期间继续运行；适用于大多数常规调用（如read、write） -
syscall.RawSyscall：完全绕过 runtime 调度干预，调用期间 goroutine 被视为“不可抢占”，可能阻塞整个 M（OS 线程）；仅用于极少数不能被中断的调用（如fork、exit），否则容易引发调度延迟甚至死锁
例如在 Linux 上调用 getpid，应写成：
pid, _, _ := syscall.Syscall(syscall.SYS_GETPID, 0, 0, 0)
而不是 RawSyscall —— 因为 getpid 不会阻塞，且不需要规避 runtime。
