企业官网建设流程全解析

写过一阵子 Linux 下文件操作的人，对#include <sys/stat.h>这行大概都不会陌生，但真正能把它说明白的人并不多。有意思的是，不少人在搜索引擎里输的是sys.stat.h——一个把斜杠打成点的写法，这个小笔误本身就很说明问题：大家知道有这么个头文件，知道它跟文件有关，却不太清楚它到底管什么、不管什么。stat在这里不是"统计学"的统计，而是 status 的缩写。这个头文件是 POSIX 给文件系统元数据开的一扇正门：文件多大、是普通文件还是目录、权限位怎么设、最后一次内容修改发生在什么时候、硬链接数是多少，所有这些信息都通过它声明的struct stat和stat、fstat、lstat、mkdir、chmod、umask这一组接口拿到。不管你是刚接触系统编程的新手，还是写了好几年业务代码、每次碰到权限问题都靠猜的老手，把这一套东西理顺都能省下大量调试时间。下面我按"它声明了什么、结构体怎么读、三个调用怎么选、建目录改权限怎么落地、哪些字段会咬人、跨平台怎么迁"的顺序，把我踩过的和见过的坑一次讲透。

1. stat 不是"统计"：这个头文件的职责边界在哪

先把最容易混淆的一点摆正。stat这个词在这套接口里全程指代"状态"（status），sys/stat.h直译过来就是"系统状态头文件"，只不过它管的"状态"特指文件系统对象的状态。你在 shell 里敲stat somefile、ls -l背后展示的那一堆信息，包括 inode 号、权限串-rw-r--r--、大小、链接数、三个时间戳，本质上都是这个头文件声明的接口吐出来的。理解这一点，后面所有 API 的命名逻辑就顺了：fstat是"对文件描述符取状态"，lstat是"取链接本身的状态"，chmod是"改 mode"，mkdir是"造一个目录"，全都在"文件状态"这条主线上。

很多人第一次被它绊住，是因为搜到的资料要么只贴一个struct stat的字段表，要么直接甩一段stat()调用示例，中间那层"为什么需要它、什么时候不需要它"的说明是缺失的。我见过有同学为了判断一个路径存不存在，专门去#include <sys/stat.h>然后写stat调用，其实用access()或者直接open()看errno更贴合场景；也见过有人拿stat的返回值当"文件大小"用，结果对目录调用时拿到一个诡异的数字，排查了半天。这一节先把边界划清楚，后面几节再往里钻。

1.1 头文件里实际躺着三类东西

打开 glibc 的sys/stat.h（不同 libc 的具体路径不同，通常是/usr/include/x86_64-linux-gnu/sys/stat.h加一个bits/stat.h），你会发现内容高度结构化，就三类：函数声明、结构体定义、宏常量。搞清楚这三类各自的用途，比死记字段名有用得多。

需要提醒的是，mode_t、off_t这些类型严格来说是sys/types.h定义的，sys/stat.h会把它包含进来，所以你在代码里只写#include <sys/stat.h>也能用mode_t。但如果你要在别的地方单独声明一个mode_t变量而又不涉及 stat 系列函数，规范做法是显式包含sys/types.h。这个细节在移植到某些精简 libc 时会突然变成编译错误，属于"平时不出事、换环境就炸"的典型。

还有几个不那么常用的成员值得知道：mkfifo用来创建命名管道，做进程间通信时会用到；futimens和utimensat可以在不改变文件内容的前提下精确设置访问时间和修改时间，做构建系统或者增量同步工具时特别有用，它们支持两个特殊值UTIME_NOW和UTIME_OMIT，后者表示"这个时间戳别动"，省去了先读再写的麻烦。

1.2 为什么有很多代码不写这行也能编过

这是新手最容易产生的错觉：明明自己没写#include <sys/stat.h>，代码里却能用struct stat，编译还没报错。原因通常是别的头文件把它间接带进来了。比如某些项目的公共头文件里包含了<sys/types.h>和<sys/stat.h>，或者某个第三方库的头文件顺手包含了它，于是你的源文件"白嫖"到了声明。

