企业官网建设流程全解析

1. 从一次文件读写翻车说起：为什么标准IO值得单独拎出来讲

前阵子帮一个做嵌入式采集的朋友排查问题，他的程序在开发机上跑得好好的，换到目标板上就出现数据写一半丢一半的情况。代码里用的是最朴素的read和write系统调用，逻辑看着没问题，但就是偶发丢数据。折腾了大半天，最后发现问题出在他自己封装的一个缓冲区上——缓冲区大小设成了 4096，但没考虑到底层块设备的实际扇区对齐，加上没有正确处理短写（short write）的返回值，导致边界情况下数据被截断。

这件事让我意识到，很多做 Linux 开发的人，包括我自己早期，对标准 IO 的理解都停留在“不就是 fopen、fread、fwrite 那几个函数嘛”的层面。但真正到了生产环境，尤其是涉及大文件处理、高并发日志写入、跨平台数据交换这些场景，标准 IO 的那套缓冲机制、错误处理、格式化规则，每一个细节都可能变成线上事故的导火索。

这篇内容我想把 Linux 标准 IO 这套东西从头到尾捋一遍。不是照本宣科地列函数原型，而是按照一个实际开发者会踩到的顺序，把“为什么这么设计”“什么时候该用哪一层”“哪些坑必须提前避开”讲清楚。适合已经写过 C 程序、用过文件读写，但对底层机制还比较模糊的开发者；也适合那些正在从脚本语言转向系统级编程、想搞明白“为什么 Python 的 open 和 C 的 fopen 行为不一样”的朋友。读完你至少能搞清楚三件事：标准 IO 和系统调用 IO 的本质区别在哪、缓冲机制到底怎么影响你的程序行为、以及在实际项目里怎么选、怎么用、怎么排查问题。

2. 标准IO到底“标准”在哪：分层设计与核心定位

2.1 标准IO与系统调用IO的本质区别

要理解标准 IO，得先把它和它下面那层系统调用 IO 摆在一起看。Linux 里所有对文件的操作，最终都要落到内核提供的系统调用上，也就是open、read、write、lseek、close这一套。这些函数直接和内核打交道，每次调用都会触发用户态到内核态的切换，开销不小。

标准 IO 是构建在系统调用之上的一层用户态缓冲库，它是 C 标准库（glibc 在 Linux 上的实现）的一部分。核心函数就是fopen、fread、fwrite、fclose、fseek、fprintf、fscanf这些。它最核心的价值有两个：一是缓冲，二是可移植性。

缓冲的意义在于减少系统调用的次数。假设你要往文件里写 10000 个字节，如果直接用write，每写一次就是一次内核切换；而用fwrite，标准 IO 会先把数据攒在用户态的缓冲区里，等缓冲区满了或者你主动 flush 的时候，才真正调用一次write把整块数据送下去。这个差别在小数据量下不明显，但在高频写入场景下，性能差距可能是数量级的。

可移植性这块，标准 IO 是 C 标准定义的，同一套代码在 Linux、其他类 Unix 系统、甚至一些嵌入式 RTOS 上都能编译运行，只要那个平台提供了符合标准的 C 库。而系统调用 IO 是跟操作系统强绑定的，Linux 的open和别的系统的open在参数和返回值上可能就有差异。

2.2 缓冲机制：全缓冲、行缓冲与无缓冲

标准 IO 的缓冲策略分三种，这个必须搞清楚，因为它直接决定了你的数据什么时候真正落到文件里。

全缓冲（Fully Buffered）：缓冲区满了才执行实际的 IO 操作。默认情况下，普通文件（磁盘上的文件）用的就是全缓冲。缓冲区大小通常是 4096 字节或 8192 字节，具体取决于系统和文件系统。这意味着你fwrite了 100 个字节，数据可能还在内存里待着，文件里暂时看不到。

