Go调用系统API本质是通过syscall包（Unix/Linux/macOS）或x/sys/windows（Windows）封装libc或原生接口；需手动处理参数、errno/错误、字符串编码及平台差异，优先使用标准库以保障安全与可移植性。
Go 调用系统 API 的本质是调用 libc 或原生系统接口
go 本身不直接暴露“系统 api 调用”这种抽象层，而是通过 syscall 包（unix/linux/macos）或 golang.org/x/sys/windows（windows）封装底层系统调用。你写的 go 代码最终要么走 libc（如 open、read），要么直通内核（如 windows 的 ntcreatefile）。这意味着：不是所有系统 api 都有 go 封装，有些得自己填参数、处理 errno、转换指针。
Linux/macOS 下用 syscall.Syscall 或 syscall.Syscall6 调用裸系统调用
比如想绕过 os.Open 直接调用 openat 系统调用（支持相对路径 + dirfd）：
package main
import (
"fmt"
"syscall"
"unsafe"
)
func main() {
// openat(AT_FDCWD, "test.txt", O_RDONLY, 0)
fd, _, errno := syscall.Syscall6(
syscall.SYS_OPENAT,
uintptr(syscall.AT_FDCWD),
uintptr(unsafe.Pointer(syscall.StringBytePtr("test.txt"))),
uintptr(syscall.O_RDONLY),
0, 0, 0,
)
if errno != 0 {
fmt.Printf("openat failed: %v
", errno)
return
}
fmt.Printf("fd = %d
", fd)
}
-
Syscall6是因为openat有 4 个参数，但 Go 的Syscall系列函数按寄存器数量分组（Syscall最多 3 参数，Syscall6最多 6） - 字符串必须转为
*byte，用syscall.StringBytePtr；不能传string或[]byte切片头 - 返回值中第三个是
errno（syscall.Errno类型），不是error接口；需手动检查是否非零 - 不同架构（amd64/arm64）的系统调用号不同，
syscall.SYS_OPENAT已做平台适配，别硬写数字
Windows 下必须用 golang.org/x/sys/windows，且多数 API 是 Win32 函数而非系统调用
Windows 没有类 Unix 的“系统调用号”概念，绝大多数是 user-mode DLL 导出函数（如 CreateFileW）。Go 官方不维护这些绑定，所以得靠 x/sys/windows：
package main
import (
"fmt"
"syscall"
"golang.org/x/sys/windows"
)
func main() {
const GENERIC_READ = 0x80000000
const OPEN_EXISTING = 3
handle, err := windows.CreateFile(
syscall.StringToUTF16Ptr("C:\temp\test.txt"),
GENERIC_READ,
0,
nil,
OPEN_EXISTING,
windows.FILE_ATTRIBUTE_NORMAL,
0,
)
if err != nil {
fmt.Printf("CreateFile failed: %v
", err)
return
}
defer windows.CloseHandle(handle)
fmt.Printf("handle = %v
", handle)
}
- Windows API 多数要求 UTF-16 字符串，用
syscall.StringToUTF16Ptr或windows.StringToUTF16Ptr - 错误不是
errno，而是windows.ERROR_XXX常量或windows.GetLastError() -
CreateFile返回的是 HANDLE（windows.Handle），不是文件描述符，不能传给os.File.Fd() - 别混用
syscall和windows包的类型（如syscall.Handlevswindows.Handle），它们底层都是uintptr但语义不同
更安全的做法：优先用标准库或成熟封装，而非手写系统调用
直接调系统调用容易出错，且破坏可移植性。比如：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 想获取进程内存信息？Linux 用
/proc/self/status读文件比调mincore稳定得多 - 想设文件权限？用
os.Chmod，它内部已处理fchmodat/chmod差异 - 想发信号？用
syscall.Kill或os.FindProcess(pid).Signal(...)，别自己填sys_kill参数 - 需要新 API（如 Linux 5.6+ 的
copy_file_range）？先查x/sys/unix是否已支持，再考虑 FFI
手写系统调用最常踩的坑是：参数顺序错、指针生命周期短（StringBytePtr 指向的字符串被 GC）、忘记关闭句柄/文件描述符、忽略平台差异（O_CLOEXEC 在 macOS 不可用）。真要调，务必对照对应平台的 man 2 或 MSDN 文档，一个字一个字核对参数类型和返回约定。
立即学习“go语言免费学习笔记（深入）”；
