syscall.Open不能直接传字符串，因Go字符串只读且不可寻址，系统调用需可写、稳定地址的null-terminated字节数组；正确做法是用syscall.ByteSliceFromString转为[]byte再取首地址，或手动分配并填充null终止符。
直接用 syscall 包调用系统调用，不是“换一个函数名就能提速”，而是主动放弃 Go 运行时的大部分安全保障和跨平台抽象——它只在你明确知道要绕过什么、且标准库确实做不到时才值得动。
为什么 syscall.Open 不能直接传 "path" 字符串
Go 字符串底层是只读、不可寻址的结构体，而系统调用需要可写、稳定地址的 C 风格 null-terminated 字节数组。直接 uintptr(unsafe.Pointer(&"hello"[0])) 会 panic 或 segfault。
- 正确做法：用
syscall.ByteSliceFromString("path")转成[]byte，再取首地址；或手动分配make([]byte, len(s)+1)并 copy + null terminator - 错误现象：
panic: runtime error: invalid memory address or nil pointer dereference或内核返回EINVAL - Windows 下还要注意路径分隔符和 Unicode 编码，
syscall.UTF16FromString才是正解
Syscall 和 RawSyscall 的调度行为差异直接影响并发表现
两者都触发内核，但 Go 调度器对它们的处理完全不同：前者让出 M（OS 线程），后者锁死 M 直到返回。
- 阻塞型调用（如
read、accept）必须用Syscall，否则其他 goroutine 会被饿死 - 极快非阻塞调用（如
getpid、clock_gettime）可用RawSyscall，省掉一次上下文切换开销 - 错误处理上，
RawSyscall不重试被信号中断的调用，errno可能未更新，Syscall会自动重试并标准化错误码
Linux 下 syscall.Write 没有缓冲，但也不等于“零拷贝”
绕过标准库的 bufio.Writer 确实省掉了用户态缓冲逻辑，但内核仍会做自己的 page cache 和 writeback，真正绕过缓存需显式传 O_DIRECT 标志（且文件需对齐）。
立即学习“go语言免费学习笔记（深入）”；
- 常见误判：以为
syscall.Write就是“直写磁盘”，实际仍走 page cache，除非打开文件时加syscall.O_DIRECT -
O_DIRECT要求 buffer 地址和长度都按 512B 对齐，否则返回EINVAL - 性能陷阱：小块写 +
O_DIRECT可能比带缓冲的标准库还慢，因每次都要同步刷盘
跨平台代码里 syscall 的系统调用号不能硬编码
Linux、Darwin、Windows 的系统调用号完全不同，SYS_READ 在 x86_64 Linux 是 63，在 macOS 是 3，硬写数字会导致编译失败或调用错函数。
- 必须用 Go 提供的常量，如
syscall.SYS_READ、syscall.SYS_WRITE，它们由go tool cgo自动生成 - Windows 下不走 syscall 号，而是通过
syscall.NewLazyDLL+proc.FindProc加载 DLL 函数，逻辑完全不同 - 更稳妥的做法是直接用
golang.org/x/sys/unix，它封装了平台差异，API 更稳定，且支持新内核特性（如 io_uring）
真正难的从来不是调通一个 syscall，而是确保它在不同内核版本、不同架构、不同 Go 版本下都不悄悄失效——尤其是当你的程序跑在容器里、被 seccomp 限制、或升级到新内核后突然卡住的时候。