行缓冲（Line Buffered）：遇到换行符\n就刷新缓冲区。终端设备（比如你程序的标准输出连到终端时）默认是行缓冲。这就是为什么你用printf打印一行带换行的内容，能立刻在屏幕上看到；但如果不带换行，可能就得等程序结束或者缓冲区满了才显示。

无缓冲（Unbuffered）：数据直接写出去，不经过用户态缓冲。标准错误stderr默认就是无缓冲的，保证错误信息能第一时间输出，哪怕程序马上要崩溃。

这里有个特别容易踩的坑：很多人调试的时候用printf打日志，程序崩溃了发现最后几行日志没出来，就以为是逻辑没走到那里。实际上很可能逻辑走到了，数据在缓冲区里没来得及刷新，程序就挂了。解决办法要么用stderr，要么在关键位置手动fflush(stdout)。

2.3 FILE结构体：不透明指针背后的东西

标准 IO 里所有操作都围绕一个FILE *指针转。这个FILE结构体对使用者是不透明的，你不需要知道它里面有什么，但了解它的存在对理解行为有帮助。

在 glibc 的实现里，FILE结构体包含的东西大致有：文件描述符（就是系统调用那层的 fd）、指向缓冲区的指针、缓冲区大小、当前读写位置、错误标志、EOF 标志、以及一把用于线程安全的锁。这也是为什么标准 IO 在默认情况下是线程安全的——每个FILE对象内部有锁机制，多个线程同时操作同一个FILE时不会把缓冲区搞乱。但注意，线程安全不等于原子性，两个线程同时往同一个文件写，写入的顺序仍然是不确定的。

FILE结构体里还维护了一个“当前缓冲模式”和“当前读写位置”的概念。标准 IO 区分“读位置”和“写位置”，在一个打开用于读写的文件上，你不能在读操作之后直接写，中间必须插入fseek、fsetpos或rewind之类的定位操作，否则行为是未定义的。这个规则在 C 标准里有明确规定，但实际写代码时很容易忘。

3. 打开与关闭：fopen的模式选择与资源管理

3.1 fopen模式详解与常见误用

fopen的第二个参数是模式字符串，常见的有"r"、"w"、"a"、"r+"、"w+"、"a+"，再加上"b"表示二进制模式。在 Linux 上，文本模式和二进制模式实际上没有区别，因为 Linux 不区分这两者；但在跨平台代码里，加上"b"是个好习惯，尤其是处理图片、音频、序列化数据的时候。

这里有几个容易出问题的地方。第一，"w"模式会截断文件，如果文件不存在就创建；"w+"也一样会截断，但同时允许读。很多人想“打开一个文件，如果不存在就创建，存在就保留内容”，结果用了"w+"，一打开就把原内容清空了。这种需求应该用"a+"或者先判断文件是否存在再用"r+"。

第二，"a"模式下的写入总是追加到文件末尾，哪怕你用了fseek把位置移到前面，写入仍然会跑到末尾去。这是 POSIX 规定的行为，在 Linux 上就是这样。如果你需要随机写入，不能用追加模式。

第三，fopen返回NULL表示失败，必须检查。失败的原因可能是文件不存在、权限不够、路径太长、文件描述符耗尽等等。用errno配合perror或strerror能打印出具体原因，这个在排查问题时非常有用。

3.2 fclose的返回值为什么不能忽略

fclose看起来简单，但它其实做了两件重要的事：把缓冲区里剩余的数据刷到内核，然后关闭文件描述符。如果刷数据的过程中出错（比如磁盘满了、网络文件系统断连了），fclose会返回EOF并设置errno。

很多代码写成fclose(fp);就完事了，不检查返回值。这在本地磁盘上通常没问题，但在网络存储、可移动介质、或者磁盘空间紧张的环境下，忽略fclose的返回值就意味着你可能丢了数据却浑然不知。正确的做法是检查返回值，如果失败，至少记录一条错误日志。

