watchdog默认不卡主线程，因其Observer运行在独立线程；但事件回调同步执行，耗时操作需剥离至线程池或asyncio处理，避免积压事件。
watchdog 默认是同步阻塞的，怎么让它不卡住主线程？
watchdog 的 Observer 默认运行在独立线程里，但它的事件回调（on_created、on_modified 等）仍是同步执行的——如果你在回调里写耗时操作（比如读大文件、发 HTTP 请求），主线程不会卡，但事件队列会积压，后续事件可能被丢弃或延迟触发。
真正要“异步”，得把耗时逻辑从回调中剥离出去，交给 asyncio 或线程池处理：
- 用
asyncio.to_thread()（Python 3.9+）包裹阻塞调用，再await它 - 或用
concurrent.futures.ThreadPoolExecutor提交任务，避免阻塞事件循环 - 切记：不能直接在回调里
await协程函数——watchdog 不支持原生 async 回调
如何让 watchdog 与 asyncio 事件循环共存？
watchdog 的 Observer 启动后会自己管理线程，和 asyncio 无直接关系。想把它“接入”异步流程，关键不是改造 watchdog，而是控制它的生命周期和事件分发方式：
- 启动
Observer前，确保 asyncio 事件循环已运行（比如用asyncio.run()包裹主逻辑） - 在回调中用
asyncio.create_task()触发真正的异步处理，例如：asyncio.create_task(handle_file_change(path)) - 停用时调用
observer.stop()并observer.join()，否则线程可能残留 - 注意：
observer.join()是阻塞调用，若在协程里直接调用会挂起整个 event loop，应放在loop.run_in_executor()中
为什么 on_modified 会连续触发多次？怎么去重？
编辑器保存文件时（如 VS Code、PyCharm），常先写临时文件再原子替换，或触发多次写入（如 .pyc 生成、IDE 备份）。watchdog 会为每个底层 fs 事件单独回调，导致同一逻辑文件被反复通知。
实用去重策略：
- 对
event.src_path做路径标准化（os.path.abspath()+os.path.normpath()） - 加时间窗口去重：100ms 内相同路径的事件只处理最后一次（用字典记录
{path: timestamp}，每次回调先查再更新） - 过滤掉临时文件：跳过以
.开头、或含~、.swp、.tmp后缀的路径 - 避免监听
__pycache__或.git目录——用IgnoredPatterns或自定义FileSystemEventHandler的dispatch()方法拦截
Windows 上监控符号链接失败？
watchdog 在 Windows 下默认不跟随符号链接（symlink），即使你用 mklink 创建了目录软链，Observer 也只监控原始路径，不会自动映射到链接目标。
解决办法只有两个：
- 显式将符号链接的目标路径加入监控（而不是链接本身）
- 改用
win32file+ReadDirectoryChangesW手动实现（复杂且非跨平台）
Linux/macOS 下 symlink 默认可正常监控，但要注意：如果链接指向的路径权限不足，watchdog 会静默失败，不报错也不触发事件——建议启动前用 os.access(target_path, os.R_OK) 主动校验。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
