on_modified多次触发是因编辑器原子写入策略（如先写临时文件再替换），非watchdog缺陷；监控单文件必须设recursive=false，路径须用os.path.abspath()转绝对路径；临时文件过滤推荐patternmatchingeventhandler+ignore_patterns。
watchdog 能实时捕获文件变动，但默认行为和系统差异会导致「监听不到」「重复触发」「路径失效」等典型问题。直接用示例代码跑起来容易，稳定用好需要绕开几个关键坑。
为什么 on_modified 会连续触发多次？
Linux/macOS 下编辑器（如 VS Code、nano）保存文件时，常先写临时文件再原子替换，或清空原文件再重写内容——这会触发 FileModifiedEvent 多次，甚至夹杂 FileDeletedEvent 和 FileCreatedEvent。
- 不要只依赖
on_modified判断“内容变了”，它反映的是系统级操作，不是语义级修改 - 对关键文件，建议在
on_modified后加 100–500ms 延迟，再用os.path.getmtime()或文件哈希比对确认是否真有内容变更 - 若只需响应最终落盘结果，可监听
on_closed_write（需自定义inotify事件，watchdog 不直接暴露；更稳妥做法是监听on_moved+on_created组合，覆盖编辑器的原子写入模式）
监控单个文件时 recursive=False 还是 True？
必须设为 recursive=False。watchdog 的 observer.schedule() 接收的是「监控路径」，不是「目标文件」——如果你传入一个文件路径却设 recursive=True，Linux 下会静默失败，Windows 下可能报 WindowsError: [Error 3] The system cannot find the path specified。
- 监控文件：
observer.schedule(handler, path="/path/to/file.txt", recursive=False) - 监控目录：
observer.schedule(handler, path="/path/to/dir/", recursive=True) - 路径务必用
os.path.abspath()转成绝对路径，相对路径在 daemon 化或不同工作目录下极易失效
如何过滤掉 .swp、~、.tmp 等临时文件事件？
watchdog 本身不提供内置文件名过滤，靠继承 FileSystemEventHandler 并在各事件方法里手动判断是最直接的方式。
- 在
on_created、on_modified等方法开头加判断：if event.src_path.endswith((".swp", "~", ".tmp", ".part")): return - 避免用
os.path.basename(event.src_path).startswith(".")来过滤隐藏文件，因为 macOS 的.DS_Store或 Git 的.git目录变动也走DirModifiedEvent，需额外判断event.is_directory - 更彻底的方案是用
PatternMatchingEventHandler（来自watchdog.events），它支持ignore_patterns参数，例如：PatternMatchingEventHandler(ignore_patterns=["*.swp", "*~", ".DS_Store"])
程序退出时 observer.stop() 为何有时卡住？
主要发生在 observer 启动后、首次事件尚未到达前就调用 stop()，底层线程可能处于阻塞等待状态，导致 join() 长时间不返回。
- 确保
observer.start()后至少 sleep 0.1 秒再做测试性中断，或加timeout参数：observer.join(timeout=2) - 生产环境建议用
atexit.register(observer.stop)替代裸 try/except KeyboardInterrupt，避免信号处理遗漏 - 如果使用 systemd 或 Docker，注意 SIGTERM 可能无法触发 KeyboardInterrupt，需显式监听
signal.SIGTERM并调用observer.stop()
watchdog 的职责里，得你亲手补上。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
