Linux系统编程：目录遍历、文件元数据与用户组映射实战解析

做Linux系统编程，几乎每个实际项目都逃不过两件事：处理目录、处理用户。无论是写一个日志清理工具、做文件分发脚本，还是给某个服务写启动器，底层都是在不停地遍历目录、读取文件元数据、再根据uid/gid去判断“这个文件是谁的、该不该动”。这篇总结就是我整理的一份实操梳理，从目录流遍历到用户组映射，把最容易卡壳的原理和细节一次说清，适合正在写C/C++系统工具、或者刚把《APUE》翻到一半打算上手练一练的开发者。

1. 整体思路与方案选型

很多人一提到“目录和用户操作”，第一反应就是shell里敲ls -l、chown、useradd，但系统编程里的工作方式完全不同：你不用去解析ls的输出，而是直接调用POSIX提供的接口，在程序内部拿到目录项、文件状态和uid/gid，然后按照自己的业务逻辑去过滤、排序、统计、修改。这一套东西组合起来，就是一个完整系统工具的底层骨架。

1.1 核心需求拆解

我可以把这部分内容拆成三个独立但又紧密关联的能力：

第一，目录遍历。你需要能打开一个目录、逐个读取其中的条目，并且能够递归进入子目录，处理目录树。这是所有文件类工具的基础能力，对应接口是opendir、readdir、closedir。

第二，文件元数据获取。拿到一个目录项的名字之后，光有名字没有用，你还得知道它的大小、类型、权限、属主、修改时间。这些信息都封装在struct stat里，通过stat或lstat一次性取回。

第三，用户和组的映射。stat结构里存的属主是uid和gid，是数字。一个正常的系统里没人记得住某个文件属于“1004”号用户，你需要通过getpwuid、getgrgid把它转成可读的用户名、组名，甚至继续查出该用户的主目录、登录shell。

这三个能力串起来，就能实现一个非常典型的工具：把某个目录树下的所有文件枚举出来，按用户分组统计磁盘占用，或者批量检查某个目录下是否存在属主异常的敏感文件。这些都是实际工作里高频出现的小需求。

1.2 为什么用POSIX API而不是调shell命令

有一种偷懒的做法是：在C代码里system("ls -lR")，然后把输出拿回来逐行解析。我在早期阶段确实这么干过，后来再也没这么干，原因有三点：

解析成本高且脆弱。ls的输出是给人看的，不同发行版、不同locale、不同终端宽度下格式都可能变化，你还得去对齐列、容忍文件名里的空格和特殊字符，稍微有个文件名带换行符就能让解析直接崩溃。

无谓的性能损耗。每次调用system都要fork一个子进程，加载/bin/ls，再通过管道把结果传回来。如果是在几万文件的目录上做递归遍历，这个开销高到无法接受。而直接调readdir只是在用户态和内核态之间交换目录项数据，快一个数量级。

无法精细控制行为。比如你要在遍历过程中对某些特殊文件跳过处理、对符号链接做不同分支、累计每个子目录的大小，这些逻辑写在shell管道里不是不能做，但会变得极其别扭。用API直接拿数据，业务逻辑全在自己代码里，灵活得多。

打个比方，调shell命令相当于你打电话给前台让帮忙查一份档案，前台把摘要念给你，你再对着摘要去做判断；而直接调POSIX API，是你自己拿着钥匙进档案库，每一张原始卡随便翻。后者看着麻烦，但可控性完全不可同日而语。

2. 目录操作的核心细节

2.1 目录流的三步走：open、read、close

目录遍历的标准流程非常简单，就是打开目录流、循环读取条目、关闭目录流。核心接口长这样：

#include <dirent.h> #include <stdio.h> #include <string.h> int list_dir(const char *path) { DIR *dir = opendir(path); if (dir == NULL) { perror("opendir"); return -1; } struct dirent *entry; while ((entry = readdir(dir)) != NULL) { printf("%s\n", entry->d_name); } closedir(dir); return 0; }