这种依赖是非常脆弱的。glibc 能过不代表 musl 能过，Linux 能过不代表 macOS 能过。我遇到过不止一次：本地开发机编译一切正常，CI 跑在 Alpine 上直接报storage size of 'st' isn't known——因为struct stat是不完整类型，编译器根本不知道要分配多大空间。修起来很简单，加一行 include 就行，但排查过程如果没有"隐式包含"这个意识，很容易怀疑到别的地方去。

提示：判断某个类型是不是靠隐式包含拿到的，最直接的办法是把可疑的 include 全部注释掉，只留标准库的最小集合，重新编译一次，报错位置会立刻告诉你真相。

养成习惯：只要你的代码里出现了struct stat、mode_t、S_ISDIR这些符号，就在该源文件顶部显式写上#include <sys/stat.h>，哪怕它已经被别的头文件包含过。多余的一行 include 有头文件保护，不会带来任何运行时开销，但能省下未来某次跨平台构建的一小时。

1.3 和 fcntl.h、unistd.h 的分工要理清

文件操作相关的头文件容易混，这里给一个我自己的记忆方式：打开与属性在 fcntl.h 和 sys/stat.h，读写与关闭在 unistd.h。open()的O_RDONLY、O_CREAT、O_NOFOLLOW这些标志位在fcntl.h里；read()、write()、close()、unlink()、rmdir()、access()在unistd.h里；而stat系列、chmod系列、mkdir、umask在sys/stat.h里。

这个分工不是随意划的，它反映的是"元数据操作"和"数据流操作"的分离。stat不碰文件内容，只读 inode 里的信息；chmod也不碰内容，只改 inode 里的权限位。而read/write走的是文件描述符的数据通道。理解了这层，你就明白为什么fstat需要一个已经打开的 fd，而stat只需要一个路径——前者是在数据通道建立之后再问元数据，后者是直接按路径去查。

2. struct stat 的字段不是摆设，st_mode 才是主战场

struct stat的字段数量在不同平台上略有差异，Linux 上大概十来个，字段顺序由 ABI 固定，绝对不要自己照着网上的文章复制一份结构体定义——这是我在代码评审里见过的最危险的操作之一。你自己定义的struct stat和系统头文件里的布局一旦对不上，stat()调用不会报错，它会老老实实往你给的那块内存里按系统布局写数据，然后你按自己的布局去读，读出来的就是一堆垃圾值。这种 bug 极难排查，因为没有任何错误码提示。

正确做法永远是#include <sys/stat.h>然后用系统给的定义。如果你确实需要跨编译单元传递这些信息，也应该传自己定义的一个精简结构体，在边界处做一次显式拷贝转换。

2.1 按用途把字段分成四组

字段多，硬背没意义，按用途分组记就轻松了。下面这张表我按"标识、类型、尺寸、时间"四组整理：

两个容易混的点提前说清楚。第一，st_blksize是"推荐 I/O 块大小"，通常是 4096，它是给read/write缓冲区大小做参考的，不是文件占用的块大小；真正表示磁盘占用的是st_blocks，单位固定为 512 字节，跟st_blksize没关系。第二，st_size对普通文件是字节数，对符号链接是链接目标字符串的长度，对目录是"实现相关"的——也就是说你在 Linux 上看到目录的st_size是 4096 或者更大，别拿它当"目录里文件总大小"用，那完全是两回事。

时间字段的命名在不同平台上还有差异。Linux/glibc 用st_atim、st_mtim、st_ctim（带tv_sec和tv_nsec），同时保留了st_atime、st_mtime、st_ctime这几个宏作为兼容别名（只取秒部分）。macOS 上则叫st_atimespec、st_mtimespec、st_ctimespec。写跨平台代码时，取秒级时间用st_mtime最稳，需要纳秒精度就得加平台判断。

2.2 st_mode 的位布局：高四位定类型，低十二位定权限

st_mode是mode_t类型（通常是 32 位无符号整型），它把"文件类型"和"权限位"塞进了同一个整数里。这个设计非常紧凑，但也意味着你必须用位掩码来读，不能直接比较。

