inotifywait不能直接后台长期运行，因其默认单次监听后退出；需用--monitor参数或带进程检查的循环，配合精确事件过滤（如close_write、move_to）和文件就绪校验，才能可靠触发脚本。
Linux下用 inotifywait 监控文件变动并触发脚本，不是“配好就能跑”，关键在事件过滤、进程守活和信号安全——漏掉任一环节，脚本大概率漏执行或重复执行。
为什么 inotifywait 不能直接放后台长期运行
inotifywait 默认只监听一次事件就退出。想持续监控，必须用循环包裹；但裸写 while true 容易因脚本异常退出导致整个监控中断。
- 用
--monitor参数替代循环更可靠，它原生支持长时监听，且对SIGHUP/SIGINT有合理响应 - 若必须用循环（比如要加延迟重试），务必在每次迭代开头检查上一轮脚本是否还在运行，避免堆积僵尸子进程：
pgrep -f "your_script.sh" > /dev/null || your_script.sh & - 不要把
inotifywait放到&后台直接跑——它依赖终端 stdin/stdout，断开后可能卡住或静默失败
inotifywait 的事件过滤必须精确到具体动作
监控 modify 会捕获所有内容变更，但编辑器保存时常先写临时文件再 mv 替换，此时真正需要响应的是 move_to 或 attrib（改权限/时间戳）。
- 常用组合：
-m -e close_write,move_to,create,delete—— 覆盖写入完成、文件落地、新建、删除四类关键动作 - 避开
modify：它在 vim/swift 编辑时高频触发，且无法区分是用户保存还是编辑器自动写 swap 文件 - 加
--excludei '\.sw[px]$|~$'过滤 vim/emacs 临时文件，否则每敲一个字都可能触发一次脚本
脚本内访问被监控文件前，必须确认文件已就绪
收到 move_to 事件时，文件可能还在从 tmp 目录 mv 过程中，直接 cat 或解析会读到空或不完整内容。
- 简单方案：收到事件后
sleep 0.1再操作（适用于低频场景） - 稳健方案：用
stat -c '%Y' "$file"检查修改时间是否稳定（连续两次差值 - 绝对避免：在事件回调里直接调用耗时操作（如 git commit、docker build），应转为异步队列或加锁防止并发冲突
systemd 服务化时，inotifywait 的路径和权限容易失效
systemd 服务默认工作目录是 /，且无用户环境变量，inotifywait 报 “No such file or directory” 很可能是路径没写绝对路径。
- 配置文件中所有路径必须用绝对路径：
/home/user/project，不能用~/project或./config - 指定用户运行：
User=alice，并确保该用户对监控目录有r权限（inotify需要读取目录 inode） - 加
Restart=on-failure和RestartSec=5，但注意：如果脚本本身崩溃导致inotifywait退出，systemd 只会重启命令，不会恢复未处理完的事件队列
真正难的不是监听到变化，而是判断“此刻文件状态是否可信”“本次事件是否值得响应”“下次事件会不会被这次阻塞”——这些边界条件，得靠日志打点+小流量验证才能摸清。