这里面的关键结构体是struct dirent，在Linux的glibc头文件中定义大致如下：

struct dirent { ino_t d_ino; /* inode号 */ off_t d_off; /* 目录项偏移 */ unsigned short d_reclen; /* 本记录长度 */ unsigned char d_type; /* 文件类型 */ char d_name[256]; /* 文件名 */ };

d_name是最常用的，注意它是一个固定大小的字符数组，理论上最长可以到255字节，实际使用时要小心长文件名截断问题。

d_type在Linux上是个很有用的字段，它直接告诉你能不能从目录项本身推断文件类型，常见的值有DT_REG（常规文件）、DT_DIR（目录）、DT_LNK（符号链接）、DT_UNKNOWN（类型未知）。我自己在写代码时基本都会判断d_type，但你也必须清楚：d_type不是POSIX标准强制要求实现的，有些文件系统（尤其是特殊文件系统如某些网络文件系统）拿不到这个值，返回DT_UNKNOWN。所以严谨的代码应该在DT_UNKNOWN时回退到lstat。

另外有个非常容易踩的坑：目录遍历会被.,..这两个隐藏项污染，不加过滤的话递归遍历会无限套娃。标准做法是拿到d_name后先判断是不是.或..，是就跳过。

if (strcmp(entry->d_name, ".") == 0 || strcmp(entry->d_name, "..") == 0) { continue; }

2.2 递归遍历目录树的正确姿势

实现目录树的递归遍历，核心逻辑不复杂：遇到类型是目录的条目，构造子路径，递归调用自身。但这里面有三个细节，我在做树形统计工具的时候翻过车，值得单独拿出来讲。

第一，路径拼接。不能简单写sprintf(buf, "%s/%s", parent, name)就完事，要提前确认parent末尾有没有斜杠。两种风格都能用，但我建议统一约定：无论传入的是/home/user还是/home/user/，都在内部处理成末尾带斜杠，然后拼接时直接"%s%s"。这样可以避免双斜杠的路径出现在后续调用里。

第二，递归深度。对于普通场景，目录树深度能到几十层就不错了，递归没风险。但如果被恶意构造出超深目录结构（比如做安全审计时），无限制递归会导致栈溢出。我看过某开源工具确实因为这个问题被搞崩过，所以严谨实现里要加一个深度参数，超过比如512层就报错返回，而不是继续递归。

第三，符号链接目录。判断“是不是目录”时，如果你用stat，遇到一个指向目录的符号链接，它会告诉你这是目录；用lstat则会告诉你这是符号链接。递归遍历时，应该忽略符号链接目录，否则很容易形成循环——某符号链接指回上一级目录，你就无限绕圈了。这一点在后续状态获取部分还会细讲，遍历阶段先记住结论：递归时用lstat判断，只对真正的目录递归，遇到符号链接一律跳过。

2.3 目录条目的过滤与排序

readdir返回的目录项顺序是文件系统原生顺序，对用户来讲就是无规律的。如果你只是遍历一遍，无规律没问题；如果要输出一份稳定的清单或者做分页展示，就必须自己排序。做法是先把所有d_name收集进一个数组，然后qsort。

int cmp_str(const void *a, const void *b) { return strcoll(*(const char **)a, *(const char **)b); } // 收集后排序 char *names[MAX_ENTRIES]; int count = 0; // ... 循环 readdir，strdup(d_name) 存入 names qsort(names, count, sizeof(char *), cmp_str);

这里用strcoll而不是strcmp，好处是它会按照当前locale的排序规则来比，中文和英文混排时行为更符合用户预期。缺点是依赖locale，服务器上locale不统一时输出顺序会有差异，这种时候用strcmp反而稳定。我自己的实践是：简单工具用strcmp，面向用户的交互工具用strcoll。

过滤逻辑就看业务需求了。举例：你只想保留.log后缀的文件，那就每次readdir之后检查strcmp(entry->d_name + strlen(entry->d_name) - 4, ".log") == 0；你想跳过隐藏文件，判断entry->d_name[0] == '.'（注意.和..要单独跳过，否则会误伤）。

