go中flock与fcntl锁本质不同：前者基于inode、内核级，后者基于fd、进程级；标准库lock跨平台行为不一致，且为建议性锁，需所有参与者主动调用才生效。
Go 里 flock 和 fcntl 锁不是一回事
Go 标准库没有直接暴露 flock（Linux/BSD 的 advisory file lock）或 fcntl（POSIX record lock），os.File 的 Lock 方法在不同系统底层调用不同：Linux/macOS 用 fcntl，Windows 用 LockFileEx。这意味着跨平台行为不一致——比如 fcntl 锁是进程级、基于文件描述符的，而 flock 是内核级、基于 inode 的，父子进程继承方式也不同。
常见错误现象：os.OpenFile 后反复调用 file.Lock() 不报错，但另一个进程仍能写入；或子进程意外持有锁导致父进程退出后锁未释放。
- 只对已打开的
*os.File调用Lock/Unlock，不能对路径字符串操作 - 锁是 advisory（建议性）的，不强制拦截读写，所有参与者必须主动调用才能生效
- Windows 下不支持共享锁（
LOCK_SH），只支持独占锁（LOCK_EX） - 避免在 goroutine 中长期持锁，尤其不要在锁内做网络/IO 等阻塞操作
os.File.Lock 的三种典型用法和参数陷阱
Go 的 Lock 方法接受一个 syscall.LOCK_EX 或 syscall.LOCK_SH 常量，但注意：它不支持 LOCK_NB（非阻塞）直接传参，必须手动设置 syscall.LOCK_EX | syscall.LOCK_NB 才能实现超时/失败立即返回。
使用场景：配置热重载、单实例守护进程、日志轮转协调。
立即学习“go语言免费学习笔记（深入）”；
-
file.Lock(syscall.LOCK_EX)：阻塞直到获取独占锁，适合写入前强互斥 -
file.Lock(syscall.LOCK_SH)：仅 Linux/macOS 支持，多个进程可同时持有，适合只读场景协同（如缓存预热检查） -
file.Lock(syscall.LOCK_EX | syscall.LOCK_NB)：失败立即返回syscall.EWOULDBLOCK，必须显式判断错误，不能忽略 - 锁粒度是整个文件，无法锁定某段偏移 —— 想做 record-level 控制得自己加内存/Redis 分布式锁
为什么 defer file.Unlock() 经常失效
看似稳妥的 defer 在 panic、os.Exit、或 goroutine 被强行终止时不会执行，导致锁残留。更隐蔽的是：如果文件被 os.OpenFile 多次打开（即使路径相同），每个 *os.File 是独立 fd，锁互不影响 —— 你以为 unlock 了，其实只是关掉了其中一个句柄。
常见错误现象：程序重启后提示“资源忙”，lsof -i | grep yourfile 发现旧进程残留锁；或并发启动多个实例，都声称自己拿到了锁。
- 务必在
Unlock后紧跟file.Close()，否则锁可能延迟释放（尤其在 fork 子进程后） - 避免在主 goroutine 外起 goroutine 持锁，
defer对其他 goroutine 无效 - 生产环境建议加锁失败时记录 pid 和 stack trace，方便排查谁持有锁
- 测试时用
syscall.Flock(int(file.Fd()), syscall.LOCK_EX|syscall.LOCK_NB)直接调系统调用验证锁状态
替代方案：什么时候不该用文件锁
文件锁解决不了分布式场景，也扛不住 NFS 这类不完全兼容 POSIX 锁的文件系统（flock 在 NFSv3 上基本失效，fcntl 行为不可靠）。如果你的应用跑在容器或 Kubernetes 里，同一文件被多个 Pod 挂载，文件锁完全不起作用。
性能影响：每次锁操作触发一次系统调用，高并发下成为瓶颈；且锁状态无法跨机器同步。
- 单机多进程协调 → 可用
os.File.Lock，但需配合pidfile做兜底 - 同一进程内 goroutine 协调 → 用
sync.Mutex或sync.RWMutex，别绕路文件系统 - 跨节点或容器部署 → 改用 Redis 的
SET key value NX PX 30000或 Etcd 的 lease 机制 - 日志写入冲突 → 直接用
lumberjack这类支持原子 rotate 的库，别自己锁文件
真正难的从来不是“怎么加锁”，而是“谁该负责释放”和“锁失效时怎么降级”。文件锁在 Go 里容易写，但线上出问题时最难查的，往往是那个没 Close 的 *os.File。
