flock 是最稳妥、零依赖的单实例方案，必须用 -c 包裹整个命令，如 /5 * flock -xn /tmp/backup.lock -c '/usr/bin/python /opt/backup.py'，直接锁脚本或分步执行均无效。
flock 是最稳妥、零依赖的单实例方案，但必须用对方式——直接对脚本本身加锁会失败，用 flock -n 包裹整个命令是 crontab 场景下的黄金写法。
crontab 里怎么写才不撞车
最常见错误是把 flock 当成“启动前检查”，实际它必须包裹要执行的命令，否则锁一释放就进来了。
-
*/5 * * * * flock -xn /tmp/backup.lock -c '/usr/bin/python /opt/backup.py'✅ 正确：锁住整个命令生命周期 -
*/5 * * * * /usr/bin/python /opt/backup.py❌ 错误：没锁，全靠运气 -
*/5 * * * * flock -xn /tmp/backup.lock && /usr/bin/python /opt/backup.py❌ 错误：&&分两步，锁在python启动前就释放了
注意：-c 后面的命令会被 shell 解释执行，所以路径、重定向、环境变量都要写全；/tmp/ 下的锁文件需确保所有用户可写（或改用 /var/lock/）。
脚本内部加锁更灵活，但 fd 分配别硬编码
适合长脚本中只有一段需要互斥（比如写日志、更新配置），其余部分可并发。
- 用
exec {fd}>/tmp/myapp.lock让 bash 自动分配未用 fd，比写死exec 9>/tmp/myapp.lock更安全，避免和脚本里其他重定向冲突 - 加锁后必须用
flock -n "$fd"检查返回值，不能只靠if判断语句块是否执行——flock失败时退出码是 1，不捕获就当成功了 - 锁住的代码块结束后，显式
exec "$fd">&-关闭 fd，锁立刻释放；不关也行，但脚本退出前这段逻辑不能被exit跳过
示例关键片段：
exec {lock_fd}>"/tmp/myapp.lock"
if ! flock -n "$lock_fd"; then
echo "another instance running" >&2
exit 1
fi
# ... 互斥区代码
exec "$lock_fd">&-
为什么直接 flock -x /path/to/script.sh 常常失效
不是 flock 不工作，而是你锁的对象错了。
- 脚本文件本身通常只有读权限（
chmod a-w很常见），flock -x需要写权限才能打开文件描述符，直接报Permission denied - 即使有写权限，多个进程以只读方式打开同一脚本文件，
flock无法阻止——锁的是 fd，不是路径，而只读打开不会触发锁检查 - 正确做法：用独立锁文件（如
/var/lock/myapp.lock），它只需存在且可写，内容为空也完全 OK
锁文件路径必须绝对路径、所有调用方一致；相对路径在 crontab 或 systemd service 里工作目录不确定，极易失效。
非阻塞 -n 和超时 -w 怎么选
核心看场景是否允许“等”。
- crontab 定时任务一律用
-n：任务堆积毫无意义，跳过本次比卡住更安全 - 手动触发的关键流程（如部署脚本）可用
-w 30：给正在运行的实例一点收尾时间，30 秒后强制放弃，避免无限等待 -
-w的秒数单位是整数，不支持小数；超时后flock进程退出，不会 kill 已启动的子命令——这点容易误判
真正容易被忽略的是：锁文件本身不需要初始化，flock 第一次用时自动创建；但如果你用 touch /var/lock/myapp.lock 预创建，记得设好权限（chmod 644 或所属用户可写），否则普通用户拿不到锁。