在这部分最后提一个经验：不要在readdir循环里直接做重活，比如在循环体内拼接超大路径、发起网络请求之类的。先把需要的目录项收集到内存，再统一处理。因为目录流本身占有内核资源，循环时间越长，期间文件系统变更导致的“目录项消失/新增”概率越大，处理时容易碰上一堆边界情况。

3. 文件状态与权限解析

3.1 stat、lstat、fstat三兄弟怎么选

拿到文件名之后，下一步就是调用stat系列函数获取文件状态。三个接口的差别一句话说清：

• stat(path, &buf)：查看路径对应文件的信息，如果路径指向符号链接，则返回的是链接目标的信息。
• lstat(path, &buf)：查看路径自身的信息，如果路径指向符号链接，返回的是符号链接本身的信息（如链接大小，类型为S_IFLNK）。
• fstat(fd, &buf)：查看已打开文件描述符对应的文件信息，不需要路径名。

日常工具开发，我的默认选择是lstat，原因在递归遍历那段也提过：避免符号链接带来的信息不可控。你遍历目录时拿到一个名字叫"link_file"的目录项，对它调stat，很可能解析出一个与直觉完全不同的类型和大小。用lstat能让你确切看到“这个目录项本身是什么”。

举个具体场景：你想统计某个目录下所有文件占多少磁盘，但目录里有个指向/dev/zero的符号链接。如果用了stat，/dev/zero这个字符设备的大小是0，不碍事；如果有个符号链接指向一个几百GB的文件，stat会把这个几百GB算进你的目录占用统计里，那报表可就好看极了。用lstat则只看链接文件自身的占位（通常就是目标路径字符串长度）。两种统计口径各有道理，但对于“目录占了多少空间”，显然应该排除符号链接指向的外部文件。

调用返回后的struct stat，在Linux x86_64下关键字段长这样：

struct stat { dev_t st_dev; /* 设备ID */ ino_t st_ino; /* inode号 */ mode_t st_mode; /* 文件类型 + 权限位 */ nlink_t st_nlink; /* 硬链接数 */ uid_t st_uid; /* 属主uid */ gid_t st_gid; /* 属组gid */ dev_t st_rdev; /* 设备文件专用 */ off_t st_size; /* 大小字节数 */ blksize_t st_blksize; /* 块大小 */ blkcnt_t st_blocks; /* 占用块数 */ struct timespec st_atim; /* 最后访问时间 */ struct timespec st_mtim; /* 最后修改时间 */ struct timespec st_ctim; /* 状态变更时间 */ };

3.2 st_mode的二进制结构与权限判断

st_mode是整个结构里信息密度最高的一个字段，它同时编码了文件类型和权限位，是一个16位的位掩码字段。我建议你把它当作位图来记，而不是单纯记数字：

• bit 15~12：文件类型，对应宏S_IFMT，判断方式是用st_mode & S_IFMT再和S_IFREG、S_IFDIR、S_IFLNK等比较。更简洁的是直接用S_ISREG(st_mode)、S_ISDIR(st_mode)、S_ISLNK(st_mode)这类宏，内部就是“掩码+比较”。
• bit 11~9：特殊权限位，分别是S_ISUID（setuid，数字4000）、S_ISGID（setgid，数字2000）、S_ISVTX（sticky，数字1000）。
• bit 8~6：属主权限，即S_IRUSR、S_IWUSR、S_IXUSR。
• bit 5~3：属组权限。
• bit 2~0：其他用户权限。

这些宏会让人望而生畏，所以很多程序干脆用八进制数判断，比如检查文件是否可写、可执行时直接st_mode & 0444、st_mode & 0111。我不反对这种做法，但有个必须警惕的坑：只判断权限位不看文件类型，会得出荒谬结论。比如对一个符号链接文件，它的0777权限位通常永远都是满的（符号链接权限本身没意义，实际生效的是目标文件权限），这时候你用st_mode & 0222去判断“该文件是否可写”，一个指向只读文件的符号链接会返回“可写”，因为它自己的权限位是可写的。