还有一个资源管理的问题：每个进程能打开的文件描述符数量是有限的，默认通常是 1024。如果程序里fopen之后忘了fclose，文件描述符会泄漏，跑一段时间后就会遇到“Too many open files”的错误。在长时间运行的服务程序里，这个问题尤其致命。用valgrind或者/proc/<pid>/fd可以排查这类泄漏。

3.3 标准输入输出的重定向与缓冲陷阱

stdin、stdout、stderr是程序启动时自动打开的三个FILE *。它们的缓冲行为会随着连接的目标不同而变化。stdout连到终端时是行缓冲，连到管道或文件时变成全缓冲。这个变化经常导致问题。

举个例子，你写了一个程序，用printf输出进度信息，在终端上跑的时候进度条一行行刷新，看着很正常。但把输出重定向到文件后，发现所有进度信息都堆在最后才出现，中间过程完全看不到。这就是因为重定向后stdout变成了全缓冲，数据攒着没刷。解决办法是在每次输出后调用fflush(stdout)，或者用setvbuf手动把stdout设成行缓冲或无缓冲。

setvbuf必须在任何其他 IO 操作之前调用，否则行为未定义。它的原型是int setvbuf(FILE *stream, char *buf, int mode, size_t size)，mode 可以是_IONBF、_IOLBF、_IOFBF。如果你传NULL作为 buf，库会自动分配缓冲区；如果传自己的缓冲区，要注意这个缓冲区的生命周期必须覆盖整个文件操作期间，不能是局部变量。

4. 读写操作：fread、fwrite与格式化IO的实战细节

4.1 fread和fwrite的返回值处理

fread和fwrite的返回值是“成功读写的元素个数”，注意是元素个数，不是字节数。如果你这样调用：fread(buf, 1, 1024, fp)，返回值就是实际读到的字节数；如果写成fread(buf, 1024, 1, fp)，返回值要么是 1（读满了）要么是 0（没读满），你就丢失了“到底读了多少字节”的信息。所以通常建议把 size 设为 1，count 设为你想要的字节数。

fwrite的返回值也需要检查。如果返回值小于 count，说明写入过程中出错了，可能是磁盘满、管道破裂、或者文件系统只读。不检查的话，数据丢了都不知道。

还有一个经典问题：fread返回 0 并不一定意味着到了文件末尾，也可能是出错了。要区分这两种情况，需要用feof和ferror。feof在读到文件末尾后返回真，ferror在发生错误后返回真。正确的读取循环通常长这样：

