Linux C文件I/O核心：open/close系统调用原理与实战避坑

1. 这不是教科书里的“打开文件”，而是你写第一个真实C程序时真正要面对的底层动作

很多人学Linux C文件I/O，一上来就背open()的三个参数、close()的返回值含义，结果写完代码发现文件打不开、数据写不进去、程序莫名卡死——不是函数用错了，是根本没搞懂：open()不是“点一下就开”的按钮，而是一次与内核的正式交涉；close()也不是“关掉就完事”的开关，而是对系统资源的一次郑重归还。我在某嵌入式项目里调试一个日志模块，连续三天查不出为什么每写满2MB就丢数据，最后发现是open()漏了O_SYNC标志，而close()前又没做fsync()，缓存里的日志压根没刷进磁盘。这种问题，翻十遍man手册也找不到答案，只有亲手把每个系统调用的语义、上下文、副作用都摸透，才能稳住。

这个标题里提到的open、creat、close，表面看是三个基础函数，实则构成Linux文件I/O最核心的“生命周期管理三件套”。它解决的不是“怎么读写”，而是“如何安全、可控、可追溯地让一个文件在你的程序里出生、存活、死亡”。适合谁？适合所有正在写C程序、需要操作文件（配置、日志、数据交换）的开发者；适合刚从Windows转Linux、还在用fopen/fclose思维写代码的人；更适合那些strace过自己程序、看到一堆openat和close却看不懂背后逻辑的中级工程师。关键词很直白：Linux C、文件I/O、open、creat、close——但它们背后牵扯的是文件描述符表、进程地址空间、VFS抽象层、页缓存机制、原子性保障……我们不堆概念，只讲你敲下open("/tmp/log.txt", O_WRONLY|O_CREAT, 0644)这一行时，内核到底做了什么，以及你漏掉哪个参数，程序就会在凌晨三点给你发告警。

2. 整体设计思路：为什么必须用open/close，而不是fopen/fclose？

2.1 核心逻辑：系统调用 vs 库函数，这是两条完全不同的技术路径

很多初学者混淆open()和fopen()，以为只是“底层”和“高级”的区别。错。它们是不同抽象层级、不同错误模型、不同资源管理策略的两套体系。open()是系统调用（system call），直接陷入内核，返回一个整数——文件描述符（file descriptor, fd）。这个fd是进程级的、全局唯一的、内核可直接索引的句柄。而fopen()是C标准库（glibc）封装的函数，返回一个FILE*指针，内部维护着自己的缓冲区、偏移量、错误状态，甚至可能复用同一个fd来管理多个FILE*流。

提示：strace ./myapp看到的全是openat(2)、close(2)，绝不会出现fopen——因为fopen在用户态完成，根本没进内核。你调试IO问题时，如果只盯fopen，等于在雾里看花。

我带过的一个新人项目，需求是实时采集传感器数据并写入SD卡。他用fopen+fprintf，结果在高频率写入时，fprintf的行缓冲导致数据延迟上百毫秒，且fclose时因缓冲区未刷盘，断电后整个文件损坏。换成open(O_SYNC|O_DSYNC)+write()+close()后，数据落盘时间稳定在5ms内，断电恢复率100%。这不是性能优化，是语义对齐：你要的是“数据已物理写入”，fopen给不了，open+O_SYNC才给得了。

2.2 方案选型依据：什么时候必须用open/close？

不是所有场景都要抛弃fopen。选型关键看三个硬指标：

1. 是否需要精确控制同步行为？
   日志、金融交易、设备控制等场景，要求“调用返回即落盘”。fopen的setvbuf()无法保证fflush()后数据一定进磁盘（它只刷到内核页缓存），而open的O_SYNC标志强制绕过页缓存，直写设备；O_DSYNC则只保证数据+元数据（如修改时间）同步，性能稍好。这是fopen永远无法提供的能力。

2. 是否需要原子性创建或截断？
   open(..., O_CREAT|O_EXCL)是原子的“检查并创建”，不存在竞态条件（两个进程同时执行，只有一个成功）。而fopen("xxx", "wx")虽有类似语义，但POSIX标准不保证其原子性，某些glibc实现会先stat再open，中间存在时间窗口。在分布式锁、临时文件生成等场景，这会导致严重逻辑错误。

3. 是否需要细粒度的文件描述符操作？
   比如dup2(fd, STDOUT_FILENO)重定向标准输出，或fcntl(fd, F_SETFL, O_NONBLOCK)设置非阻塞，或epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev)将文件加入事件循环——这些操作的对象只能是open()返回的fd，FILE*对此完全无能为力。

