木-Star系统调用这个话题，说大不大说小不小。大到内核源码里的 sys_call_table，小到你随手敲的 open、read、fork，它都是系统调用。你在实际开发中遇到的各种诡异问题——文件打不开、进程僵死、网络卡住、命令行工具突然"无法识别"——追到最底层，大多都能在某次系统调用上找到答案。这篇东西不打算讲那种教科书式的系统调用清单，而是把我这些年用过的、踩过的、排查过的系统调用相关函数和问题，按真实使用频率和踩坑概率做个梳理，希望对正在学系统编程或者已经在生产环境里被系统调用坑过的人有点实际帮助。
1. 先搞清楚：系统调用到底是什么
1.1 从用户态到内核态的必经之路
系统调用是用户程序请求操作系统内核服务的唯一正式通道。应用程序跑在用户态，不能直接访问硬件、修改内存页表、操作网卡，这些特权操作只有内核能做。当你的程序调用 read() 想从磁盘读数据，实际流程大致是：read() 把参数放到寄存器，触发一条特殊的陷入指令（x86-64 上是 syscall，ARM64 上是 svc），CPU 切换到内核态，内核根据系统调用号找到对应的 handler，执行完再把结果返回用户态。整个过程虽然只有几微秒，但涉及特权级切换、栈切换、寄存器保存恢复，不能随便写。
很多初学者容易把系统调用和普通函数调用搞混。普通函数调用就是在同一个进程地址空间里跳转指令，callee 和 caller 共用一套用户态栈和寄存器，开销极小；系统调用则要切换 CPU 特权级、切换内核栈、保存用户态上下文，还要经过系统调用表的索引分发。所以哪怕是最简单的 getpid()，也比一个纯用户态函数慢一个数量级。这也是为什么像 VDSO 这种优化手段会存在——把一部分不需要特权级的系统调用（比如 gettimeofday、clock_gettime）直接映射到用户态执行，省掉陷入内核的开销。
1.2 系统调用与库函数、API 的边界
很多人分不清 open() 和 fopen() 到底有什么区别。open() 是系统调用，直接跟内核打交道，返回的是文件描述符；fopen() 是 C 标准库函数，内部照样会调用 open()，但它多了用户态的缓冲区管理，所以对小块读写性能有显著提升。再比如 malloc() 并不是系统调用，但当你申请大块内存时，glibc 会调用 brk() 或 mmap() 从内核拿内存。所以库函数是建立在系统调用之上的"加了一层缓存和便利"，系统调用才是真正干活的人。理解这一层，你就能明白为什么有些场景必须绕过库函数直接使用系统调用。
举一个实际例子：你要写程序把一批小记录写入日志文件。用 fprintf() 每次写一个几百字节的记录，因为 stdio 有用户态缓冲区，未必每次都触发系统调用；但如果你改成每次 write() 一个几百字节，那就必然是 N 条记录 N 次系统调用。在你追求极致写盘性能的场景里，这个差别就可能决定一个服务能不能扛住高并发。反过来说，如果你对每条数据都调用 fsync()，那不管用多少缓冲区都白搭，因为 fsync 本身就是强制落盘的系统调用。区分这两层，能帮你判断性能瓶颈到底在哪里。
1.3 系统调用的执行流程拆解
我把一个系统调用的完整链路拆细一点。假设你写了一个最简单的 C 程序，调用 read(fd, buf, 128)：
- 参数检查：read() 由 libc 封装，它把 fd、buf、count 放入寄存器，然后执行 syscall 指令，同时把系统调用号（Linux 上 read 是 0）放入 rax。
- 内核入口：CPU 切换到内核态，跳到 entry_SYSCALL_64 入口，保存用户态寄存器，从 rax 拿到系统调用号，查 sys_call_table 找到 do_syscall_64 的处理函数。
- 权限与参数校验：内核会检查 fd 是否合法、buf 指针是否真的指向用户可写内存，比如会调用 access_ok() 做地址范围检查，防止你传一个内核地址进来。
- 真正的 IO 操作：通过 current->files->fdt 找到 file 结构体，调用 file_operations 里的 read 方法，在磁盘上发起 IO。
- 返回与恢复：把读取到的字节数写入 rax，恢复用户态寄存器，执行 sysret 回到用户态。
这里最容易被忽略的是第 3 步——内核并没有你想的那么信任你。它做的第一件事往往是校验参数，这也是为什么系统调用慢的一部分原因。也是为什么在写系统调用封装的时候，你最好自己先做一遍参数检查，比如 fd