while ((n = fread(buf, 1, sizeof(buf), fp)) > 0) { // 处理读到的 n 个字节 } if (ferror(fp)) { // 处理错误 }

4.2 格式化IO：printf家族与scanf家族的坑

printf和scanf这两家族函数用起来方便，但坑也不少。先说printf这边，最常见的坑是格式字符串和参数类型不匹配。比如用%d打印long类型的值，在 64 位系统上就会出问题，因为long是 8 字节而int是 4 字节，参数传递时栈上的布局会对不上。正确的做法是用%ld对应long，%lld对应long long，%zu对应size_t。

snprintf比sprintf安全，因为它限制了写入的最大长度。但要注意snprintf的返回值是“假如缓冲区足够大，本应写入的字符数”，而不是实际写入的字符数。如果返回值大于等于缓冲区大小，说明输出被截断了。这个特性可以用来计算所需缓冲区大小：先传 NULL 和 0 调一次拿到长度，再分配内存调第二次。

scanf家族的问题更多。%s不检查目标缓冲区大小，输入超长就会溢出，这是经典的安全漏洞来源。scanf对换行符的处理也很反直觉：%d会跳过前导空白（包括换行），但%c不会跳过任何东西，包括换行符。所以如果你先用scanf("%d", &n)读了一个数，再用scanf("%c", &c)想读一个字符，读到的很可能是上一次输入留下的换行符。解决办法是在%c前面加一个空格：scanf(" %c", &c)，空格会告诉scanf跳过前导空白。

在实际项目里，我个人的建议是：读取结构化数据尽量用fgets配合sscanf，而不是直接用scanf。fgets能限制读取长度，避免溢出；sscanf在已知格式的字符串上解析，行为更可控。

4.3 文件定位：fseek、ftell与fgetpos

fseek用来移动文件位置指针，ftell用来获取当前位置。这两个函数在普通文件上工作正常，但在处理大文件（超过 2GB）时，ftell返回的long类型可能不够用。在 64 位 Linux 上，long是 8 字节，通常没问题；但在 32 位系统上，long是 4 字节，就会溢出。可移植的做法是用fgetpos和fsetpos，它们使用fpos_t类型，能表示任意大小的文件位置。

fseek的第三个参数可以是SEEK_SET、SEEK_CUR、SEEK_END。用SEEK_END配合ftell可以快速获取文件大小：fseek(fp, 0, SEEK_END); long size = ftell(fp);。但注意，这个操作之后文件位置在末尾，如果要继续读，得再fseek回去。

还有一个细节：fseek会丢弃缓冲区里未刷新的数据。如果你先写了一些数据没 flush，然后调fseek，那些数据会被刷出去（这是 glibc 的行为），但标准里其实没有明确规定，所以依赖这个行为是不安全的。稳妥的做法是在fseek之前手动fflush。

5. 缓冲区管理：setvbuf、fflush与性能调优

5.1 手动设置缓冲区：什么时候需要，怎么设

默认的缓冲区大小对大多数场景够用，但在一些特殊情况下需要手动调整。比如你要写一个高频日志系统，每秒写入几万条小记录，默认的 4096 字节缓冲区意味着每写满 4096 字节就触发一次系统调用。如果把缓冲区调大到 64KB 或 256KB，系统调用次数能减少一个数量级，吞吐量会明显提升。

用setvbuf设置自定义缓冲区时，有几点要注意。第一，缓冲区内存的生命周期必须覆盖整个文件操作期间，所以不能用栈上的局部数组，除非这个数组所在的作用域一直有效。第二，缓冲区大小最好是底层块大小的整数倍，比如 4096 的倍数，这样能减少部分块写入的情况。第三，设置必须在任何 IO 操作之前完成。

static char my_buf[65536]; FILE *fp = fopen("data.bin", "wb"); if (fp) { setvbuf(fp, my_buf, _IOFBF, sizeof(my_buf)); // 后续读写操作 }

5.2 fflush的正确使用姿势

fflush把用户态缓冲区的数据强制刷到内核。对于输出流，它触发一次write系统调用；对于输入流，它的行为在标准里是未定义的，虽然 glibc 允许对输入流调fflush并会丢弃缓冲的输入数据，但依赖这个行为不可移植。

什么时候必须fflush？一是程序可能在写入后崩溃，你希望关键数据已经落盘；二是多个进程或线程共享同一个文件，你需要确保自己的写入对其他读者可见；三是调试时希望日志立刻输出。但也不要滥用fflush，每次写完都刷就等于放弃了缓冲带来的性能优势，退化成和直接write差不多的效率。

还有一个容易忽略的点：fflush(NULL)会刷新所有打开的输出流。这个在程序退出前、或者 fork 之前有用。特别是 fork 的时候，子进程会继承父进程的缓冲区内容，如果父子进程都往同一个文件写，缓冲区里的数据可能被写两次。所以在 fork 之前fflush(NULL)是个好习惯。

5.3 缓冲与性能的量化关系

我做过一个简单的测试来量化缓冲对性能的影响。在同一台机器上，往一个普通文件写入 100 万条记录，每条 100 字节，总共约 100MB 数据。用三种方式对比：

这个差距在数据量更大、记录更小的时候会更明显。当然，实际性能还受磁盘类型（SSD 还是机械盘）、文件系统、是否有其他 IO 负载等因素影响，但缓冲带来的数量级差异是确定的。

6. 错误处理与常见问题排查实录

6.1 errno、perror与strerror的配合使用

标准 IO 函数出错时，通常返回NULL或EOF，具体原因放在全局变量errno里。errno是线程局部的，每个线程有自己的副本，所以多线程环境下不用担心互相覆盖。

perror会打印你给的字符串加上errno对应的描述，比如perror("fopen")可能输出fopen: No such file or directory。strerror(errno)返回描述字符串，方便你自己格式化输出。注意strerror返回的指针指向静态内存，多线程下可能被覆盖，更安全的是用strerror_r。

一个常见的错误处理模式：

FILE *fp = fopen(path, "rb"); if (!fp) { fprintf(stderr, "打开文件 %s 失败: %s\n", path, strerror(errno)); return -1; }

6.2 常见问题速查表

下面这张表整理了我在实际工作中遇到的标准 IO 相关问题，以及对应的排查思路和解决方法：

6.3 几个我踩过的坑和独家建议

第一个坑是关于fwrite的“部分写入”。fwrite在正常情况下会写完全部数据，但如果底层write因为信号中断或磁盘满而只写了一部分，fwrite会返回一个小于 count 的值。这时候你不能假设剩下的数据会自动重试，必须自己处理。我的做法是封装一个write_all函数，循环调用直到全部写完或确认出错。

第二个坑是关于fclose和fflush的顺序。有些人习惯先fflush再fclose，觉得这样更保险。实际上fclose内部就会做 flush，多调一次fflush没有坏处但也没必要。真正需要注意的是，fclose之后不能再对FILE *做任何操作，包括再次fclose，否则是未定义行为，可能直接崩溃。

第三个坑是关于临时文件的。用tmpfile()创建的临时文件在程序正常退出时会自动删除，但如果程序崩溃或被 kill，文件就会留在/tmp下。在长时间运行的服务里，如果频繁创建临时文件又崩溃，/tmp会被塞满。更可控的做法是用mkstemp自己管理临时文件的生命周期。

第四个坑是关于setlocale和格式化 IO 的交互。printf和scanf对小数点、千位分隔符的处理受 locale 影响。如果你的程序在不同 locale 环境下运行，同一个格式字符串可能产生不同的输出。对于需要固定格式的场景（比如生成配置文件、协议数据），最好在程序启动时调用setlocale(LC_ALL, "C")把 locale 固定住。

7. 标准IO与系统调用IO的选型对比

7.1 什么时候该用标准IO，什么时候该用系统调用

这个问题没有绝对答案，但有一些经验规则。标准 IO 适合：需要格式化输入输出、需要跨平台可移植性、读写的数据块比较小但频率高、不需要精确控制每次 IO 的时机。系统调用 IO 适合：需要精细控制缓冲行为、需要非阻塞 IO、需要mmap、sendfile这类高级特性、或者在做底层系统编程时。

还有一个维度是性能。标准 IO 的缓冲在大多数场景下能提升性能，但在某些场景下反而添乱。比如你要实现一个数据库的 WAL（预写日志），需要确保每条记录都真正落盘，这时候标准 IO 的缓冲反而增加了不确定性，直接用write配合fsync更可控。

7.2 混用标准IO和系统调用IO的风险

混用这两层是很多 bug 的来源。核心问题是：标准 IO 有自己的缓冲区，系统调用 IO 直接操作文件描述符，两者的“当前位置”概念可能不一致。如果你先用fread读了一些数据（数据进了标准 IO 的缓冲区，文件描述符的位置已经往前走了），然后直接用read去读同一个 fd，读到的位置会和你预期的对不上。

如果确实需要混用，必须在切换之前fflush输出流，并且用lseek重新定位文件描述符的位置。但更推荐的做法是不要混用，要么全用标准 IO，要么全用系统调用 IO。如果必须混用，可以用fileno从FILE *拿到文件描述符，但一定要清楚缓冲区的状态。

7.3 从标准IO到更高级抽象的演进

标准 IO 之上还有很多更高级的抽象，比如 C++ 的 iostream、Python 的 file object、Java 的 InputStream/OutputStream。这些抽象在底层或多或少都借鉴了标准 IO 的缓冲思想，但在错误处理、类型安全、国际化支持上做了改进。

理解标准 IO 的价值在于，它是这些高级抽象的基石。当你用 Python 的open读写文件时，底层调用的就是 C 库的fopen和fread/fwrite（CPython 的实现里确实是这样）。当你遇到 Python 文件读写性能问题、编码问题、缓冲问题时，往下一层看，往往就是标准 IO 的行为在起作用。

8. 一个完整的实战案例：带缓冲的日志写入模块

8.1 需求分析与设计决策

假设我们要写一个日志模块，需求是：支持多线程调用、每条日志带时间戳和级别、写入频率高、程序崩溃时不能丢关键日志、日志文件支持按大小滚动。基于这些需求，设计决策如下：

用标准 IO 而不是系统调用 IO，因为需要格式化输出（时间戳、级别、消息拼接），标准 IO 的fprintf比手动拼接字符串再write方便得多。用行缓冲而不是全缓冲，因为日志需要及时可见，行缓冲在每条日志末尾有换行符时会自动刷新。但行缓冲的性能不如全缓冲，所以对于高频日志场景，更好的方案是全缓冲加定期fflush，或者关键级别日志立即fflush、普通级别日志攒着。

多线程安全方面，标准 IO 本身对单个FILE对象是线程安全的，但“写一条完整日志”这个操作不是原子的。两个线程同时调fprintf，输出可能交错。解决办法是在模块层面加一把互斥锁，把“格式化+写入”作为一个临界区。

8.2 核心代码实现与注释

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #include <pthread.h> #define LOG_BUF_SIZE 8192 #define LOG_MAX_SIZE (10 * 1024 * 1024) // 10MB 滚动 static FILE *log_fp = NULL; static pthread_mutex_t log_mutex = PTHREAD_MUTEX_INITIALIZER; static char log_buf[LOG_BUF_SIZE]; static long log_written = 0; int log_init(const char *path) { log_fp = fopen(path, "a"); if (!log_fp) { fprintf(stderr, "日志文件打开失败: %s\n", strerror(errno)); return -1; } // 设置全缓冲，缓冲区用静态内存，生命周期覆盖整个程序运行期 if (setvbuf(log_fp, log_buf, _IOFBF, sizeof(log_buf)) != 0) { fprintf(stderr, "设置日志缓冲区失败\n"); fclose(log_fp); log_fp = NULL; return -1; } return 0; } void log_write(const char *level, const char *msg) { if (!log_fp) return; pthread_mutex_lock(&log_mutex); // 获取当前时间 time_t now = time(NULL); struct tm tm_buf; localtime_r(&now, &tm_buf); char time_str[32]; strftime(time_str, sizeof(time_str), "%Y-%m-%d %H:%M:%S", &tm_buf); // 格式化并写入 int n = fprintf(log_fp, "[%s] [%s] %s\n", time_str, level, msg); if (n < 0) { // 写入出错，尝试输出到 stderr fprintf(stderr, "日志写入失败: %s\n", strerror(errno)); pthread_mutex_unlock(&log_mutex); return; } log_written += n; // 关键级别日志立即刷新，普通日志攒着 if (strcmp(level, "ERROR") == 0 || strcmp(level, "FATAL") == 0) { fflush(log_fp); } // 检查是否需要滚动 if (log_written >= LOG_MAX_SIZE) { fflush(log_fp); fclose(log_fp); // 这里省略重命名和重新打开的代码 // 实际实现中需要处理滚动逻辑 } pthread_mutex_unlock(&log_mutex); } void log_close(void) { pthread_mutex_lock(&log_mutex); if (log_fp) { fflush(log_fp); fclose(log_fp); log_fp = NULL; } pthread_mutex_unlock(&log_mutex); }

8.3 这个实现里的关键决策说明

用静态缓冲区而不是malloc，是因为静态内存在程序整个生命周期内都有效，不用担心setvbuf之后缓冲区被释放的问题。缓冲区大小选 8192 而不是 4096，是因为 8192 是常见的页大小倍数，且能容纳更多日志条目，减少系统调用次数。

localtime_r而不是localtime，是因为后者返回静态内存指针，多线程下不安全。strftime用来格式化时间，比手动拼接tm结构体的字段更简洁可靠。

错误级别日志立即fflush，是为了保证程序崩溃时错误信息不丢。普通日志攒在缓冲区里，靠缓冲区满或程序正常退出时刷新。这个策略在性能和数据安全性之间取了一个平衡点。

滚动逻辑这里只写了框架，实际实现中需要考虑：滚动时其他线程可能正在写日志，所以整个滚动过程必须在锁内完成；滚动后的文件命名要避免冲突；重新打开新文件后要重新设置缓冲区。

9. 跨平台与可移植性注意事项

标准 IO 虽然叫“标准”，但不同平台在细节上仍有差异。Windows 上文本模式会把\n转换成\r\n，Linux 上不会。所以处理二进制数据时一定要加"b"。fseek和ftell在超过 2GB 的文件上，32 位平台可能有问题，用fgetpos/fsetpos更保险。setvbuf的缓冲区大小在不同 C 库实现里可能有不同的上限，设得太大可能失败。

还有一个容易忽略的点：printf的%n格式符在某些安全加固的编译环境里被禁用，因为它可能被用于格式化字符串攻击。如果你的代码里用了%n，换到新环境可能编译不过或者运行时报错。

线程安全方面，POSIX 要求标准 IO 函数是线程安全的，但 C 标准并没有这个要求。在 Linux 上用 glibc 没问题，但换到一些嵌入式 C 库可能就不是线程安全的了。如果代码需要跨平台且涉及多线程，最好自己加锁，不要依赖库的线程安全保证。

10. 一些零散但有用的经验

关于fgets的一个细节：它会把换行符也读进缓冲区（如果缓冲区够大的话）。所以读到的字符串末尾可能带\n，处理时要注意去掉。如果一行超长，fgets会分多次返回，每次读一部分，不会溢出，但你需要自己拼接。

关于fputs和fprintf的选择：如果只是输出一个字符串加换行，fputs比fprintf快，因为不需要解析格式字符串。在性能敏感的循环里，能用fputs就别用fprintf。

关于freopen：它可以改变一个已经打开的流的目标。比如把stdout重定向到文件：freopen("out.txt", "w", stdout)。这个在需要把程序输出保存到文件的场景下有用，但注意freopen之后原来的流就失效了，不能再对旧的FILE *操作。

关于remove和rename：这两个函数操作的是文件路径，不是FILE *。在 Windows 上，如果文件还被打开着，remove会失败；Linux 上则允许删除已打开的文件（文件真正被删除要等到所有引用都关闭）。跨平台代码要注意这个差异。

关于tmpfile和tmpnam：tmpnam生成一个临时文件名，但在生成和打开之间有竞争条件，不安全。tmpfile直接返回一个打开的FILE *，更安全，但文件在程序退出时自动删除，你拿不到文件名。如果需要文件名，用mkstemp。

最后说一个调试技巧：当你怀疑标准 IO 的缓冲行为导致问题时，可以用strace跟踪程序的write系统调用，看看数据到底什么时候、以多大的块写出去的。这个比在代码里到处加printf高效得多。strace -e trace=write -o trace.log ./your_program就能把所有的write调用记录下来，一目了然。