flock不会触发go runtime死锁panic，因为它是系统调用级阻塞，由内核接管等待，runtime无法感知；真正触发deadlock panic的仅限chan、mutex等goroutine间同步原语。
为什么用 flock 不会触发 Go runtime 死锁 panic
Go 的 fatal error: all goroutines are asleep - deadlock! 只检测 goroutine 间同步原语（如 chan、sync.Mutex）的循环等待，而 flock 是系统调用级的阻塞，内核接管等待逻辑，Go runtime 完全感知不到。所以即使你写 unix.Flock(fd, unix.LOCK_EX) 卡住，程序不会 panic，只是挂起——这看似“安全”，实则是更危险的假象。
- 它掩盖了资源争用问题，线上可能表现为进程长时间无响应，而非快速失败
- 若业务逻辑依赖该锁后继续执行，卡住会导致整个流程停滞，比如部署脚本 hang 在锁上，后续 reload systemd 失败
- 没有超时机制时，一个崩溃未清理锁的旧进程，可能让新进程无限期等待
LOCK_NB 是唯一靠谱的非阻塞姿势
别信“加个 defer 就万事大吉”。unix.Flock(fd, unix.LOCK_EX) 默认阻塞，一旦被占用就卡死；必须显式加 unix.LOCK_NB 才能立即返回错误，把控制权交还给业务层做决策。
- 错误写法：
unix.Flock(fd, unix.LOCK_EX)—— 进程卡住，监控看不到 panic，运维只能 kill -9 - 正确写法：
unix.Flock(fd, unix.LOCK_EX|unix.LOCK_NB)，检查是否返回unix.EWOULDBLOCK - Windows 下对应的是
windows.LockFileEx的LOCKFILE_FAIL_IMMEDIATELY标志，不是加个timeout参数 - 注意：
os.O_RDONLY+LOCK_EX在 Linux/macOS 会直接报syscall.EBADF，必须用os.O_RDWR或os.O_WRONLY
第三方库 github.com/gofrs/flock 真正解决的不是“加锁”，而是“锁失效场景”
手写 flock 很容易漏掉边界情况，而 gofrs/flock 封装的重点恰恰是那些让你半夜被叫醒的问题：
- 进程被
SIGKILL强杀时，fd 来不及 close，锁残留 —— 它内部用临时文件 +os.Remove做兜底清理 - 在 NFS 或某些容器挂载卷上，
flock行为不一致 —— 它会 fallback 到open(O_EXCL)重试机制 - 锁文件路径和业务文件路径混用 —— 它强制要求独立锁路径（如
"data.json.lock"），避免重命名导致的锁错位 - 没提供超时参数？它支持
TryLockContext(ctx)，可配合context.WithTimeout实现秒级放弃
跨平台代码里最容易忽略的“锁释放时机”
Linux 上 flock 随 fd 关闭自动释放，但 Windows 的 LockFileEx 不会。如果封装成统一接口，必须区分释放逻辑：
- Unix：先
unix.Flock(fd, unix.LOCK_UN)，再file.Close()；顺序反了可能导致 unlock 失败（fd 已无效） - Windows：必须显式调
windows.UnlockFileEx，且不能依赖Close—— 否则锁一直挂着，其他进程永远拿不到 - 更隐蔽的坑：用
os.Create打开文件再flock，如果文件刚被另一个进程 truncate，你拿到的可能是新 inode，锁绑定失效 - 结论：不要自己拼
syscall，哪怕只跑 Linux，也用gofrs/flock—— 它的Unlock()方法已按平台做了适配
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