注意：creat()函数已过时，它等价于open(path, O_WRONLY|O_CREAT|O_TRUNC, mode)。现代代码应直接用open()，避免使用creat()。这是POSIX.1-2008明确标注的废弃接口，glibc虽仍保留，但新项目中出现creat()会被资深同事直接标红。

2.3 避坑前提：理解文件描述符的本质与生命周期

文件描述符不是“数字编号”那么简单。它是进程打开文件表（open file table）中的一个索引，该表由内核维护，每个条目包含：

• 指向inode的指针（文件元数据）
• 当前文件偏移量（lseek修改的就是它）
• 文件状态标志（O_APPEND,O_NONBLOCK等）
• 引用计数（多个fd可指向同一打开文件条目）

close(fd)的作用，是将该fd从进程的文件描述符表中删除，并将对应打开文件条目的引用计数减1。仅当引用计数降为0时，内核才真正释放该条目，关闭底层设备连接，刷盘缓存。这意味着：如果你用dup(fd)复制出fd2，然后close(fd)，文件并未关闭，fd2仍可正常读写。这是close()常被误解的核心——它关的是“句柄”，不是“文件”。

我在某网络代理服务中遇到过经典案例：主进程fork()子进程处理连接，父子进程共用一个日志fd。父进程在exec新程序前close(log_fd)，但子进程仍在用它写日志。结果新程序启动后，log_fd被分配给其他文件（如配置文件），日志数据全写进了配置文件里，导致服务启动失败。根源就是没理解close()只减引用计数，而非立即切断IO。

3. 核心细节解析：open、creat、close的参数、返回值与底层行为

3.1open()：不只是“打开”，而是一次完整的文件状态协商

int open(const char *pathname, int flags, ... /* mode_t mode */);

open()的签名看似简单，但三个参数组合出的语义极其丰富。我们拆解最常用的flags组合及其真实含义：

flags组合	典型用途	内核实际行为	常见误用
O_RDONLY	只读打开	检查文件是否存在、是否有读权限；不修改inode	误用于需要O_SYNC的只读日志回放，导致缓存不一致
O_WRONLY | O_CREAT | O_EXCL	原子创建新文件	若文件存在，open失败（errno= EEXIST）；若不存在，创建并返回fd	忘加O_EXCL，导致多进程竞争时覆盖已有文件
O_RDWR | O_APPEND	追加写入	每次write()前，内核自动lseek(fd, 0, SEEK_END)，确保写入位置总在末尾	与lseek()混用，lseek后write仍会跳回末尾，破坏预期偏移
O_WRONLY | O_TRUNC	清空重写	打开时立即将文件长度截为0，原内容丢失	在O_TRUNC后未检查open返回值，若失败则后续write写入未知位置

mode参数（仅当O_CREAT存在时必需）不是“设置最终权限”，而是“提供给内核的权限建议”。最终文件权限 =mode & ~umask。例如，进程umask为0022，open("a.txt", O_CREAT, 0666)，实际创建的文件权限是0644（rw-r--r--）。这是新手常踩的坑：以为0666就能创建可写的组权限，结果被umask默默过滤掉了。

实操心得：永远用umask(0)临时清空掩码再open，或显式计算mode & ~umask。我在某配置生成工具中，因忽略umask，导致生成的/etc/myapp.conf权限为0600，其他服务无法读取，排查了两天才发现是umask在作祟。

open()的返回值是核心判断依据：

• 成功：返回非负整数（最小可用fd，通常是3，因为0/1/2已被stdin/stdout/stderr占用）
• 失败：返回-1，并设置errno。必须检查返回值！我见过太多代码直接int fd = open(...); write(fd, ...)，一旦open失败（如磁盘满、权限不足），fd为-1，write(-1, ...)会触发SIGPIPE或静默失败，日志里只有一行write: Bad file descriptor，毫无上下文。

3.2creat()：一个被时代淘汰的简化接口

int creat(const char *pathname, mode_t mode);

creat()等价于open(pathname, O_WRONLY|O_CREAT|O_TRUNC, mode)。它的存在，是早期Unix为简化常用操作（创建并清空写入）而设的快捷方式。但在现代Linux中，它已失去存在价值：

