FileSystemWatcher 默认不响应文件夹重命名，仅响应文件重命名；需将Path设为父目录、Filter设为空或目标名、IncludeSubdirectories=false，并通过Directory.Exists验证新旧路径是否均为目录来准确识别文件夹重命名。
用 FileSystemWatcher 监控文件夹重命名，但默认不触发
直接结论：filesystemwatcher 默认监听 rename 事件时，**只对文件重命名响应，不对文件夹重命名响应**——这是最常被踩的坑。它底层依赖 windows api 的 readdirectorychangesw，而该 api 对目录重命名的报告行为受监视路径层级影响。
实操建议：
- 必须将
Path设置为被监控目录的**父级路径**（例如想监控C: est older是否被重命名，Path应设为C: est） -
Filter设为空字符串（""）或精确匹配目标文件夹名（如"folder"），否则可能错过事件 - 启用
IncludeSubdirectories = false，避免子目录变动干扰判断 - 收到
Renamed事件后，检查e.OldName和e.Name是否都为目录（通过Directory.Exists(Path.Combine(watcher.Path, e.OldName))等辅助判断）
Renamed 事件里怎么区分是文件改名还是文件夹改名？
事件参数 RenamedEventArgs 不带类型标识，得自己推断。关键不是猜，而是验证路径是否存在且为目录。
实操建议：
- 不要只看
e.OldName或e.Name的扩展名——文件夹没有扩展名，但名字也可能不带点 - 用
Directory.Exists(Path.Combine(watcher.Path, e.OldName))判断旧路径是否曾是目录 - 同理用
Directory.Exists(Path.Combine(watcher.Path, e.Name))判断新路径是否已是目录 - 两者都为
true，基本可确定是文件夹重命名；若仅一个为true，可能是移动操作（需结合ChangeType和前后路径进一步过滤）
为什么有时重命名没捕获到？常见漏报原因
漏报不是 bug，是 FileSystemWatcher 的设计约束和系统行为叠加的结果。
实操建议：
- 监控路径不能是网络驱动器映射路径（如
Z:），必须用 UNC 路径（如\servershare）才稳定 - 如果目标文件夹在重命名瞬间被其他进程独占（如资源管理器正打开其属性页），事件可能丢弃——这是 Windows 内核级限制，无法绕过
-
InternalBufferSize太小（默认 8KB）会导致高频率重命名时缓冲区溢出，建议设为64 * 1024 - 确保事件处理逻辑轻量，避免在
Renamed回调里做耗时 I/O（如递归扫描），否则会阻塞后续事件队列
替代方案：轮询检测比监听更可靠？
当业务要求 100% 不漏（比如审计场景），纯 FileSystemWatcher 就不够用了。轮询不是退化，而是补位。
实操建议：
- 用
Directory.GetDirectories(parentPath)定期（如每 2 秒）获取当前子目录列表，与上一次快照比对增删 - 记录每个目录的
CreationTimeUtc和LastWriteTimeUtc，重命名通常不改变这两个时间戳，但新建+删除会——可辅助排除误判 - 轮询 + 监听双路并行：监听用于低延迟响应，轮询用于兜底校验，两者用同一份缓存状态（如
ConcurrentDictionary<string, DateTime>）同步 - 注意轮询频率和磁盘压力平衡，SSD 可稍激进，机械盘建议 ≥5 秒间隔
事情说清了就结束。真正难的不是写监听逻辑，而是接受「Windows 对目录元操作的可见性天生不完整」这个前提——所有方案都是在妥协中找平衡点。