所以先类型判断，再权限判断，顺序不能乱。我写过一个小函数来输出文件的权限字符串（类似ls -l的-rwxr-xr-x），每次都是先按类型确定第一个字符，再按位逐一填充：

void mode_to_string(mode_t mode, char buf[11]) { /* 文件类型 */ if (S_ISDIR(mode)) buf[0] = 'd'; else if (S_ISLNK(mode)) buf[0] = 'l'; else if (S_ISREG(mode)) buf[0] = '-'; else if (S_ISCHR(mode)) buf[0] = 'c'; else if (S_ISBLK(mode)) buf[0] = 'b'; else if (S_ISSOCK(mode))buf[0] = 's'; else if (S_ISFIFO(mode))buf[0] = 'p'; else buf[0] = '?'; /* 属主权限 */ buf[1] = (mode & S_IRUSR) ? 'r' : '-'; buf[2] = (mode & S_IWUSR) ? 'w' : '-'; buf[3] = (mode & S_IXUSR) ? 'x' : '-'; /* setuid位 */ if (mode & S_IXUSR && mode & S_ISUID) buf[3] = 's'; else if (!(mode & S_IXUSR) && mode & S_ISUID) buf[3] = 'S'; /* 属组权限，逻辑同上 */ buf[4] = (mode & S_IRGRP) ? 'r' : '-'; buf[5] = (mode & S_IWGRP) ? 'w' : '-'; buf[6] = (mode & S_IXGRP) ? 'x' : '-'; if (mode & S_IXGRP && mode & S_ISGID) buf[6] = 's'; else if (!(mode & S_IXGRP) && mode & S_ISGID) buf[6] = 'S'; /* 其他用户权限 */ buf[7] = (mode & S_IROTH) ? 'r' : '-'; buf[8] = (mode & S_IWOTH) ? 'w' : '-'; buf[9] = (mode & S_IXOTH) ? 'x' : '-'; if (mode & S_IXOTH && mode & S_ISVTX) buf[9] = 't'; else if (!(mode & S_IXOTH) && mode & S_ISVTX) buf[9] = 'T'; buf[10] = '\0'; }

关键细节在于setuid/setgid/sticky位与执行位的组合显示：小写s/t表示“特殊位和执行位同时有效”，大写S/T表示“特殊位有效但执行位无效”。如果不处理这一层，你会看到一个文件明明是-rw-r--r--却带着4000位，用ls显示是-rwsr--r--，自己写的程序却显示成-rw-r--r--，怎么排查都对不上，最终才发现是小写转换问题。

3.3 属主属组与“是不是我的文件”

st_uid和st_gid确认了文件归谁所有。系统编程里常遇到的一个需求是：检查当前进程是否有权限删除/修改一个文件。这里不能只看st_uid == geteuid()，因为Linux权限模型有“属主、属组、其他”三个档位，判断逻辑是逐级下探的。

我的做法是封装一个get_access_class函数，返回当前有效用户相对于这个文件属于哪一档：

enum access_class { CLASS_OWNER, CLASS_GROUP, CLASS_OTHER, CLASS_ROOT }; enum access_class classify(const struct stat *st) { if (geteuid() == 0) return CLASS_ROOT; /* root 几乎啥都能干 */ if (st->st_uid == geteuid()) return CLASS_OWNER; if (st->st_gid == getegid()) return CLASS_GROUP; return CLASS_OTHER; }

注意两点：第一，root判断要放在最前面。root虽然能绕过绝大多数权限限制，但绕过的方式和普通用户完全不同（比如root对只读文件也未必能直接写，要看具体挂载和inode标志），代码逻辑上单独处理最清晰。第二，属组判断不能只看st_gid，还需要用getgroups获取进程附加组列表，因为一个用户可能属于多个组，附加组同样拥有“属组权限”档位的访问资格。简化场景不做也对，但做运维工具时，很多“怎么权限明明在组里却操作失败”的排查，最后都落在这个细节上。

