做Linux开发这些年，文件操作大概是写过的代码里出现频率最高的场景了。不管你是写C、C++还是Python，底层跑的都是那几个系统调用——open、read、write、close、lseek。很多人能熟练地用fopen、fread做读写，但一旦碰上文件描述符泄露、部分读写、信号中断这类问题，就开始抓瞎。这就是因为对系统调用层的理解还停留在"API会返回一个值"的程度。
这篇文章我会把Linux文件操作最核心的几条系统调用掰开揉碎讲透——不只是讲函数原型和参数，重点讲清楚内核在背后做了什么、为什么这么设计、以及实操时最容易踩的坑。我尽量用我这几年实际调试的经验来讲，内容既适合刚接触Linux编程的新手建立完整认知框架，也适合有经验的老手查漏补缺。文中的所有示例代码都是可编译运行的最小实现，可以直接拿去实验。
1. 一切从open开始：文件描述符是怎么回事
1.1 为什么Linux里"一切皆文件"
Linux从一开始的设计哲学里就有一个核心抽象——一切皆文件。普通文件是文件，设备是文件，管道是文件，socket是文件，甚至/proc下面那些虚拟的进程信息也是文件。这个设计的好处在于，程序员只需要学会一套操作接口，就能处理几乎所有I/O场景。
而支撑起这套统一抽象的，就是文件描述符，简称fd（file descriptor）。你可以把它理解成一张"票据"或者说"索引号"。每次你调用open打开一个文件时，内核就会在当前进程的文件描述符表里分配一个空闲的整数号，这个整数就是fd。之后所有针对该文件的操作——读、写、移动位置、收尾关闭——都是基于这个整数进行的。
这里有个非常关键的概念需要澄清：fd是属于进程的，而不是属于文件的。同一个文件被同一个进程open两次，会得到两个不同的fd，它们在文件描述符表里对应两个完全独立的"打开文件记录"，各自的读写位置（offset）互不影响。
实操心得：新手写程序时经常忘了"同一个文件，两次打开，是两个独立的读写位置"这一点。如果你想让两个fd共享同一个offset，要用dup或dup2做描述符复制，而不是重新open一次。
1.2 open系统调用的完整参数拆解
open的原型是：
#include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode);第一个参数pathname是路径，这个没什么好说的。关键在第二个参数flags——它由三部分构成：访问模式、创建选项、辅助选项。
访问模式必须是O_RDONLY（只读）、O_WRONLY（只写）、O_RDWR（读写）三选一。这是"主模式"，内核必须根据它来检查进程是否有相应权限。
创建选项常用的包括：
O_CREAT：如果文件不存在就创建它，需要搭配第三个参数mode指定权限。O_EXCL：如果同时指定了O_CREAT，而文件已经存在，open直接失败。这个选项常用于防止覆盖已有文件，比如创建锁文件时。O_TRUNC：如果文件已存在，且以写模式打开，会立刻把文件长度截断为0。注意，O_TRUNC和O_RDONLY搭配时会直接报错，因为只读模式不允许改变文件大小。
辅助选项里最经典的是O_APPEND和O_NONBLOCK。O_APPEND会让每次write前都先把offset移动到文件末尾，两个或多个进程同时以追加模式写同一个文件时，数据不会互相覆盖。O_NONBLOCK用于打开FIFO、设备等特殊文件时，让open本身不被阻塞。
第三个参数mode只有在指定O_CREAT时才有效。这里要注意，mode不是直接作为文件的最终权限，它还要与进程的umask做一次取反后再按位与的操作。比如你传0644（rw-r--r--），但umask是022时，最终文件权限是0644 & ~022 = 0644；如果umask是077，最终就变成0600了。
int fd = open("/tmp/example.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); return -1; }我在实际项目中见过一个典型的bug：调用open时忘了传第三个参数，结果创建出来的文件权限是随机的，有时是0600，有时是0000，搞得其他用户读不了，排查了很久才发现是umask和垃圾栈数据导致的。
2. read与write：数据搬运工的自我修养
2.1 read的返回值是灵魂
read系统调用的原型是：
#include <unistd.h> ssize_t read(int fd, void *buf, size_t count);这里第一个坑就是类型。ssize_t是有符号的，size_t是无符号的，为什么返回值要用有符号类型？因为read要返回三种情况：成功读到的字节数、0表示到达文件末尾、 -1表示出错。
我在评审代码时经常看到有人这么写：
char buf[4096]; while (1) { int n = read(fd, buf, sizeof(buf)); // 这里没有判断n < 0的情况 if (n == 0) break; write(1, buf, n); }如果read返回-1，n是负数，被隐式转成int，如果不判断就直接传给write，就往标准输出写了巨大的一坨东西——因为-1当成size_t参数传递时会变成一个天文数字。更致命的是这种bug不一定每次都会触发，只有在信号中断或磁盘出错的时候才会暴露。
正确写法是：
ssize_t n; while ((n = read(fd, buf, sizeof(buf))) > 0) { if (write(STDOUT_FILENO, buf, n) != n) { perror("write"); exit(1); } } if (n < 0) { perror("read"); exit(1); }2.2 write的"部分写"问题远比想象中常见
write的原型是：
ssize_t write(int fd, const void *buf, size_t count);很多人想当然地认为write一次写了多少就返回多少，写少的情况只有磁盘满了。这个想法在普通文件上基本成立，但在socket、管道、终端等场景下完全不成立。
write只保证"成功地把count个字节从用户空间拷贝到了内核缓冲区"，但它不能保证内核缓冲区一次性全部接收。对于管道和socket，当缓冲区空间不足时，write只会写入一部分字节就返回，返回值小于count。而对于普通文件，通常情况下一旦写入内核页缓存就不会返回"部分写"，但如果你用O_NONBLOCK或者碰上了某些文件系统，同样可能部分写。
这也是为什么所有成熟的网络服务库都要自己做"写缓冲"和"循环写"逻辑——因为一次write根本不够无线程序用。
我给自己的文件拷贝工具封装过一个safe_write函数：
ssize_t safe_write(int fd, const void *buf, size_t count) { size_t written = 0; while (written < count) { ssize_t n = write(fd, (const char *)buf + written, count - written); if (n < 0) { if (errno == EINTR) continue; // 信号中断，重试 return -1; } if (n == 0) { errno = EIO; return -1; } written += n; } return (ssize_t)written; }这个函数里有两个关键点：一是循环写直到写完，二是处理EINTR。EINTR问题是后面第4节要展开讲的实战热点话题。
3. lseek、close与文件描述符的底层语义
3.1 lseek的移动方式和细节
lseek的原型：
#include <unistd.h> off_t lseek(int fd, off_t offset, int whence);whence有三个取值：
SEEK_SET：从文件头开始，offset是绝对值。SEEK_CUR：从当前读写位置开始，offset是相对值。SEEK_END：从文件末尾开始，offset是相对值。
lseek本身是同步的、瞬时完成的，它只是修改了文件描述符对应的那个"当前读写位置"变量，并没有发生真正的磁盘I/O。所以lseek的返回值是移动后的最终位置。
有一个很多人不知道但很实用的技巧：用lseek(fd, 0, SEEK_CUR)来获取当前文件的读写位置，不需要多余变量维护。另一个技巧是用lseek(fd, 0, SEEK_END)快速拿到文件大小。
但注意一个坑：lseek只能用于普通文件，如果用在管道、socket、终端等不可定位（unseekable）的文件上，会返回-1并置errno为ESPIPE。所以在写通用工具时不能假设所有fd都能lseek。
3.2 close为什么可能失败
close的原型很简单：
int close(int fd);关闭文件时，内核会做以下事情：从进程的文件描述符表中移除该fd、释放对应的打开文件记录、检查该文件是否还有其他的打开引用（包括其它进程的fd或dup出来的fd），如果引用计数降到0，则真正释放inode，刷新所有脏数据页。
很多人忽略的一点是：close在极端情况下也可能失败。比如NFS文件系统上，数据延迟刷新到服务器时出错，close会返回-1，errno是EIO（另外一个可能的是EBADF，表示fd本身不合法）。你以为关闭成功了，实际数据根本就没落到磁盘上。
所以严谨的程序在完成写操作后，应当：
if (fsync(fd) < 0) { // 处理同步失败 } if (close(fd) < 0) { // 处理关闭失败 }当然，项目中是否需要每次都fsync，得看对数据安全性的要求和性能预算。fsync一次往往要等磁盘真正落盘，SSD上面大概零点几毫秒到几毫秒，机械盘上能到几十毫秒，频繁调用对性能影响非常大。
4. 系统调用和库函数：为什么fwrite比write"高级"
4.1 用户空间缓冲区是怎么回事
很多人会有疑问：既然底层是open/read/write，那fopen/fread/fwrite是干什么的？是不是多余的？
这就是标准C库stdio层的意义。stdio在这几个系统调用之上，又加了一层用户空间的缓冲区。默认情况下，fopen打开的文件是带缓冲的（默认大小通常是4096或8192字节）。你fread几字节时，它一次性从内核读一大块到用户空间buf里，下次fread就直接从buf里取，不用频繁陷入内核。
read/write是"无缓冲"的系统调用，每次调用都要触发一次用户态到内核态的切换，如果读1个字节就调一次read，性能惨不忍睹。
举个例子，我之前做过一个性能对比实验：
- 用read/write循环每次读写1字节，复制一个100MB的文件，耗时约几秒到十几秒。
- 用fread/fwrite循环每次读写1字节，耗时只有前者的几十分之一。
- 用read/write配合4KB缓冲区，耗时和fread/fwrite差不多。
原因就在于系统调用上下文切换的开销被摊薄了。一次read(1字节)和一次read(4096字节)，系统调用的固定开销几乎一样，都是那几十个纳秒的陷阱（syscall）成本，所以你一次读得越多，摊到每个字节上的开销就越小。
4.2 用strace观察真实系统调用
如果你想亲眼看看程序到底调用了哪些系统调用，strace是最好的工具。一行命令：
strace -e trace=openat,read,write,close ./my_program输出里会清清楚楚地列出每次系统调用、参数和返回值。带-f参数还能跟踪fork出来的子进程。我用这个方法定位过不少诡异问题——比如程序写入的文件大小跟预期不符，strace一下就看出来read只被调用了部分次数，或者write被分裂成了多次小写。
实操建议：碰到"文件内容不完整""程序行为奇怪"这类问题，先别急着查逻辑，跑一遍strace看系统调用序列，大多数情况下问题一秒现形。
怎样判断一个fd是否带缓冲，这是很多人的知识盲区。其实就看你是用read/write还是fread/fwrite在操作它。read/write是直接穿透用户空间缓冲，直达内核页缓存；fread/fwrite则套了一层用户态缓冲。同一个fd你混着用这两种接口，会出大问题——数据可能在stdio的缓冲区里还没被flush就被write到了fd，导致乱序。项目里最好的实践是：要么只用一层接口，要么在切换接口前显式调用fflush同步缓冲区。
5. 实操：写一个靠谱的cp工具，并让它足够快
5.1 基础版本的文件拷贝
很多公司的笔试题就是让你用C语言实现一个cp命令。最简单的版本长这样：
#include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { if (argc != 3) { fprintf(stderr, "Usage: %s src dst\n", argv[0]); exit(1); } int src = open(argv[1], O_RDONLY); if (src < 0) { perror("open src"); exit(1); } int dst = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0644); if (dst < 0) { perror("open dst"); exit(1); } char buf[8192]; ssize_t n; while ((n = read(src, buf, sizeof(buf))) > 0) { ssize_t written = 0; while (written < n) { ssize_t w = write(dst, buf + written, n - written); if (w < 0) { perror("write"); exit(1); } written += w; } } if (n < 0) { perror("read"); exit(1); } close(src); close(dst); return 0; }这个版本功能上是对的，但有几个专业问题：
- 没处理close失败。
- 没调用fsync，数据可能还在页缓存里，突然断电文件内容不完整。
- 缓冲区大小8KB在绝大多数场景下够用，但如果你想追求极致性能，缓冲区大小至少要到256KB甚至1MB，这样能大幅减少系统调用次数。
5.2 一个更专业的实现：考虑权限、时间戳和错误处理
专业级的cp还要考虑复制权限和文件时间戳。复制权限需要用到fstat系列调用，复制时间戳则要用到utimensat。让我写一个更快一点点的版本，把几个关键点塞进去：
#include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <sys/stat.h> #include <sys/types.h> int copy_file(const char *src_path, const char *dst_path) { int src = open(src_path, O_RDONLY); if (src < 0) { perror("open src"); return -1; } struct stat st; if (fstat(src, &st) < 0) { perror("fstat"); close(src); return -1; } int dst = open(dst_path, O_WRONLY | O_CREAT | O_TRUNC, st.st_mode & 0777); if (dst < 0) { perror("open dst"); close(src); return -1; } // 用大缓冲区减少系统调用次数 size_t bufsize = 1024 * 128; char *buf = malloc(bufsize); if (!buf) { close(src); close(dst); return -1; } ssize_t n, written; while ((n = read(src, buf, bufsize)) > 0) { size_t off = 0; while (off < (size_t)n) { written = write(dst, buf + off, n - off); if (written < 0) { perror("write"); free(buf); close(src); close(dst); return -1; } off += written; } } free(buf); close(src); if (fsync(dst) < 0) { perror("fsync"); close(dst); return -1; } if (close(dst) < 0) { perror("close dst"); return -1; } return 0; } int main(int argc, char *argv[]) { if (argc != 3) { fprintf(stderr, "Usage: %s src dst\n", argv[0]); return 1; } return copy_file(argv[1], argv[2]) == 0 ? 0 : 1; }这个版本我没有复制文件的所有扩展属性，只覆盖了权限和内容。完整实现cp命令还应该考虑硬链接、符号链接、ACL、时间戳等，这里点到为止，重点在于把系统调用用对了。
5.3 性能变数与内核页缓存的关系
有意思的是，文件拷贝性能不只取决于缓冲区大小，还跟内核页缓存的状态强相关。
第一次拷贝一个大文件时，数据从磁盘读入内核页缓存（page cache），再从页缓存拷贝到用户空间buf，最后又从用户空间写到内核页缓存，关联到目标文件的脏页。整个过程其实是在"磁盘 -> 页缓存 -> 用户空间 -> 页缓存 -> 磁盘"之间转了两道。如果目录项、inode、块映射信息都已被缓存了，第二次拷贝同样的文件（源和目标都在缓存里）会快很多。
这也是为什么性能测试必须做"冷缓存"和"热缓存"两轮对比：第一次跑是真实磁盘IO，第二次跑可能已经完全被页缓存覆盖了，数据根本不落盘。
经验之谈：在Linux上做性能基准时，echo 3 > /proc/sys/vm/drop_caches 可以清掉页缓存（需要root权限），确保每次跑的是相对真实的磁盘性能。
6. 实战排查：文件操作中遇到的几个问题
6.1 EINTR信号中断问题
这是多线程/信号处理程序里最经典的坑。假设你的程序注册了定时器信号SIGALRM，或者用signalfd接信号，那么当信号到达时，如果程序正阻塞在一个慢速系统调用上（比如read一个慢设备、还被阻塞在等数据），系统调用会被信号打断，内核直接返回到用户空间，此时read返回-1，errno被置为EINTR。
最恶心的在于它不是一个确定的错误——文件操作每次都成功，偶尔一次失败，然后程序直接退出。这就是典型的EINTR没处理好。
处理方法很简单，把read/write包一层循环，碰到EINTR就重试：
ssize_t n; do { n = read(fd, buf, sizeof(buf)); } while (n < 0 && errno == EINTR);我见过生产环境下一个日志服务莫名其妙地丢数据，排查到最后就是某个write被信号中断后，日志模块直接break了循环，一条日志就这么消失了。
6.2 文件读取不完整，诡异又常见
还有一次，一个同事写的程序把一个大文件读入内存，他用fseek拿文件大小，malloc一块内存，然后用一次fread把它全读进来。
在小文件上没问题，但文件超过几十MB后，他写的fread只调用了一次，而且没有检查返回值是不是等于期望的字节数。而fread在普通文件上通常可以一次读完，但在某些文件系统上或者当内存压力大时，会分多次返回。
后来我给他推荐了两种写法。第一种，循环读取直到EOF：
size_t total = 0; ssize_t n; while ((n = read(fd, buf + total, size - total)) > 0) { total += n; }第二种更优雅的做法是用mmap，直接把文件映射到进程地址空间，省去反复read和搬移数据的开销。这个后面第7节细讲。
总的来说，通用教训是：永远不要假设一次read/fread能读完，肉眼看着合理的代码在极端条件下不一定正确。
6.3 磁盘空间满时的write行为
磁盘满了，write会失败，返回-1，errno为ENOSPC。这个大家都会判断，但有个隐蔽点：部分写也可以发生在磁盘满的场景。
想象你write了8192字节，内核先接受了4096字节，然后发现磁盘块不够了，此时write返回的是4096，还是-1？
POSIX语义是这样的：对于普通文件，write通常是在页缓存层面完成的，数据先进入缓存，落盘发生在后台。只要页缓存能放得下，write就返回成功，即使磁盘实际满了，也只是后台刷盘时出错。但如果文件系统在写入路径上就检测到空间不足（比如分配不了新块，这常见于一些日志式文件系统），就会导致部分写。
那你怎么知道该不该重试？重试可能无限循环，因为空间一直没释放。做法是：write返回-1且errno==ENOSPC时，停止写入，清理临时文件，或者提示用户释放空间。
项目里处理这个问题的标准逻辑是：
if (w < 0) { if (errno == ENOSPC) { fprintf(stderr, "no space left on device\n"); return -1; } }6.4 文件描述符泄露：烫手的山芋
写长期运行的服务时，fd泄露比内存泄露还致命。内存泄露可能只是进程占用内存变大，fd耗尽后open直接返回EMFILE，之后连日志都写不了。
我之前排查过一个后台服务，运行一周后所有新连接都建立失败，strace看到错误是Too many open files。看了进程的/proc/pid/fd目录，发现大量指向同一个日志文件的描述符——代码里每次写日志都open一次，但close被放在了某条错误分支之后，结果异常退出时没关掉。
排查技巧很简单：ls /proc/pid/fd | wc -l对比正常值；lsof -p pid或者直接看 /proc/pid/fd 目录，按文件的inode归类，就能快速看出哪些fd重复打开了。
7. 进阶内容：mmap、O_DIRECT和原子操作，把小细节打通
7.1 mmap：把文件变成内存
mmap是文件操作的高阶话题，它能把文件的一部分直接映射到进程的虚拟地址空间。映射完成后，读写文件就像读写内存数组一样，不需要read/write系统调用，也不需要自己管理用户空间缓冲区。
#include <sys/mman.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> int main() { int fd = open("/tmp/data.bin", O_RDONLY); if (fd < 0) { perror("open"); return 1; } struct stat st; fstat(fd, &st); char *addr = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if (addr == MAP_FAILED) { perror("mmap"); close(fd); return 1; } // 直接像访问数组一样访问文件内容 printf("first byte: %d\n", addr[0]); // 要修改文件内容就用 PROT_WRITE | MAP_SHARED munmap(addr, st.st_size); close(fd); return 0; }mmap读取的性能优势在读大文件时很明显，因为省掉了用户空间缓冲的拷贝（零拷贝的思想算是它的简化版），而且内核按需调页，文件内容不需要一次性全部调入内存。读一个2GB的文件，mmap后访问其中一小段，内存开销很小。
需要注意，mmap映射的长度不能超过文件实际大小，否则访问越界部分会触发SIGBUS。另外，文件被截断（truncate）而映射还在时，访问截断后的区域同样会SIGBUS。
7.2 O_DIRECT：绕过页缓存
O_DIRECT是open时的一个标志，它的含义是：读写操作直接访问用户空间的缓冲区，绕过内核页缓存。注意这不是"更高级"，这个模式通常只有数据库这类需要自己管理缓存的应用才用。普通程序用O_DIRECT反而可能导致性能更差，因为少了页缓存这层缓冲区。
使用O_DIRECT时，缓冲区地址和长度有对齐要求——通常要求对齐到文件系统逻辑块大小（一般512字节或4KB）。不满足对齐条件，read/write会返回EINVAL错误。
int fd = open("/tmp/data.bin", O_RDONLY | O_DIRECT);如果你自己写演示程序，建议先用posix_memalign分配内存，且长度是512的整数倍，这样最常见。
心得：在云服务器上，我发现O_DIRECT在文件系统被缓存污染严重时（比如大量随机写导致缓存命中率下降）反而能带来性能提升。但大多数场景里，让内核管页缓存是更优的选择。
7.3 文件操作中的原子性
O_APPEND已经保证了多进程追加写时每次write的原子性（指偏移量定位和写入是一个原子操作，不会出现两个进程写重叠）。但这并不保证你的写不会交错——如果你一次只写一行字符串，而多个进程同时写同一个日志文件，行与行之间可能出现错乱，因为每个write本身是原子的，但两次write之间不一定连续。
还有个经典技巧是创建临时文件后rename。写文件时先写一个临时文件，写完并fsync，然后rename到目标路径。rename是原子的——任何时刻，目标路径要么指向旧文件，要么指向新文件，不会出现中间状态。这是处理"配置文件更新时崩溃"问题的最佳实践。
8. 面试题视角：这些系统调用，你会被问到什么
Linux岗位面试里文件操作是必考模块，下面几个问题我总结了一下，面试官问的角度在实战中很有价值：
open返回的fd一定是最小的可用fd吗？ 答案是：是的。Linux内核分配fd时，总是从当前进程的fd表中选取最小的空闲数字。这个细节可以用在"关闭标准输出重定向再打开文件"的场景里。
两个进程同时open同一个文件，它们的offset是独立的还是共享的？ 独立。每个进程的fd是独立的，内核中的"打开文件记录"也是独立的，所以offset自然独立。如果两个进程都想追加写，需要用O_APPEND来保证定位和写入的原子性。
read一个socket返回0，是读到EOF了吗？ 不一定。对socket来说，返回0通常表示对端关闭了连接（FIN），但这不等于底层数据已经全部读完——准确说是不会再读到新数据了。
write到pipe，buffer满时会发生什么？ 阻塞模式下，write会一直阻塞直到有读者消费掉数据，或写入全部成功；非阻塞模式下立即返回-1，errno为EAGAIN或EWOULDBLOCK。这个场景在并发编程中很常见。
符号链接和硬链接在open时表现一样吗？ 不一样。open符号链接时，内核会透明地跟随它找到目标文件再打开；而用openO_NOFOLLOW可以直接控制是否跟随。硬链接本质是同一个inode的另一个目录项，open结果完全一样。
再分享一个小技巧：写代码之前用man 2 open、man 2 read这样的命令看看官方文档，比任何博客都靠谱。Linux的man手册把这些系统调用的语义、错误码、边界条件写得很详细，很多疑难问题都能从里面找到答案。
我在实际工作里还有一个习惯，就是在写涉及文件I/O的代码时，先在草稿纸上把"成功路径"和"失败路径"的fd生命周期画出来，确保每个分支都正确关闭fd。这个习惯帮我避免过很多次fd泄露问题，也让我给代码加错误处理时不再觉得麻烦。
文件操作看似基础，但因为太基础，反而容易被轻视。希望这篇文章能帮你把系统调用这块补齐——只有理解了内核在背后干什么，你写出来的代码才能在程序里真正站稳脚跟。