1. 功能冗余：open()通过flags组合可实现creat()全部功能，且更灵活（如支持O_APPEND、O_SYNC等）。
2. 语义模糊：creat()隐含O_TRUNC，但开发者可能只想创建而不清空，此时必须用open()。
3. 标准废弃：POSIX.1-2008明确将其标记为“obsolescent”，未来版本可能移除。

注意：creat()没有flags参数，因此无法指定O_EXCL实现原子创建。这是它最致命的缺陷。在并发环境下，creat()永远存在竞态风险，而open(..., O_CREAT|O_EXCL)是唯一可靠的原子创建方案。

3.3close()：一次轻量但至关重要的资源回收

int close(int fd);

close()看似最简单，却是最容易出问题的函数。它的行为远比“关掉文件”复杂：

• 成功时：返回0。fd从进程文件描述符表中移除，对应打开文件条目的引用计数减1。
• 失败时：返回-1，设置errno。常见失败原因：
  • EBADF：fd无效（已关闭、未打开、负数）
  • EINTR：被信号中断（极少见，但需处理）
  • EIO：底层IO错误（如磁盘故障，此时close()可能触发数据刷盘失败）

最关键的细节：close()失败时，fd的状态是未定义的。POSIX标准规定，若close()返回-1且errno == EINTR，fd仍有效，可再次close()；但若errno为EIO，fd可能已部分关闭，再次调用close()行为未定义。因此，健壮代码应这样写：