4. 用户与组映射的底层逻辑

4.1 uid/gid到底是什么

uid（用户ID）和gid（组ID）本质上是内核用于权限检查的整数，它们跟“用户名”这种字符串没有直接关系。系统里维护了一个数据库把整数映射到可读名称，传统上就是/etc/passwd和/etc/group，现在很多环境走的是NSS（Name Service Switch），可能从LDAP、SSSD、NIS等来源解析。

常规Linux发行版的uid分配有约定俗成的范围：

但别在生产代码里硬编码。你写死“uid>=1000就是普通用户”，到某套精简环境的容器里可能完全对不上，用户ID 999也照样是登录用户。真要判断用户类型，应该去查/etc/login.defs或者直接用getpwuid看返回的pw_shell、pw_dir等字段是否有效。

4.2 getpwuid/getgrgid的正确打开方式

把uid转成用户名的标准接口是：

#include <pwd.h> #include <grp.h> struct passwd *pw = getpwuid(st.st_uid); struct group *gr = getgrgid(st.st_gid); printf("%s %s\n", pw->pw_name, gr->gr_name);

struct passwd和struct group同样由静态存储区管理，多次调用会互相覆盖，所以千万不能这样写：

printf("%s %s\n", getpwuid(a)->pw_name, getpwuid(b)->pw_name);

这行代码先调第一个getpwuid(a)，返回的pw指针指向静态区；随后调第二个getpwuid(b)，静态区被覆盖；结果两个%s打印出来的都是getpwuid(b)的用户名。

正确做法是每次用完立刻拷贝，或者放入局部变量再输出。在多线程环境下问题更严重，因为静态区是进程级共享的，线程A调用时线程B调用就会踩踏数据。此时必须用可重入版本getpwuid_r和getgrgid_r，提前分配缓冲区：

#define BUFSZ 1024 char buf[BUFSZ]; struct passwd pw, *result = NULL; int ret = getpwuid_r(st.st_uid, &pw, buf, BUFSZ, &result); if (ret != 0 || result == NULL) { /* uid 无对应用户 */ }

还有一个非常隐蔽的坑：uid可能没有对应的passwd条目。文件可能由被删除的用户遗留下来，或从其他系统同步过来，getpwuid返回NULL。遇到这种情况直接打印uid数字就好，而不是解引用NULL指针导致段错误。我在实际中见过不少“一跑就崩，gdb一查是getpwuid返回NULL”的程序。

注意：getpwuid成功与否不是判断“用户是否存在”的唯一标准。在NSS配置复杂的环境下，一次查询失败可能只是LDAP临时不可达，不代表用户不存在。严谨做法是检查errno，EINTR时可以重试几次。

4.3 真实用户、有效用户与setuid位

这块是系统编程里最容易绕晕的点。简单说：

• getuid()返回真实用户ID，代表“你是谁”。
• geteuid()返回有效用户ID，代表“内核用你来判断本次文件访问权限”。

正常情况下两者相等。但如果一个可执行文件设置了setuid位（chmod u+s），那么运行它时，内核会把进程的有效用户ID改成文件属主的uid。典型例子是passwd命令，它属主是root、带setuid位，普通用户运行时有效用户变成root，因此能写/etc/shadow。

看文件权限时，你会看到这类文件的属主权限位处有一个s，比如-rwsr-xr-x。前面3.2节我写的转换函数就是专门处理这个的。

在编程实践里要注意：如果你写了一个设置setuid位的工具，务必在程序开头用getuid()和geteuid()做比较，主动识别自己处于提权状态。有些工具用完特权后还要显式调用seteuid(getuid())把有效用户降回去，避免意外获得过高权限。很多安全事故都出在“忘记降权”这种不明不白的实现里。

4.4 用户映射的常见误区

除开线程安全问题，用户映射还有三个我反复踩过的坑：

