filesystemwatcher 初始化后无反应，首要检查 enableraisingevents 是否设为 true；path 必须是本地绝对路径且真实存在，建议用 directory.getfullpath() 标准化；includesubdirectories 默认 false，需显式启用；unc 路径应改用轮询。
FileSystemWatcher 初始化后没反应？检查这几个关键属性
最常见的原因是 EnableRaisingEvents 默认为 false，不手动设为 true 就完全不会监听。另外，Path 必须是本地绝对路径（不能是 UNC 或相对路径），且目录必须真实存在——哪怕只是多一个尾部斜杠（如 "C:\Temp\"）都可能因权限或路径解析失败静默失效。
-
Path要用Directory.GetFullPath()标准化，避免空格、特殊字符或符号链接干扰 -
IncludeSubdirectories默认false，要监控子文件夹必须显式设为true - 如果目标是网络共享路径，改用轮询方案（
FileSystemWatcher对 UNC 支持极差，容易丢事件）
为什么 Created/Changed 事件会触发多次？
Windows 文件系统在保存文件时往往分多步：先创建临时文件 → 写入内容 → 重命名覆盖原文件。这会导致 Created、Changed、Renamed 多个事件连发；文本编辑器（如 VS Code）还可能触发额外的 Changed（写入 .swp 或备份文件）。直接在事件处理器里执行耗时操作（比如解析大文件）会阻塞后续事件队列，甚至引发 Error 事件。
- 用
NotifyFilter精简监听粒度，例如只关注NotifyFilters.LastWrite | NotifyFilters.FileName - 对同一文件路径做简单去重：缓存最近 500ms 内处理过的
FullPath，重复则跳过 - 事件回调里别直接 IO 或解析，用
Task.Run()拆离，但注意别无节制创建 Task 导致线程池饥饿
如何安全地读取刚写完的文件？
事件到达时文件可能还没真正写完（尤其大文件或杀毒软件介入时），直接 File.OpenRead() 会抛 IOException: The process cannot access the file。这不是 FileSystemWatcher 的 bug，而是 Windows 文件锁机制导致的竞态。
- 不要依赖事件里的
EventArgs.Name就立刻打开，先拼出完整路径：Path.Combine(watcher.Path, e.Name) - 加简单重试逻辑：最多 3 次，每次间隔 100ms，用
FileStream的FileShare.Read尝试打开 - 更稳的做法是监听
Changed后等待LastWriteTime稳定（两次读取间隔 > 200ms 且值不变）再处理
跨线程访问 UI 控件报错？别在事件里直接更新 TextBox
FileSystemWatcher 的事件是在后台线程触发的，WPF/WinForms 的控件不是线程安全的。直接调用 textBox.AppendText() 会崩，错误信息是 InvalidOperationException: The calling thread cannot access this object because a different thread owns it。
- WinForms：用
this.Invoke((MethodInvoker)delegate { textBox.AppendText(...); }) - WPF：用
Dispatcher.Invoke(() => textBox.AppendText(...)) - 或者彻底规避 UI 交互——把日志写进
ConcurrentQueue<string></string>，另起定时器（Timer）定期刷到界面