int ret = close(fd); if (ret == -1) { if (errno == EINTR) { // 被信号中断，重试 ret = close(fd); } if (ret == -1 && errno != EBADF) { // EBADF表示fd已无效，可忽略 perror("close"); // 记录错误，但不要abort，避免程序崩溃 } } fd = -1; // 关闭后立即将fd置为-1，防止重复close

实操心得：close()后立即将fd赋值为-1，是防御性编程铁律。我在某长期运行的监控服务中，因忘记置零fd，导致close()失败后，后续逻辑误用该fd进行write()，数据全写进了/dev/null，而日志里没有任何报错，直到客户投诉数据缺失才定位到。

4. 实操过程：从零开始构建一个安全、可调试的日志写入模块

4.1 需求分析与接口设计

假设我们要为一个嵌入式设备开发日志模块，核心需求：

• 日志必须实时落盘，断电不丢数据
• 支持按大小轮转（单个日志文件不超过1MB）
• 多线程安全（多个模块可同时调用日志API）
• 错误可追踪（记录open/write/close的详细错误码）

基于此，我们设计C接口：

// log.h typedef struct { int fd; // 当前日志fd off_t size; // 当前文件大小 const char *path; // 日志路径模板，如 "/var/log/app_%d.log" } log_ctx_t; int log_init(log_ctx_t *ctx, const char *base_path); void log_write(log_ctx_t *ctx, const char *fmt, ...); void log_close(log_ctx_t *ctx);

4.2log_init()：安全打开日志文件的完整流程

// log.c #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> #include <string.h> int log_init(log_ctx_t *ctx, const char *base_path) { if (!ctx || !base_path) return -1; // 步骤1：构造日志文件名（如 /var/log/app_0.log） char path[PATH_MAX]; snprintf(path, sizeof(path), "%s_0.log", base_path); // 步骤2：原子创建新文件，确保不覆盖旧日志 // 使用 O_CREAT|O_EXCL|O_WRONLY|O_SYNC 组合 int fd = open(path, O_CREAT|O_EXCL|O_WRONLY|O_SYNC, 0644); if (fd == -1) { if (errno == EEXIST) { // 文件已存在，说明上次未正常关闭，尝试打开并追加 fd = open(path, O_WRONLY|O_APPEND|O_SYNC); if (fd == -1) { fprintf(stderr, "log_init: failed to open existing %s: %s\n", path, strerror(errno)); return -1; } // 获取当前文件大小，用于轮转判断 ctx->size = lseek(fd, 0, SEEK_END); if (ctx->size == -1) { perror("log_init: lseek"); close(fd); return -1; } } else { fprintf(stderr, "log_init: failed to create %s: %s\n", path, strerror(errno)); return -1; } } else { // 新建成功，size为0 ctx->size = 0; } ctx->fd = fd; ctx->path = strdup(base_path); // 保存base_path用于轮转 return 0; }

关键点解析：

• 原子性保障：首次open(..., O_CREAT|O_EXCL)确保不会意外覆盖旧日志。若失败且errno==EEXIST，说明文件已存在，再用O_APPEND|O_SYNC打开，保证追加写入。
• 同步写入：O_SYNC标志确保每次write()后，数据和元数据（如修改时间）都已写入磁盘，这是断电不丢数据的基石。
• 错误分级处理：对EEXIST特殊处理，其他错误直接返回，避免掩盖真实问题。

4.3log_write()：带轮转与错误捕获的写入逻辑

#include <stdarg.h> #include <time.h> void log_write(log_ctx_t *ctx, const char *fmt, ...) { if (!ctx || ctx->fd == -1) return; // 步骤1：格式化日志内容（含时间戳） char buf[1024]; time_t now = time(NULL); struct tm *tm_info = localtime(&now); char time_str[32]; strftime(time_str, sizeof(time_str), "%Y-%m-%d %H:%M:%S", tm_info); va_list args; va_start(args, fmt); int len = vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); if (len < 0 || len >= (int)sizeof(buf)) { // 格式化失败，写入简短错误 const char *err_msg = "[LOG ERROR: message too long]\n"; write(ctx->fd, err_msg, strlen(err_msg)); return; } // 步骤2：检查轮转条件（当前大小 + 新消息长度 > 1MB） const off_t MAX_SIZE = 1024 * 1024; // 1MB if (ctx->size + len + 64 > MAX_SIZE) { // +64预留时间戳和换行 log_rotate(ctx); } // 步骤3：写入日志（含时间戳和换行） char full_msg[1024 + 64]; int full_len = snprintf(full_msg, sizeof(full_msg), "[%s] %s\n", time_str, buf); if (full_len > 0 && full_len < (int)sizeof(full_msg)) { ssize_t wlen = write(ctx->fd, full_msg, full_len); if (wlen != full_len) { // write失败，记录错误但不abort fprintf(stderr, "log_write: write failed, expected %d, got %zd, errno=%d\n", full_len, wlen, errno); } ctx->size += (wlen > 0 ? wlen : 0); } } static void log_rotate(log_ctx_t *ctx) { if (!ctx || !ctx->path) return; // 关闭当前fd if (ctx->fd != -1) { close(ctx->fd); ctx->fd = -1; } // 构造新文件名（递增序号） static int seq = 0; char new_path[PATH_MAX]; snprintf(new_path, sizeof(new_path), "%s_%d.log", ctx->path, ++seq); // 重新open新文件 ctx->fd = open(new_path, O_CREAT|O_WRONLY|O_SYNC, 0644); if (ctx->fd == -1) { fprintf(stderr, "log_rotate: failed to create %s: %s\n", new_path, strerror(errno)); // 降级：尝试写回原文件（即使超限） ctx->fd = open(strcat((char*)ctx->path, "_overflow.log"), O_CREAT|O_WRONLY|O_APPEND|O_SYNC, 0644); } ctx->size = 0; }

关键点解析：

• 轮转前置检查：在write()前计算ctx->size + len + 64，预判是否超限，避免write()后才发现要轮转，导致部分日志写入旧文件、部分写入新文件。
• 错误隔离：write()失败时，只记录错误，不终止程序。日志模块本身不能成为系统单点故障。
• close()后置零：log_rotate()中close(ctx->fd)后立即将ctx->fd置为-1，防止后续误用。

4.4log_close()：优雅关闭与资源清理

void log_close(log_ctx_t *ctx) { if (!ctx) return; // 步骤1：关闭fd（注意：close()失败不abort） if (ctx->fd != -1) { int ret = close(ctx->fd); if (ret == -1) { if (errno == EINTR) { // 被信号中断，重试 close(ctx->fd); } else if (errno != EBADF) { fprintf(stderr, "log_close: close failed: %s\n", strerror(errno)); } } ctx->fd = -1; } // 步骤2：释放动态分配的path内存 if (ctx->path) { free((void*)ctx->path); ctx->path = NULL; } }

关键点解析：

• 双重防护：close()后置零fd，且检查ctx->fd != -1再执行，避免重复close(-1)。
• 内存安全：free()后置空指针，防止悬垂指针。

5. 常见问题与排查技巧实录：那些让你熬夜的open/close陷阱

5.1 典型问题速查表

问题现象	可能原因	排查命令/方法	解决方案
open()返回-1，errno=2（ENOENT）	文件路径不存在，或上级目录无执行权限（x）	ls -ld /path/to/dir检查目录权限；strace -e trace=openat ./myapp看具体路径	确保路径存在，且所有上级目录有x权限（Linux中目录的x权限=可进入）
open()返回-1，errno=13（EACCES）	权限不足：文件无读/写权限，或目录无搜索权限	ls -l /path/to/file；getfacl /path/to/dir（检查ACL）	用chmod修正权限；确认umask未过度过滤mode
write()成功但文件为空	open()漏了O_SYNC，数据在页缓存未刷盘	sync命令后检查文件；cat /proc/sys/vm/dirty_ratio查缓存阈值	加O_SYNC或O_DSYNC；或write()后调用fsync(fd)
close()后write()仍成功	fd被dup()或fork()继承，未真正关闭	lsof -p $(pidof myapp)查看进程所有fd	确认close()前未dup()；fork()后子进程需自行close()
程序运行缓慢，strace显示大量openat	频繁打开/关闭同一文件，未复用fd	strace -c -e trace=openat,close ./myapp统计调用次数	将fd作为全局或静态变量复用，避免循环内open/close

5.2 独家避坑技巧：来自十年踩坑现场

技巧1：用strace定位open失败的真实路径
新手常写open("config.txt", ...)，以为在当前目录，实际程序chdir()到了/var/run。strace能暴露真相：

strace -e trace=openat,open ./myapp 2>&1 | grep open # 输出：openat(AT_FDCWD, "config.txt", O_RDONLY) = -1 ENOENT (No such file or directory) # AT_FDCWD 表示相对路径，实际查找路径是进程当前工作目录

解决方案：用绝对路径，或readlink /proc/self/cwd确认当前目录。

技巧2：close()失败时，errno可能被后续系统调用覆盖
以下代码是危险的：

close(fd); if (errno == EIO) { ... } // 错！errno可能已被printf修改

正确写法：

int ret = close(fd); int saved_errno = errno; // 立即保存 if (ret == -1 && saved_errno == EIO) { ... }

技巧3：O_CLOEXEC标志是守护进程的隐形盾牌
fork()后，子进程会继承父进程所有fd。若父进程打开了数据库连接、日志文件，子进程exec新程序后，这些fd仍保持打开，浪费资源且可能泄露敏感信息。解决方案：open()时加O_CLOEXEC标志：

int fd = open("/tmp/log.txt", O_WRONLY|O_CREAT|O_CLOEXEC, 0644); // fork()后，子进程exec时，该fd自动关闭

这是编写守护进程、system()调用的必备实践。

技巧4：/proc/PID/fd/是你的调试透视镜
当怀疑fd泄漏，直接查看：

ls -l /proc/$(pidof myapp)/fd/ # 输出：0 -> /dev/pts/0, 1 -> /dev/pts/0, 2 -> /dev/pts/0, 3 -> /var/log/app.log # 若看到大量3,4,5...指向同一文件，说明未及时close()

配合lsof -p PID，可精确定位哪段代码打开了未关闭的fd。

5.3 实战排错案例：一个open返回-1的深夜故事

某夜，线上服务突然拒绝写入日志，strace显示：

openat(AT_FDCWD, "/var/log/app.log", O_WRONLY|O_APPEND|O_SYNC) = -1 EMFILE (Too many open files)

EMFILE表示进程打开的文件描述符已达上限（默认1024）。lsof -p $(pidof app)显示有1023个fd，全指向/dev/zero。排查代码，发现一个网络模块在accept()后，对每个连接open("/dev/zero", O_RDONLY)获取一个fd，但忘记close()。修复后，添加ulimit -n 4096临时扩容，并在代码中加入fd计数告警。

这个案例教会我：open()失败的第一反应，不是改路径或权限，而是先查ulimit -n和lsof。大多数“神秘错误”，根源都在资源耗尽。

6. 工具链与调试辅助：让open/close行为可视化

6.1strace：系统调用的X光机

strace是观察open/close行为最直接的工具。常用组合：

• strace -e trace=openat,close,write ./myapp：只跟踪IO相关系统调用
• strace -f -e trace=openat,close ./myapp：跟踪子进程（fork后）
• strace -o trace.log ./myapp：输出到文件，便于分析

关键解读：

• openat(AT_FDCWD, "path", flags) = fd：成功，返回fd
• openat(..., flags) = -1 ENOENT (No such file or directory)：失败，errno明确
• close(fd) = 0：成功
• close(fd) = -1 EBADF (Bad file descriptor)：fd无效

提示：openat()是open()的现代变种，AT_FDCWD表示相对路径基于当前工作目录。strace默认显示openat，不影响理解。

6.2/proc/PID/status：进程资源快照

/proc/PID/status中的FDSize和SigQ字段，能快速判断fd使用情况：

cat /proc/$(pidof myapp)/status | grep -E "FDSize|SigQ" # FDSize: 1024 # 当前fd表大小 # SigQ: 0/63759 # 信号队列使用量（无关，但常一起看）

结合ls /proc/PID/fd/ | wc -l，可计算fd使用率。

6.3 自定义open/close包装器：为调试注入日志

在开发阶段，可临时替换系统调用，注入调试信息：

#define _GNU_SOURCE #include <dlfcn.h> #include <stdio.h> #include <errno.h> static int (*real_open)(const char*, int, ...) = NULL; static int (*real_close)(int) = NULL; int open(const char *pathname, int flags, ...) { if (!real_open) real_open = dlsym(RTLD_NEXT, "open"); va_list args; va_start(args, flags); mode_t mode = va_arg(args, mode_t); va_end(args); int fd = real_open(pathname, flags, mode); fprintf(stderr, "[DEBUG] open('%s', 0x%x, 0%o) = %d (errno=%d)\n", pathname, flags, mode, fd, errno); return fd; } int close(int fd) { if (!real_close) real_close = dlsym(RTLD_NEXT, "close"); int ret = real_close(fd); fprintf(stderr, "[DEBUG] close(%d) = %d (errno=%d)\n", fd, ret, errno); return ret; }

编译为共享库：gcc -shared -fPIC -o libdebug.so debug.c -ldl
运行时注入：LD_PRELOAD=./libdebug.so ./myapp
效果：所有open/close调用都会打印到stderr，无需修改源码。

这个技巧在我调试一个第三方库的fd泄漏时救了大命——它暴露了库内部隐藏的open("/dev/random")却未close()的行为。

7. 性能与安全边界：open/close的极限在哪里？

7.1 性能瓶颈分析：open()为何比fopen()慢？

open()慢，是因为它每次都要：

• 切换到内核态（用户态→内核态，约1000ns）
• 遍历VFS层，解析路径名（/a/b/c需三次目录查找）
• 检查inode权限、访问控制列表（ACL）
• 分配并初始化打开文件表项

而fopen()在用户态完成，路径解析、缓冲区分配均在用户空间，且fopen后fwrite可批量写入，减少系统调用次数。性能差距在高频小文件操作中明显：10万次open/close耗时约200ms，而10万次fopen/fclose约80ms。

优化策略：

• 复用fd：对同一文件，open()一次，多次write()，最后close()。避免循环内open/write/close。
• 批量写入：用writev()或sendfile()替代多次write()。
• 异步IO：io_uring或aio_write()，将open/write/close提交到内核队列，用户态无阻塞。

7.2 安全边界：open()能打开多少文件？

Linux单进程fd上限由ulimit -n控制，默认1024。可通过ulimit -n 65536提升。但物理上限受内存限制：每个fd在内核中占用约1KB内存（打开文件表项+inode缓存），65536个fd约需64MB内核内存。

更关键的安全问题是符号链接攻击：open("user_input.txt", O_CREAT)若user_input.txt是恶意符号链接（如/etc/passwd），可能导致覆盖系统文件。解决方案：

• 使用openat(AT_FDCWD, path, O_CREAT|O_NOFOLLOW)，O_NOFOLLOW禁止跟随符号链接
• 或用openat(dirfd, basename, O_CREAT)，在已知安全目录下操作

注意：O_NOFOLLOW在open()中不可用，必须用openat()。这是现代安全编码的硬性要求。

7.3 最佳实践清单：写在代码注释里的经验

我把这十年总结的open/close黄金法则，浓缩成可直接复制到代码头的注释：

/* * open()/close() 使用守则（2024版） * 1. 永远检查 open() 返回值，-1 时立即处理 errno * 2. 优先用 open() + O_SYNC/O_DSYNC，而非 fopen() + fflush()，确保落盘语义 * 3. 原子创建必用 open(..., O_CREAT|O_EXCL)，禁用 creat() * 4. close() 后立即将 fd = -1，防止重复 close 或误用 * 5. 多线程环境，fd 不可跨线程共享（除非明确 dup() 并同步管理） * 6. fork() 后，子进程需自行 close() 不需要的 fd，或 open 时加 O_CLOEXEC * 7. 调试 IO 问题，第一反应：strace -e trace=openat,close,write；第二反应：lsof -p PID * 8. 生产环境，open() 失败必须记录 errno 字符串（strerror(errno)），而非只记数字 */

这条清单，是我带过的每个新人入职第一天必须抄写三遍的内容。它不炫