第一，不能拿用户名当唯一标识。系统里完全可以存在两个相同用户名的条目对应不同uid（比如NSS配置里/etc/passwd先命中，LDAP里还有同名用户）。权限判断必须一律以uid为准，用户名只作为给人看的展示字段。

第二，组名与用户名可以同名。用户joker的默认组名往往也叫joker，但这俩是不同数据库的不同条目。看到输出里名字相同，不要下意识认为是同一回事。

第三，别忽略“没有名称”的情况。容器环境里.dockerenv常见这种场景：文件属主是宿主机uid映射过来的一个超大整数（比如1234567），容器里的/etc/passwd根本没有它。这时getpwuid直接NULL，显示“1234567”比显示“unknown (1234567)”更不容易误导人。

5. 综合实操：写出一个带用户映射的目录树工具

5.1 工具功能设计

光讲接口太散，我把它们串成一个具体项目来做演示。目标是一个命令行小工具，行为类似ls -l，但专门用于目录树的批量展示和统计。功能如下：

• 指定一个起始目录，递归遍历所有子目录；
• 对每个文件/目录输出：类型、权限字符串、属主名、组名、大小（字节）、最后修改时间；
• 可选参数--sort=name|size|mtime控制输出顺序；
• 可选参数--filter=REGEX只显示文件名匹配的文件；
• 结束后打印总计文件数、目录数、占用磁盘块数。

这个工具覆盖了本文前面提到的几乎所有核心点，可以作为你练习的起点。

5.2 完整实现与构建方式

主程序我拆成三个函数来展示核心逻辑。第一个是递归遍历，第二个是权限转字符串，第三个是用户映射。因为完整代码比较长，我挑关键片段讲，完整代码组织结构最后给出。

递归遍历主循环：

static int walk_dir(const char *path, int depth, options *opt, stats *st) { if (depth > MAX_DEPTH) return -1; DIR *dir = opendir(path); if (!dir) { perror(path); return -1; } struct dirent *entry; char child_path[PATH_MAX]; while ((entry = readdir(dir)) != NULL) { if (!strcmp(entry->d_name, ".") || !strcmp(entry->d_name, "..")) continue; if (snprintf(child_path, sizeof(child_path), "%s/%s", path, entry->d_name) >= (int)sizeof(child_path)) { fprintf(stderr, "path too long: %s/%s\n", path, entry->d_name); continue; } struct stat stbuf; if (lstat(child_path, &stbuf) != 0) { perror(child_path); continue; } /* 过滤 */ if (opt->pattern && !regex_match(opt->pattern, entry->d_name)) continue; record_entry(child_path, entry->d_name, &stbuf, st); if (S_ISDIR(stbuf.st_mode)) { /* 递归进入真正的子目录，符号链接目录跳过 */ walk_dir(child_path, depth + 1, opt, st); } } closedir(dir); return 0; }

记录条目时做用户映射：

static void record_entry(const char *path, const char *name, const struct stat *stbuf, stats *st) { Entry *e = &st->entries[st->count++]; snprintf(e->path, sizeof(e->path), "%s", path); struct passwd *pw = getpwuid(stbuf->st_uid); struct group *gr = getgrgid(stbuf->st_gid); if (pw) snprintf(e->owner, sizeof(e->owner), "%s", pw->pw_name); else snprintf(e->owner, sizeof(e->owner), "%d", stbuf->st_uid); if (gr) snprintf(e->group, sizeof(e->group), "%s", gr->gr_name); else snprintf(e->group, sizeof(e->group), "%d", stbuf->st_gid); mode_to_string(stbuf->st_mode, e->mode_str); e->size = stbuf->st_size; e->blocks = stbuf->st_blocks; e->mtime = stbuf->st_mtim.tv_sec; }

排序逻辑用qsort加按需回调即可，不再重复贴代码。构建方式用一条gcc命令就行：

gcc -O2 -o dirstat dirstat.c -Wall -Wextra