高位的文件类型占了 4 个比特，掩码是S_IFMT，八进制0170000。具体取值：

低十二位是权限，八进制07777。其中最高的三位是特殊位：S_ISUID（04000）、S_ISGID（02000）、S_ISVTX（01000），剩下九位是属主/属组/其他的 rwx。S_IRWXU是0700，S_IRUSR是0400，S_IWUSR是0200，S_IXUSR是0100，G和O两组同理右移。

为什么必须用S_IFMT掩码？因为st_mode里同时有类型位和权限位，你写if (st.st_mode == S_IFDIR)永远为假，除非这个目录权限恰好是 0。正确的写法是(st.st_mode & S_IFMT) == S_IFDIR，或者直接用宏S_ISDIR(st.st_mode)。

2.3 别再手写 (mode & 0170000) == 0100000 了

S_ISREG、S_ISDIR、S_ISLNK、S_ISCHR、S_ISBLK、S_ISFIFO、S_ISSOCK这一组宏就是上面位运算的封装。它们的实现在 glibc 里大致是这样：

#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG) #define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR) #define S_ISLNK(m) (((m) & S_IFMT) == S_IFLNK)

我见过不少老代码直接写st.st_mode & S_IFDIR来判断目录，这在多数情况下"碰巧能用"，因为目录的类型位0040000里有非零位，与运算结果非零就为真。但它是错的：任何类型为S_IFREG的文件，st_mode里0040000这一位也可能是 1（0100000和0040000的位并不互斥），于是普通文件会被误判成目录。这类 bug 在测试环境里可能因为样本文件权限简单而侥幸躲过，一到生产就爆。

一个完整的类型判断写法：

#include <sys/stat.h> #include <stdio.h> static const char *type_name(mode_t m) { if (S_ISREG(m)) return "regular"; if (S_ISDIR(m)) return "directory"; if (S_ISLNK(m)) return "symlink"; if (S_ISCHR(m)) return "char-device"; if (S_ISBLK(m)) return "block-device"; if (S_ISFIFO(m)) return "fifo"; if (S_ISSOCK(m)) return "socket"; return "unknown"; }

注意S_ISLNK只在lstat的结果里才可能为真。stat()会跟随符号链接，返回的是目标文件的状态，所以对软链接调用stat得到的类型是目标文件的类型。这个差异是下一节的重点。

3. stat、fstat、lstat 的选择逻辑与 TOCTOU 竞态

三个函数签名几乎一样，参数都是"路径或 fd +struct stat *"，理解它们的差异是写好文件操作代码的分水岭。用错不会编译报错，但行为会差出十万八千里。

3.1 三者的差异点浓缩成一句话

stat跟随符号链接，lstat不跟随，fstat用已打开的文件描述符。这句总结好记，但真正重要的是知道什么时候该用哪个。

遍历目录树时，99% 的情况应该用lstat。因为你要的是"这个目录项本身是什么"，遇到符号链接就记录下来、不去跟随，否则一个指向父目录的软链接会让你的递归无限循环，直接把栈打爆。这个坑我在写第一个文件清理脚本时踩过，脚本跑了三秒就把内存吃满了。

反过来，你要判断"这个路径能不能读、多大、是不是普通文件"，用stat更符合直觉——因为你接下来要open的就是目标文件，问链接本身的状态没有意义。

3.2 软链接场景下的实测差异

拿一个软链接做对照，差别一目了然。假设link.txt -> real.txt，real.txt内容是 5 个字节：

#include <sys/stat.h> #include <stdio.h> #include <time.h> void dump(const char *tag, const struct stat *st) { printf("%-6s type=%s size=%lld ino=%llu\n", tag, S_ISLNK(st->st_mode) ? "LNK" : S_ISREG(st->st_mode) ? "REG" : "OTHER", (long long)st->st_size, (unsigned long long)st->st_ino); } int main(void) { struct stat a, b; if (stat("link.txt", &a) == 0) dump("stat", &a); if (lstat("link.txt", &b) == 0) dump("lstat", &b); return 0; }

