watchdog的on_modified反复触发是因编辑器采用“写临时文件+原子重命名”机制，导致同一文件多次通知；应去重、优先监听on_moved_to/on_created，并延迟读取确保内容写完。
Watchdog 能实时监听文件系统事件，但默认不处理“内容修改后立即备份”这种需求——它只通知发生了什么，具体怎么响应、是否需要去重、是否要等写入完成，全得你自己控制。
为什么 FileSystemEventHandler 的 on_modified 会反复触发？
Linux/macOS 下编辑器（如 VS Code、nano）常通过“写临时文件 + 原子重命名”保存，导致同一文件触发多次 on_modified；Windows 上则可能因杀毒软件扫描、缩略图生成等产生干扰事件。
- 不要直接在
on_modified里调用备份逻辑，优先用on_moved或on_created更可靠 - 对同一路径加时间窗口去重：记录最近 1 秒内是否已处理过该路径，跳过重复事件
- 检查
event.is_directory == False，避免误处理文件夹事件 - 若必须响应
on_modified，建议配合os.path.getmtime()对比前后时间戳，确认真实内容变更
如何确保备份时源文件已写完？
很多程序（尤其是文本编辑器或下载工具）会在文件关闭前就发出 on_modified，此时读取可能得到截断或乱码内容。
- 简单做法：收到事件后延迟 100–500ms 再读取，用
time.sleep(0.3)+os.path.exists()+os.path.getsize()双重确认 - 更稳妥做法：用
inotifywait -m -e moved_to,create --format '%w%f' /path（Linux）做前置过滤，只转发稳定事件给 Python - 绝对不能依赖
event.src_path立即打开读取——它可能正被其他进程独占写入
Observer 启动后没反应？常见配置陷阱
Watchdog 默认使用 AutoPlatformObserver，但在 Docker 容器、WSL 或某些 NFS 挂载点下会静默降级为轮询模式（PollingObserver），性能差且可能漏事件。
- 启动前显式指定观察器：
observer = Observer(timeout=1.0)（Linux 推荐InotifyObserver） - 检查日志：
import logging; logging.basicConfig(level=logging.INFO)，看是否打印Emitter started或警告inotify limit reached - Docker 中需挂载
/dev/inotify并增加内核参数：sysctl fs.inotify.max_user_watches=524288 - 路径必须是绝对路径，
./data这类相对路径在守护进程中容易失效
真正难的不是监听到变化，而是判断“这个变化是否值得备份”——比如 .tmp 文件、.swp 交换文件、编辑器自动保存的隐藏副本。这些得靠文件名过滤、扩展名白名单或 stat 时间戳交叉验证，Watchdog 本身不提供业务语义。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