如果后续要加正则过滤，记得链接pcre2或regex库，#include <regex.h>用的是POSIX正则，在glibc里属于libc无需额外链接。

5.3 运行效果与结果验证

假设在某个测试目录/tmp/demo下有这些内容：

demo/ ├── a.txt ├── sub/ │ ├── b.log │ └── link_to_a -> ../a.txt └── run.sh

运行工具：

./dirstat --sort=name --filter='\.(txt|log)$' /tmp/demo

输出类似：

/tmp/demo/a.txt -rw-r--r-- user1 user1 2048 2025-01-12 10:32 /tmp/demo/sub/b.log -rw-r--r-- user1 user1 4096 2025-01-12 09:15

一个很明显的验证点是：link_to_a因为不匹配\.(txt|log)$被过滤掉——过滤逻辑只作用在entry->d_name上，不会递归判断目标路径的扩展名。如果你希望过滤的是“目标文件是txt则显示符号链接”，那就得在过滤前额外stat一次目标路径。这属于业务口径选择，这里提出来是让你意识到同样一个需求，不同实现路径会带来所有人都不容易察觉的行为差异，工具发布前最好把这类边界写进测试用例。

另外建议在验证阶段刻意造一些特殊文件：文件名带空格、文件名以-开头、空目录、无权限目录（chmod 000）。我上一版工具就在“无权限目录”上crash了，因为我只处理了opendir失败，没处理lstat偶尔因目录权限竞态失败的情况。

代码里我特意在每条perror后加continue而不是直接退出，就是为了保证单个文件出错不影响整个遍历。这个“单点失败不中断”的设计原则，在批量工具里比“遇到错误立刻终止”要有用得多。

6. 常见问题速查与排查技巧

6.1 问题对照表

6.2 排查思路：先看errno，再看系统调用

遇到系统调用失败，不要急着printf大法。第一件事是打印errno和strerror(errno)，很多时候一句话就把问题点出来了。比如opendir失败返回EACCES，你直接就知道是权限问题；返回EMFILE，是进程文件描述符数耗尽；返回ENOTDIR，是路径中间某个组件不是目录。

如果需要进一步追踪内核层面发生了什么，strace是神器。假设你的工具递归遍历某目录时报Too many open files，但代码里明明每次opendir后都closedir了，这时候strace一拉就能看见到底有没有成对调用、哪个文件描述符没有关闭：

strace -f -e trace=openat,close ./dirstat /tmp/demo 2>&1 | tail -100

6.3 我总结的三个关键经验

第一，目录遍历和文件操作是两个阶段，要尽量分开。第一阶段把所有要处理的条目路径收集到内存，第二阶段再去做重活。这样既减少了目录流在长时间多步操作中被外部变更干扰的概率，也让代码逻辑天然分成“收集”和“处理”两块，测试起来方便很多。我也踩过“边遍历边删除”、“边遍历边重命名”导致后续条目找不到的坑。

第二，几乎所有权限相关bug，都出在“我以为我是xxx用户”这个假设上。运行环境可能有setuid位、可能有sudo、可能有容器映射，不要相信直觉，程序里通过getuid/geteuid/getgroups实际确认当前身份是哪个档位，再按档位决定能不能对文件做操作。

第三，能显示数字就不要伪造名字。我在一个工具里对无法解析的uid输出unknown(1004)，这在日志排查时非常有价值。你一眼看到unknown(1004)就知道是uid 1004缺条目；如果只输出一个unknown，除了怀疑人生没有任何信息量。

最后说一句我自己的体会：Linux系统编程里目录和用户这块，API本身不多，一天就能过完，但真的用好它们，靠的全是边界情况的处理——符号链接、并发删除、uid缺失、线程安全、静态内存覆盖。你把这些坑都填平了，写出来的工具才会又稳又准，而不是“看起来能跑，一上生产就出事”。把这个小工具实现一遍、跑一遍、故意制造几个坏环境再排查一遍，比我在这里写一万字总结都管用。