实测输出大致是：stat那行显示REG、size=5，lstat那行显示LNK、size=8（也就是real.txt这个目标字符串的长度）。同一个路径，两个调用给出完全不同的答案，st_ino也可能不同（软链接有自己的 inode）。这就是为什么备份工具、rsync这类软件必须用lstat——它们要原样保留链接结构，而不是把链接解开变成实体文件。

3.3 先 stat 再 open 的经典竞态

这是安全领域的老问题，但日常业务代码里天天有人这么写：

/* 反例：TOCTOU（检查时与使用时不一致） */ struct stat st; if (stat(path, &st) == 0 && S_ISREG(st.st_mode)) { int fd = open(path, O_RDONLY); /* 这一行之间，path 可能被换掉 */ /* ... */ }

问题在于stat和open之间存在一个时间窗口。如果这个路径在共享目录、临时目录，或者被其他进程可控，攻击者可以在这两步之间把普通文件替换成指向敏感位置的符号链接，你的open就会打开意料之外的文件。这类漏洞有个统一的名字叫 TOCTOU。

还有一种变体更隐蔽：先用stat检查文件大小，再按这个大小分配缓冲区去读。中间文件被追加内容，读的时候缓冲区就不够了。或者反过来，文件被截断，你读到一堆空洞。

3.4 正确的姿势是 open 完再 fstat

把检查挪到打开之后，用fstat对已经拿到的 fd 做判断，路径就不再参与后续决策，竞态窗口彻底消失：

#include <fcntl.h> #include <sys/stat.h> #include <unistd.h> #include <errno.h> int open_regular(const char *path, int *out_fd, struct stat *out_st) { int fd = open(path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC); if (fd == -1) return -1; /* ELOOP 表示最后一段是软链接 */ struct stat st; if (fstat(fd, &st) == -1) { int saved = errno; close(fd); errno = saved; return -1; } if (!S_ISREG(st.st_mode)) { close(fd); errno = EINVAL; return -1; } *out_fd = fd; *out_st = st; return 0; }

这里有三个细节值得展开。O_NOFOLLOW保证如果路径最后一段是符号链接就直接失败（errno为ELOOP），这是比lstat更彻底的防护，因为它把检查和打开合并成一个原子操作。O_CLOEXEC让 fd 在exec家族调用后自动关闭，避免子进程意外继承——这个标志在写守护进程或者调用外部命令时几乎是必须的，不加的话很容易出现"文件句柄泄漏到子进程、父进程关了子进程还占着"的怪现象。最后，错误处理里要先把errno存下来再close，因为close本身失败时会覆盖errno，这个坑我调过不止一次。

注意：open成功后立刻fstat，然后基于st做所有后续判断，中间不要再碰路径字符串。这条规则能消灭你代码里 90% 的文件相关竞态。

4. 建目录与改权限：mkdir、chmod、umask 的联动实操

sys/stat.h里被用得最多的函数其实是mkdir，其次才是stat。而mkdir又是最容易让人产生"我的参数怎么不生效"疑问的一个。

4.1 mkdir 的 mode 参数为什么经常"不生效"

mkdir("/tmp/mydir", 0777); /* 你以为会得到 drwxrwxrwx */

跑完ls -ld /tmp/mydir，看到的多半是drwxr-xr-x，也就是0755。这不是 bug，是umask在起作用。mkdir的第二个参数叫"期望权限"，实际创建出来的权限等于mode & ~umask。

umask是进程级属性，含义是"从新建文件的默认权限里屏蔽掉哪些位"。绝大多数 shell 的默认umask是022，也就是屏蔽掉组和其他用户的写权限。所以0777 & ~022 = 0755，0775 & ~022 = 0755，0700 & ~022 = 0700。

计算过程拆开看更清楚。~022在 32 位下是...1111111111011101，跟0777按位与，把0022对应位置的两个 1 清零，得到0755。如果umask是077，那0777 & ~077 = 0700，只有属主有权限。做安全敏感的服务时，很多团队会把服务进程的umask显式设成077，确保新建文件天然对其他用户不可见。

