最近又把系统编程的笔记翻出来整理，看到文件IO和标准IO这一章，发现很多老问题依然值得重新聊一遍。学Linux编程绕不开文件IO和标准IO，面试题里也总爱问"read/write和fread/fwrite有什么区别"，但真正在工程里用顺手的人并不多，更多人只是背了答案，等到自己写代码时该踩的坑一个都躲不过。这篇不打算做成API手册，而是把两者背后的机制拆开，再拿实测数据说话，看完你应该能清楚什么场景该用哪个，以及混用时有哪些必须注意的边界。
先说个直接结论方便你往下读：文件IO（也叫系统调用IO）是操作系统提供的read/write这一层，标准IO（也叫库函数IO）是C标准库在文件IO之上封出来的fread/fwrite这一层。两者不是竞争关系，而是上下层关系，标准IO内部最终还是调用read/write来完成真正的数据传输。既然有上下层，性能、行为、使用方式就注定不一样，误区也主要从这里来。
1. 从一道基础题切入：为什么read和fread的"快慢"说法总打架
1.1 一个最直观的复现实验
随便找一台Linux机器，写个小程序复制文件：一种方案是循环调用read、write，每次512字节；另一种方案是用fread、fwrite，每次512字节。跑下来你会发现结果很有意思：fread/fwrite版本明显更快。可你再换一种方案，把read/write的buffer改成64KB，结果局势又反转了，read/write版本甚至比fread/fwrite还快一点。
这就是"快慢"说法总打架的根源。问题不在"系统调用VS库函数"谁更快，而在buffer大小这个变量被忽略了。fread/fwrite快，是因为标准库内部帮你做了一层大块缓冲，把很多次小IO合并成了少数几次大IO；read/write慢，是512字节一次的用户缓冲太小，导致系统调用次数太多。一旦你把read/write的buffer调大，减少系统调用次数，它自己也能很快。
这个实验很有代表性，可以回答为什么网上对两者的性能评价两极分化。也提醒我们一件事：比较性能时，一定要先限定场景和参数。
1.2 两条技术路线的本质差别
文件IO和标准IO的差别可以浓缩成三句话：
- 文件IO是操作系统对外提供的接口，属于系统调用层，直接面对文件描述符（fd）。
- 标准IO是C标准库实现的接口，属于用户态库函数层，直接面对FILE指针（stream）。
- 标准IO内部会做缓冲管理，文件IO本身不带任何缓冲（除非你刻意用带有BUF的辅助函数或自己手动维护buffer）。
所以它们的关系不是"标准IO更高级所以替代文件IO"，而是"标准IO建立在文件IO之上，多了一层缓冲管理"。标准IO多出来的这层缓冲，既是它的强大之处，也是它所有坑的来源。
有人会问：既然标准IO封装了文件IO，那我是不是永远用标准IO就够了？显然不是。如果你是做嵌入式Linux、网络服务、数据库存储引擎这类需要精细控制IO行为的场景，直接用文件IO反而更可控。标准IO适合处理普通文本文件、配置文件读写、日志输出这些常规任务，它让代码更安全、更省心。理解完这条线，下面我们就一层层拆开看。
2. 文件描述符背后的机制：open/write/close真正影响的是什么
2.1 文件描述符不是"编号"那么简单
Linux里所有IO操作都围绕文件描述符（fd）展开。fd本质上是一个非负整数，它指向进程文件描述符表中的一个表项，而表项再指向系统级的打开文件描述（open file description），再到真正的inode和文件系统对象。
这三个层级的关系大概是：
- 进程文件描述符表：每个进程一张，记录这个进程打开的所有fd。
- 系统打开文件描述表：全局共享，记录文件偏移量、打开模式、锁信息等。
- inode对象：文件本身的元数据，包含数据块位置、修改时间等。
所以当你看到两个进程同时打开同一个文件时，它们各自持有不同的fd，但指向同一个inode。如果两边分别维护自己的文件偏移量，写数据就会互相覆盖。这也是为什么多进程追加日志时，必须用O_APPEND标志，让每次write都先定位到文件末尾再写，而不是依赖进程自己记录的偏移量。
这里有一个平时容易忽略的点：dup和dup2能复制fd，复制的fd和原fd指向同一个系统打开文件描述。这意味着它们共享同一个文件偏移量，任何一方读写移动了偏移，另一方也能感知到。掌握dup/dup2在重定向场景很重要，但如果你不清楚共享偏移量这个隐含行为，排查脏数据时会非常头疼。
2.2 write一个字节，数据经历了什么
当你在用户态调用write(fd, buf, 1)时，真正的路径是：
用户缓冲区 -> 内核页缓存（page cache） -> 块设备层 -> 磁盘。
write这个系统调用本身，只是把数据从用户缓冲区拷贝到内核页缓存，然后立即返回。它并不保证数据已经写到磁盘上。也就是说，write成功了，数据可能还在内存里。只有后面被内核的pdflush/flusher线程刷新到磁盘，或者你调用fsync、fdatasync强制下刷，数据才算真正落盘。
这个机制带来的两个实际后果：
- write的调用成本不低，因为它涉及用户态/内核态切换，还要做一次内存拷贝。但相比真正写磁盘的毫秒级耗时，这点成本已经算快了。
- 进程崩溃，write写出去的数据不一定丢；但机器突然断电，页缓存里没下刷的数据就危险了。所以数据库这类对数据持久性要求极高的程序，往往自己再加一层fsync策略，而不是依赖write返回就完事。
2.3 系统调用的"路费"：上下文切换
为什么老说系统调用贵？因为每次调用都要从用户态切换到内核态，CPU要保存用户态现场，执行内核代码，再恢复用户态现场。这个切换本身就是开销，内存屏障、寄存器保存恢复都要时间。
有人测过，一次空系统调用（比如getpid）大约耗时几十到几百纳秒，看起来不贵，但乘以百万次就是毫秒级甚至秒级的差距。IO密集型程序如果每次只读写几个字节，却触发成千上万次系统调用，那性能就崩了。这也是为什么标准IO要引入缓冲：把一万次1字节的系统调用，合并成一次一万字节的系统调用。
代码里，我们可以用strace直接观察程序到底发起了多少次系统调用，后面实测部分会展示这个工具怎么用。这也是排查性能问题时每个人手上必备的工具。
3. 标准IO的真实身份：它帮你解决了两件大事
3.1 缓冲管理：标准IO的核心价值
fopen打开文件后，标准库会为这个FILE流分配一个缓冲区，默认大小一般是4KB或8KB，具体取决于libc版本和文件系统。fread/fwrite真正干活时，会先把数据攒到缓冲区里，攒满了一并调用read/write搬运。
这个设计至少带来三个好处：
- 减少系统调用次数，性能有保障。
- 统一处理文本流、二进制流的差异，fgets/fprintf这些函数用起来方便。
- 自动处理一些跨平台的行结束符问题（尽管在Linux下这个优势不明显）。
代价则是：缓冲区里的数据和磁盘上的数据可能不一致，需要进行flush操作，或者关闭流时才会落到底层。
3.2 三种缓冲模式，别只在教科书里见过
标准IO定义了三种缓冲方式，了解它们比背定义有用得多：
- 全缓冲（fully buffered）：缓冲区满了才做实际IO。普通文件默认就是全缓冲。
- 行缓冲（line buffered）：遇到换行符就做实际IO。终端设备默认是行缓冲，这就是为什么printf("hello")不加\n，在终端上可能看不到输出。
- 无缓冲（unbuffered）：不做缓冲，每次都直接IO。stderr通常就是无缓冲，因此错误信息能立刻输出。
一个高频面试陷阱：文件重定向时，stdout的缓冲模式会不会变？会。当你把输出重定向到文件，stdout不再是终端设备，libc会把它从行缓冲切换成全缓冲。这会导致一个现象：程序里printf打印的日志，在文件里迟迟不出现，直到缓冲区被填满或者程序正常退出。排查线上问题的人，经常发现core dump文件里没有最后几行日志，就是这个问题。
setvbuf可以手动调整缓冲策略，比如setvbuf(stdout, NULL, _IONBF, 0)可以禁止stdout缓冲，调试时可以临时这么干。工程上不建议全局禁用stdout缓冲，那一堆printf全变成系统调用，性能会明显下降，只作为排查手段用。
3.3 fflush与fclose的真实区别
很多人以为fflush就是"把数据写进文件"，其实准确说法是：fflush把C库缓冲区里的数据，推送给内核（通过write系统调用）。推送给内核以后，数据还在页缓存里，离磁盘还有一步。
fclose则做了三件事：调用fflush把用户缓冲区数据送下去，关闭文件流释放FILE结构体，最后关闭底层fd。正常情况下fclose已经够用，但如果你需要确保数据真正落盘，在fclose之前或之后还需要调用fsync。数据库程序常这么做，普通日志程序很少这么干。
需要手动调用fflush的场景，我实际中遇到这些：
- 交互式程序里，打印进度条但不想每次都用换行符。
- 日志系统，程序可能长时间不退出，缓冲区迟迟不满，日志卡住。
- fork之前，要保证父进程缓冲区的数据先下刷，否则子进程会拷贝一份重复的缓冲内容。
- 需要把数据发送给另一个进程（管道/网络）时，避免数据一直停留在自己的用户缓冲里。
4. 混用文件IO和标准IO时，最容易踩坑的边界地带
4.1 fileno和fdopen：两套接口的"牵手"姿势
实际项目中，很容易出现既要直接用read/write又要用fread/fwrite的场景。C库提供了两个接口用来互通：
- int fileno(FILE *stream)：拿到FILE内部的fd，然后可以拿去给read/write用。
- FILE *fdopen(int fd, const char *mode)：把已有fd包装成FILE流，之后可以用fread/fwrite操作。
看起来很简单，但混用时的血泪教训一大把。核心规则是：同一个fd上，用户缓冲区（fileIO自己的buffer）和stdio缓冲区是两套体系，混用前必须想清楚数据到底在哪一层。
举个实际例子：你用fopen打开文件，调fwrite写了一批数据到FILE的缓冲区，然后调fileno拿到fd，直接用write再写一段。这个write会绕过标准IO缓冲区，导致双方写的数据顺序错乱——你在标准IO缓冲区里的那批数据可能还没进入内核，而write的数据已经写到文件里了。
解决办法是：在切换接口之前，先fflush(stream)，把标准IO缓冲区里的东西全部推送到内核；然后才能用fd裸写。反过来，如果你先用read裸读了数据，再想用fread接着读，同样要先统一偏移量、处理好缓冲区，不然fread拿到的数据可能不是从你期望的位置开始的。
4.2 打开标志不等于fopen的mode
有人觉得open(path, O_WRONLY|O_CREAT|O_TRUNC, 0644)等价于fopen(path, "w")，从最终结果看差不多，但O_APPEND和"a"模式之间的坑就多了。
具体说：
- fopen的"a"模式底层是O_WRONLY|O_CREAT|O_APPEND，它保证每次写入前都定位到文件末尾。
- open的O_APPEND也是如此，但有一个经典场景容易忽略：同一个文件被多个fd打开，其中一个fd没有加O_APPEND，你拿它去write，会覆盖其他fd刚写入的数据。因为该fd自己的偏移量可能是旧的，write就直接覆盖到老位置了。
所以，日志类多进程追加写入，所有进程打开文件时都必须带上O_APPEND。只靠"打开一次，往里写"的习惯思维，在多进程、多线程协同IO下是会出事的。
另一个容易踩的点：fopen("r+")对应O_RDWR，但不会创建文件；fopen("w+")对应O_RDWR|O_CREAT|O_TRUNC，会清空文件。如果你要保留原有文件内容、又要可读可写，应该用fopen("r+")而不要用"w+"。这个其实教科书写过很多遍，但实际项目中还是经常有人搞混，导致文件被清空，只能靠备份恢复。
4.3 关闭顺序和缓冲区的"后续作业"
正常进程exit，C运行时会遍历所有已打开的FILE流，把缓冲区里的数据flush掉，然后关闭。但如果你在代码里写了一个库函数，里面偷偷fopen了一个文件，调用方后面调用_Exit或者exec，缓冲里的数据就永远没机会flush了。
_Exit()、_exit()和exit()的差别就在这里：exit会做标准IO清理，_exit和_Exit是直接进内核结束进程，所有用户态缓冲区数据直接丢失。这在fork的子进程里尤其常见：子进程里不应该用exit，但如果你用了，而父进程之前的printf数据还在缓冲区没flush，子进程exit时会把这些数据再刷一遍，导致输出重复。
这类问题的排查思路：看到"输出重复"或者"最后一段日志丢了"，优先怀疑两个位置——缓冲区是否下刷、退出时用的是exit还是_exit。用strace一跟就能看到底有没有发出多余的write调用。
5. 实测对比：同样写一千万字节，四个方案谁更强
5.1 测试方案与测试环境
我拿一台普通的虚拟机做测试，系统是Ubuntu 22.04，文件系统ext4，CPU和内存都很普通。测试任务是向一个新建文件写入一千万字节（约10MB），分几个方案：
- 方案A：read/write，每次512字节buffer。
- 方案B：read/write，每次64KB。
- 方案C：fread/fwrite，每次1KB。
- 方案D：fread/fwrite，每次64KB。
每个方案跑多轮取稳定值。顺便用strace统计write系统调用次数，这样可以直观看到缓冲的影响。
需要注意，这个测试结果不代表所有环境，重点看趋势和机制，而不是纠结具体数字。
5.2 结果很扎心：小buffer哪里都吃亏
实测下来：
- 方案A花了大约95ms，write系统调用次数高达两万多次。
- 方案B花了大约3.2ms，write次数只有几百次。
- 方案C花了大约4.5ms，write系统调用次数大约两千多次（1KB缓冲下，fread/fwrite内部也不是一次fwrite对应一次write，它攒到4KB才写一次）。
- 方案D最快，大约2.8ms，write次数也最少。
方案A的惨败，输在系统调用数量上，而不在"系统调用本身慢"或"标准IO更快"。方案C能赢过方案A，靠的正是内部缓冲合并write次数；方案B、D调大buffer后，两者差距已经很小，胜负取决于具体库实现和文件系统。
这个实验的价值在于告诉你：标准IO所谓"更快"，是它替你做了合理的缓冲合并。如果你自己也能做同样的事，文件IO并不会慢。反过来，你用标准IO却一次只fread一个字节，性能照样惨不忍睹。
5.3 终极形态：手写缓冲的read/write
看到方案B已经很接近方案D了，有人会问：那我自己用read/write + 一个4KB数组，是不是就达到标准IO的效果了？
正确答案：从数据吞吐上看，确实接近；从易用性看，差距很大。标准IO除了缓冲，还提供了格式化读写、文本流处理、错误处理机制。你手写read/write，所有格式化工作（数字转字符串、按行读取、字段切割）都得自己来，代码量会大得多。所以不要为了"极致性能"把所有代码都改成裸read/write，除非你确实需要精确控制每一次系统调用的时机、大小和顺序。
嵌入式开发里，有些场景确实必须用裸IO，比如直接和寄存器设备交互、操作特定块设备、实现自定义文件系统。这种时候，手写缓冲反而比标准IO更合适。
6. read/write的返回值：短读写和EINTR是排查问题的关键线索
6.1 为什么read请求1KB可能只返回233字节
read和write的返回值含义是"实际传输的字节数"，它不保证等于你请求的长度。如果你指定读1000字节，返回200字节，这就是"短读"（short read）。在普通磁盘文件上比较少见，但在管道、socket、终端设备上非常常见，因为数据是按数据包到达的。
write同理。写大块数据时，内核可能只接受了部分字节，剩下的需要你自行继续写。回头看网络编程的代码，如果只写一次就认为全部发送成功，在高负载、大流量下一定会出现数据丢失。正确的写法是循环调用read/write，直到目标字节数全部完成。
经典实现如下：
ssize_t writen(int fd, const void *buf, size_t n) { size_t total = 0; const char *p = (const char *)buf; while (total < n) { ssize_t nwritten = write(fd, p + total, n - total); if (nwritten <= 0) { if (nwritten < 0 && errno == EINTR) { continue; } return -1; } total += nwritten; } return total; }read的循环同理，还要额外处理EOF，即read返回0的情况。
很多人一开始觉得这种循环是多余，但等你真在socket上跑高并发传输，就会发现短写是常态，而不是异常。
6.2 EINTR：被信号打断的系统调用
read/write在等待数据时，如果进程收到信号并且信号处理函数返回，系统调用可能返回-1，errno被设为EINTR。老派Unix代码里，必须判断EINTR并重新调用read/write，否则数据没读取成功就提前跑了。
现代Linux内核通常会自动重启慢速系统调用，取决于信号处理时的SA_RESTART标志和具体系统调用，但为了代码健壮，网络编程里依然建议对EINTR做处理。
我自己踩过的一个真实案例：一个网络转发服务，偶尔出现丢包，排查了很久，最后定位到socket read返回-1且errno为EINTR，代码里没判断，直接当连接关闭处理，把一条正常连接close掉了。修了两个字符，问题消失。
6.3 排查思路的延伸：先用strace定位"真凶"
遇到IO相关的问题，我的排查顺序一般是：
- 先用strace -f -e trace=read,write,open,close -p 挂到进程，看系统调用返回值。
- 观察是否有大量短读写、EINTR、EBADF、EAGAIN。
- 结合代码入口，判断是缓冲策略问题，还是offset问题，还是fd生命周期管理问题。
- 最后才考虑改代码。
这个套路不止用于排查问题，也用于确认"标准IO到底替我们做了什么"。很多以前看文档想不通的行为，strace跑一遍就全明白了。比如你以为printf带\n会立刻写文件，strace告诉你：缓冲区未满时，即使有\n，输出重定向到文件也未必立即write。
7. 一个实际的场景取舍建议：写日志到底用哪个
日志是Linux开发里最频繁用到的IO场景之一。很多团队刚起步时都用printf，后面要落盘就改成fprintf，但日志文件总是丢最后几行，或者多进程写日志互相覆盖。我的建议是：
- 单进程、低并发日志：直接用标准IO，fprintf/fputs都很舒服，注意定期fflush或fclose。
- 多进程日志：open时必须加O_APPEND，并且写入时每条日志保证一次write尽量写完（日志消息控制在PIPE_BUF或4KB内，能有效提升原子性概率）。避免多进程各持一个FILE流乱写，否则offset管理很难做。
- 高可靠场景（比如要求日志不能丢）：write后用fsync强制落盘。代价是性能下降，必须接受。
- 嵌入式环境内存有限：尽量少用标准IO的默认缓冲，必要时setvbuf调小缓冲或禁用缓冲，避免内存暴涨。
这些都是老生常谈，但实际出问题的时候，"为什么会丢日志"几乎都能归到缓冲、偏移量、退出方式这三类原因上。顺着这三条排查，通常不用太久就能定位。
最后再分享一个我自己的习惯：写任何涉及IO的C程序，第一步就先把read/write包装成带循环的safe_read/safe_write，顺带把EINTR也处理掉。多花五分钟，后面省下的排查时间可能是几小时。这个习惯我从初学Linux编程那会儿一直坚持到现在，基本没让我失望过。
