watchdog启动后无反应需检查事件处理器注册和事件循环阻塞必须显式注册处理器并用join()或sleep()维持主线程on_modified可能因编辑器保存机制触发多次建议去重或监听on_closed_write。watchdog 启动后没反应检查事件处理器注册和事件循环是否阻塞watchdog 不是“启动就自动打印所有变化”的黑盒它需要你显式注册事件处理器并且必须保持主程序运行不能启动完就退出。常见错误是写了 Observer 实例、调用了 start()但没加 time.sleep() 或没接 join()导致主线程立刻结束后台监听直接终止。必须用 observer.join() 阻塞主线程或在循环中用 time.sleep(1) 维持进程存活事件处理器如继承 FileSystemEventHandler 的类要重写具体方法on_created、on_modified 等不是只写 on_any_event 就万事大吉如果用在 Flask/FastAPI 后台里别把 observer.start() 放在路由函数内——每次请求都新建 observer资源泄漏且无法持续监听on_modified 触发两次这是编辑器保存机制导致的正常现象多数现代编辑器VS Code、Sublime、PyCharm保存文件时会先写临时文件再原子替换或启用备份/swap 文件策略结果触发多次 on_modified 甚至 on_deleted on_created。这不是 watchdog bug而是文件系统真实行为。不要依赖单次 on_modified 做关键业务比如立即解析日志加简单去重缓存最近 1 秒内处理过的 event.src_path优先监听 on_closed_write需用 PollingObserver 或 Linux 下 inotify inotify 库它更接近“真正写完”时刻Windows 上默认用 ReadDirectoryChangesW对某些编辑器行为更稳定macOS 则依赖 FSEvents本身就有合并通知机制监控子目录不生效注意 recursive 参数和路径权限observer.schedule(handler, path, recursiveTrue) 中的 recursive 控制是否监听子目录但很多人忽略两点一是路径末尾斜杠影响实际匹配尤其符号链接场景二是当前用户对目标路径是否有读取执行x权限——缺任一权限子目录根本不会被纳入监听范围。用 os.path.abspath(path) 规范路径避免相对路径引发的层级误判Linux/macOS 下执行 ls -ld /target/dir 确认当前用户有 r-x 权限Windows 下检查文件夹“安全”选项卡中用户是否具备“列出文件夹内容”和“读取”权限若监控网络挂载点如 NFS、SambarecursiveTrue 可能失效或极不稳定改用 PollingObserver 更可靠watchdog 在 Docker 容器里监听不到变化宿主机文件系统事件不透传Docker 默认不会把宿主机 inotify 事件转发进容器尤其是挂载 hostPath 或 bind mount 时容器内看到的是静态快照inotify 监听器收不到任何信号。这不是 Python 或 watchdog 的问题是容器隔离机制决定的。 arXiv Xplorer ArXiv 语义搜索引擎帮您快速轻松的查找保存和下载arXiv文章。