想读到当前umask而不改变它，标准做法是先设后恢复：

#include <sys/stat.h> mode_t current_umask(void) { mode_t old = umask(0); umask(old); return old; }

这个写法有个小瑕疵：中间那一瞬间umask是 0，如果是多线程程序，恰好有别的线程在这个窗口里创建文件，就会得到过于宽松的权限。对权限敏感的场景，正确做法是在程序启动、还没起线程的时候就记录一次umask，后面直接用缓存值。

4.2 递归建目录：mkdir -p 的手写实现

标准 C 库没有mkdir -p的等价函数，需要自己逐级创建。这个函数看起来简单，但错误处理有不少讲究：

#include <sys/stat.h> #include <string.h> #include <errno.h> #include <limits.h> int mkdir_p(const char *path, mode_t mode) { char tmp[PATH_MAX]; size_t len = strlen(path); if (len == 0 || len >= sizeof(tmp)) { errno = ENAMETOOLONG; return -1; } memcpy(tmp, path, len + 1); for (char *p = tmp + 1; *p != '\0'; p++) { if (*p != '/') continue; *p = '\0'; if (mkdir(tmp, mode) == -1 && errno != EEXIST) return -1; *p = '/'; } if (mkdir(tmp, mode) == -1) { if (errno != EEXIST) return -1; struct stat st; if (stat(tmp, &st) == -1) return -1; if (!S_ISDIR(st.st_mode)) { errno = ENOTDIR; return -1; } } return 0; }

几个关键点。第一，从tmp + 1开始扫描，跳过第一个字符，这样处理绝对路径/a/b/c时不会尝试创建空字符串路径。第二，EEXIST不能无条件当成成功——如果这个位置上已经存在一个同名普通文件，mkdir同样返回-1且errno是EEXIST，但它不是目录，后续往里写文件会失败。所以最终一步必须补一次stat确认是目录，不是就返回ENOTDIR。第三，中间层级遇到EEXIST不做检查是常见取舍，因为逐级stat会显著增加系统调用次数；如果你对健壮性要求高，可以把每个层级都检查一遍，代价是路径深度翻倍的 syscall。第四，PATH_MAX在有些系统上是不确定的（比如 GNU Hurd），严格可移植的写法要用动态分配，日常 Linux 环境用PATH_MAX够用。

还有一个细节容易被忽略：中间层级的mkdir用的也是同样的mode，但最终权限会被umask削减。如果你需要指定精确权限（比如0750），应该在全部创建完成后对最终目录调一次chmod，因为chmod不受umask影响。

4.3 chmod 与 fchmod 的差别，以及什么情况下必须用后者

chmod(path, mode)按路径改权限，fchmod(fd, mode)按已打开的 fd 改。两者语义一样，区别只在竞态安全性：如果你已经打开了文件，再按路径去chmod，中间路径可能被替换，你改的就是另一个文件的权限。稳妥的顺序永远是open→fchmod→close。

int fd = open(path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC); if (fd == -1) return -1; if (fchmod(fd, 0640) == -1) { int e = errno; close(fd); errno = e; return -1; } close(fd);

另外提一句，chmod对符号链接的行为是"改目标文件"，不是改链接本身——因为链接自身没有有意义的权限位（在 Linux 上永远是0777，且chmod跟随链接）。想改链接的权限是做不到的，这不是 API 限制，而是文件系统层面就没这个概念。

5. 时间戳、inode 和 st_size：几个一定会咬人的字段

字段表背下来只是起点，真正让你加班的往往是这些字段的语义边界。

5.1 三个时间戳，ctime 不是创建时间

st_atime是访问时间，读文件内容会更新它（现代内核用 relatime 策略，只有在特定条件下才真正写盘，所以别指望它精确到每次 read）；st_mtime是内容修改时间，写入文件内容会更新；st_ctime是状态变更时间，改权限、改属主、改名、加硬链接都会更新它。

