Go 的 syscall 包非跨平台抽象，Windows 和 Linux 的系统调用接口差异大，直接使用会导致 panic 或错误；应优先选用 golang.org/x/sys/unix（Linux/macOS）或 golang.org/x/sys/windows（Windows），并用 build tag 隔离平台代码。
Go 里直接用 syscall 包在 Windows 和 Linux 上会失败
Go 的 syscall 包不是跨平台抽象层，而是对操作系统原生 syscall 的薄封装。Linux 上调的是 sys_read、sys_write 这类 ABI 级接口；Windows 上则对应 NtReadFile、NtWriteFile 等 NT API，二者函数签名、参数顺序、错误码含义完全不同。硬写一套通用 syscall.Syscall 调用，在另一平台十有八九 panic 或返回 EINVAL。
常见错误现象：runtime: failed to create new OS thread (have 2 already; errno=22) 或直接 exit status 3221225477（Windows STATUS_ACCESS_VIOLATION）。
- 别直接用
syscall.Syscall+ 数字号跨平台——Linux 号是__NR_read，Windows 根本没这个概念 - Windows 上多数“系统调用”实际走的是
golang.org/x/sys/windows提供的封装，比如windows.CreateFile，它内部调CreateFileW而非裸 NT API - Linux 上若真需绕过
os包直触 syscall，优先用golang.org/x/sys/unix，它把read、write、openat等都做了类型安全封装，比裸syscall包可靠得多
golang.org/x/sys/unix 和 golang.org/x/sys/windows 怎么选
这两个包才是 Go 官方维护的跨平台 syscall 封装主力。它们不试图统一接口，而是按平台提供各自语义清晰的函数，且自动处理 ABI 差异（比如 Windows 上字符串转 UTF-16、句柄 vs 文件描述符、错误码映射）。
使用场景：需要精确控制文件打开标志（如 O_CLOEXEC）、设置 socket 选项（SO_REUSEPORT）、读取进程信息（/proc/self/status 或 GetProcessMemoryInfo）等底层操作。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Linux/macOS 项目：导入
golang.org/x/sys/unix，用unix.Open、unix.Read、unix.Getpid - Windows 项目：导入
golang.org/x/sys/windows，用windows.CreateFile、windows.ReadFile、windows.GetCurrentProcessId - 同一代码库需双平台支持？用 build tag 分离：
//go:build windows和//go:build !windows，避免编译失败 - 注意：两个包的返回值错误处理风格一致（
err != nil），但错误类型不同——unix.Errnovswindows.Errno，不能混用类型断言
为什么 os.OpenFile 够用时别碰 syscall
绝大多数业务场景下，os.OpenFile、os.Stat、net.Listen 这些高层 API 已经做了足够好的跨平台适配和错误归一化。它们内部确实调用了平台特定 syscall，但屏蔽了差异，比如把 Windows 的 ERROR_FILE_NOT_FOUND 映射为 os.ErrNotExist，Linux 的 ENOENT 也映射为同一个值。
容易踩的坑：
- 自己用
unix.Open打开文件后忘了设O_CLOEXEC，子进程继承 fd 导致资源泄漏；而os.OpenFile默认就带这个 flag - Windows 上用
windows.CreateFile传错dwCreationDisposition（比如该用CREATE_ALWAYS却写了OPEN_EXISTING），结果文件存在时直接失败，而os.Create会自动覆盖 - 性能上无优势：高层 API 与 syscall 层之间通常只多一次函数调用和结构体拷贝，瓶颈从来不在这里
跨平台 syscall 封装的边界在哪
没有银弹。哪怕用了 x/sys 系列包，仍有大量行为无法抽象：文件路径分隔符（/ vs \）、权限模型（Linux 的 rwx vs Windows 的 DACL）、信号机制（Windows 几乎不支持 POSIX signal）、甚至“进程”概念本身（Windows 的 job object、Linux 的 cgroup）。
真正要做的，是承认差异，然后隔离它：
- 路径拼接永远用
path/filepath.Join，别手拼"dir" + string(os.PathSeparator) + "file" - 权限控制优先走
os.Chmod，它在 Windows 上静默忽略（因为不适用），比自己调unix.Chmod或windows.SetFileAttributes更安全 - 涉及进程管理（如限制内存、CPU）必须按平台写两套逻辑，没有第三条路
- 最易被忽略的一点：
syscall相关的测试几乎无法 mock——别指望单元测试能覆盖所有平台分支，CI 必须跑双平台
