多线程C程序文件系统操作：选ftw()还是fts_open()？

嘿，这个问题问到点子上了——多线程环境下做文件系统遍历，ftw() 确实是个容易踩的坑，我来给你掰扯清楚：

原因很直接：

• fts 系列就是为递归遍历目录树量身打造的，它用结构体保存每个遍历任务的独立状态，完全不依赖全局变量，天生支持多线程（只要每个线程用自己的fts句柄就行），设计上比ftw优雅太多。
• scandir() 只能搞定单个目录的遍历，如果要递归扫整个目录树，你得自己写递归逻辑，还要手动处理每个目录的状态同步，多线程下只会徒增复杂度，远不如fts省心。

这得分两部分说，都是ftw()设计上的硬伤：

1. 多线程调用本身就会炸：全局状态的致命缺陷 #

ftw() 内部用全局变量存储遍历的上下文（比如当前遍历深度、已访问的节点、回调函数的参数等）。当多个线程同时调用ftw()时，这些全局变量会被并发覆盖：

• 比如线程A正在遍历/data/logs，线程B突然启动ftw()遍历/tmp/cache，线程B的操作会把全局状态改成自己的遍历上下文，线程A的遍历会直接“跑偏”——可能突然跳到/tmp的路径，或者因为状态混乱直接崩溃。
• 更糟的是，POSIX标准根本没规定ftw()是线程安全的，这不是实现问题，是设计上的先天不足。

2. 并发文件操作（删除/移动）会触发未定义行为 #

就算是单线程用ftw()，如果有其他线程（或进程）同时修改文件系统，也会出大问题：

• ftw() 会提前缓存目录的结构信息，当某个文件/目录被删除或移动后，ftw() 还是会按照缓存的路径去访问，结果就是触发ENOENT（文件不存在）错误，甚至因为访问了已经释放的资源导致程序崩溃。
• 关键是ftw()没有提供任何机制来处理这种动态变化——它默认假设遍历期间文件系统是静态的。而fts系列可以通过fts_set()调整策略，比如遇到不存在的文件时跳过、重新读取目录内容，适应性强得多。

内容的提问来源于stack exchange，提问作者 Étale-cohomology