最常被误解的是st_ctime，很多人以为它是 "create time"。不是。Linux 的struct stat里根本没有创建时间字段，要拿创建时间得用statx系统调用（stx_btime），而且还得看文件系统支不支持。这个误会在排查"文件明明没改内容，mtime 怎么变了"这类问题时特别误导人——实际上变的常常是 ctime，因为有人改了权限或者重命名了目录。

打印时间戳要注意ctime()返回的字符串自带换行，而且不是线程安全的。多线程环境用ctime_r或者strftime：

#include <time.h> #include <stdio.h> char buf[32]; struct tm tm_buf; localtime_r(&st.st_mtime, &tm_buf); strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", &tm_buf); printf("mtime=%s\n", buf);

5.2 st_ino 加 st_dev 才是文件的唯一身份

想判断"两个路径是不是同一个文件"，比较路径字符串是肯定不行的，软链接、硬链接、..都能绕过它。正确的是比较st_dev和st_ino的组合：

static int same_file(const struct stat *a, const struct stat *b) { return a->st_dev == b->st_dev && a->st_ino == b->st_ino; }

st_dev不能省，因为 inode 号只在单个文件系统内唯一，不同挂载点下完全可能出现相同 inode 号的两个文件。st_nlink则表示这个 inode 上有多少个硬链接，普通文件通常是 1，目录至少是 2（自身的.加上父目录里的条目），这也可以用来粗略判断某个路径是不是挂载点。

5.3 st_size 在非普通文件上不可靠

前面提过目录的st_size是实现相关的，这里再补几个。对管道、字符设备、套接字文件调用stat，st_size通常是 0，不代表"没有数据"。对块设备，st_size可能也是 0，要拿设备容量得用ioctl配合BLKGETSIZE64。对/proc下的文件，st_size普遍是 0，因为内容是动态生成的，你读出来的字节数和st_size完全对不上。

所以任何"先stat拿大小、再按大小分配缓冲"的代码，都必须先确认S_ISREG为真。我见过一个日志读取工具，遇到/proc/self/status时因为st_size是 0 直接判定"文件为空"跳过了，排查了半天才发现是字段语义问题。

5.4 32 位系统上的大文件与 EOVERFLOW

在老一些的 32 位环境里，off_t默认是 32 位，超过 2GB 的文件调用stat会失败，errno是EOVERFLOW。这个错误码不常见，很容易被当成"权限问题"或者"文件不存在"忽略掉。

解决办法是编译时加-D_FILE_OFFSET_BITS=64，让off_t在编译期变成 64 位：

gcc -D_FILE_OFFSET_BITS=64 -O2 reader.c -o reader

这个宏必须在包含任何系统头文件之前定义，所以只能通过编译选项传，写在源文件里往往太晚了。现在主流 64 位平台默认off_t就是 64 位，不太会碰到这个问题，但如果你维护的是嵌入式或者老系统上的代码，这条是必查项。顺便说，fopen时代对应的是fopen64、stat64、lseek64这一套，现在用宏的方式更省心。

6. 跨平台迁移与三条真实排查链路

最后聊聊换平台时会发生什么，以及几个我实际处理过的排查过程。

6.1 Windows、C++17 和脚本语言的对应物

Windows 的 MSVC 其实也提供<sys/stat.h>，但里面的东西是另一套：函数叫_stat、_stat64、_fstat，结构体叫struct _stat或struct _stat64，字段名是st_mode、st_size、st_mtime这套没错，但类型宽度和行为不同。文件类型宏也不一样，用的是_S_IFREG、_S_IFDIR，权限宏是_S_IREAD、_S_IWRITE，没有执行位这个概念。st_ino在 Windows 上是 0 或没有意义，st_nlink对普通文件基本恒为 1。写跨平台代码时，通常的做法是抽一层薄封装，平台相关的部分用条件编译隔开，对外暴露统一的判定接口。

C++17 之后有个更省事的选择：<filesystem>。std::filesystem::status(path)返回file_status，is_regular_file()、is_directory()、is_symlink()这些方法语义清晰，std::filesystem::perms枚举把权限位也抽象好了。它底层在 POSIX 平台就是调stat/lstat，但屏蔽了类型宽度和字段名差异。缺点是对错误处理的方式变了——它用error_code重载，默认版本会抛异常，在禁用异常的嵌入式环境里要用带error_code的那个版本。

脚本语言里对应的是 Python 的os.stat()，返回os.stat_result具名元组，配合标准库stat模块的S_ISREG(mode)等函数使用，思路和 C 完全一致。理解 C 的这套模型之后，看其他语言的封装基本是降维。

6.2 排查链路一：errno 被 close 覆盖导致误判

现象：一个清理脚本偶尔把"权限不足"的文件当成"不存在"跳过，日志里errno显示ENOENT，但人工核对文件确实存在。

排查过程是这样的。先看代码：

int fd = open(path, O_RDONLY); if (fd == -1) { if (errno == ENOENT) { /* 当作不存在，静默跳过 */ } else { perror("open"); } return; } struct stat st; if (fstat(fd, &st) == -1) { close(fd); /* 问题在这一行 */ if (errno == ENOENT) { /* 这里读到的是 close 留下的 errno */ } }

问题很清楚了：fstat失败后调close，close执行成功不会重置errno，但如果它内部有任何系统调用设置了errno，就会把原值覆盖掉。虽然规范允许函数成功时保持errno不变，但依赖这一点是非常脆弱的。修法就是前面示例里那个模式：先存int saved = errno;，再close，最后errno = saved;。

这条经验可以推广成一条硬规则：在多步错误处理中，每一个可能调用系统函数的清理动作之前，都要先保存errno。

6.3 排查链路二：自己定义 struct stat 导致的幽灵 bug

现象：一个历史项目在新机器上编译通过，但读出来的文件大小全是几十亿的离谱数字，权限判断也完全错乱。

顺着代码看，在某个老旧的兼容头文件里发现了一段手写的结构体定义，注释写着"为了兼容某些平台"。这段定义大概是十几年前照着一份文档抄的，字段顺序和现在的 ABI 已经对不上，还漏了st_blksize、st_blocks和时间戳字段。stat()把 144 字节（或更多）的数据写进只有 88 字节的结构体里，直接踩爆了栈，同时后续读取全按错误偏移解析。

修复方式是删掉自定义定义，改成#include <sys/stat.h>。这里给一个可复用的排查手法：拿sizeof(struct stat)打印一下，和系统文档对照；再用offsetof(struct stat, st_size)看字段偏移，如果和官方布局对不上，基本就能锁定问题。这类 bug 的特点是"只在某些平台上错"，因为老平台 ABI 可能碰巧兼容，迁移之后就全乱了。

6.4 排查链路三：umask 在守护进程里意外变成 0

现象：一个后台服务启动后创建的文件全是0666，其他用户可读可写，安全审计直接报了问题。开发环境复现不出来。

排查从mkdir、open的 mode 参数查起，参数写的都是0640，看起来没问题。继续追，发现服务启动脚本里有一段初始化逻辑，为了"临时拿到真实 umask"调了umask(0)，然后因为某个异常分支提前 return，恢复那行没执行到。进程的umask就永久变成了 0，之后所有文件创建都按mode & ~0来，等于完全不做削减。

这类问题的修法是：读取umask的操作要么放在进程启动最早期、所有分支都保证恢复，要么干脆用pthread_atfork或者启动时缓存的方式避免中途修改。更稳的思路是根本不去读它——如果你需要精确权限，就在创建后显式chmod，这样umask是什么值都无所谓。

我个人在写这类文件操作代码时，会坚持三条：凡是涉及路径和打开的地方，一律open后fstat，不信任两次调用之间的世界；凡是涉及权限，创建时给宽一点的mode再用fchmod收紧，避免被umask意外削减；凡是涉及错误处理，errno一律先存后恢复。这三条看着啰嗦，但真能省掉大量"本地复现不出来、线上偶尔出现"的排查时间。如果你现在手上正好有一段用stat判断存在性的代码，可以翻出来看看它后面跟着的open，那中间的一行空隙，就是最值得重写的地方。