go中flock文件锁常失效，因标准库无跨进程封装，误用chmod或临时文件模拟致竞态；可靠方案是调用系统flock(2)，linux/macos用golang.org/x/sys/unix.flock，windows用windows.lockfileex，且需注意fd打开模式、锁释放时机及fsync保障持久性。
Go 中用 flock 实现文件锁为什么经常失效？
因为 Go 标准库不直接提供跨进程的 flock 封装，很多开发者误用 os.File.Chmod 或临时文件“模拟”锁，结果在并发写入时出现竞态。真正可靠的方案是调用系统 flock(2) 系统调用，需借助 golang.org/x/sys/unix（Linux/macOS）或 golang.org/x/sys/windows（Windows）。
常见错误现象：syscall.EBADF（文件描述符未设置为阻塞）、syscall.EAGAIN（非阻塞模式下锁被占用但没处理重试）、锁在 goroutine panic 后未释放导致死锁。
- Linux/macOS 下必须用
unix.Flock(fd, unix.LOCK_EX)，且fd需来自os.OpenFile(..., os.O_RDWR, 0)（只读打开无法加写锁） - Windows 不支持
flock，得用windows.LockFileEx+windows.INFINITE，行为和语义与 Unix 不同，不可混用 - 加锁后务必用
defer unix.Flock(fd, unix.LOCK_UN)，但要注意：如果函数提前 return 或 panic，需确保fd仍有效（不能在 defer 前 close）
用 fsnotify 监听文件变化时要不要加文件锁？
不需要，而且加了反而有害。fsnotify 是事件驱动，监听的是文件系统级变更（如 IN_MODIFY），它本身不修改文件；而文件锁用于协调多个进程/线程对同一文件的读写冲突。两者解决的问题域不同。
容易踩的坑：fsnotify 收到事件后直接去读文件，却没考虑此时其他进程可能正往里写——这不是锁能解决的，而是需要应用层协议（如写完先 fsync 再 rename 到目标路径）。
立即学习“go语言免费学习笔记（深入）”；
- 典型安全做法：生产者写入临时文件
data.json.tmp→fsync→os.Rename覆盖原文件；消费者只读data.json，靠原子 rename 保证一致性 - 若硬要加锁，只能锁“正在被消费的文件”，但会阻塞通知事件响应，违背
fsnotify的轻量初衷 -
fsnotify在 Docker 容器中可能因 inotify 限制丢事件，这时锁也救不了——得加轮询兜底
os.Create 和 os.OpenFile 对文件锁的影响差异
os.Create 等价于 os.OpenFile(name, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0666)，关键在 os.O_TRUNC：它会在打开时清空文件内容，但这个截断操作发生在加锁之前。如果你先加锁再 Create，锁对象其实是旧文件 inode；而 Create 后得到的是新 inode，导致锁失效。
正确做法永远是：先用 os.OpenFile(..., os.O_RDWR, 0) 打开已有文件（不带 O_CREATE 或 O_TRUNC），再加锁；写入逻辑放在锁内，用 file.Truncate(0) + file.Write 替代 os.Create。
-
os.OpenFile(path, os.O_WRONLY|os.O_CREATE, 0644)无法加写锁：只写模式返回的 fd 不支持flock的LOCK_EX -
os.O_APPEND和锁共用时注意：内核保证 append 写入原子性，但锁只保你自己的读写顺序，不保其他进程的 append 行为 - 锁的粒度是整个文件，不是某段偏移——别指望用锁实现“行级并发写”
多个 goroutine 共享一个文件句柄加锁是否线程安全？
是，但仅限于“锁状态”本身线程安全；实际并发控制效果取决于你怎么用。Go 运行时保证对同一个 int 类型 fd 的 unix.Flock 调用不会崩溃，但不会自动序列化 goroutine 的执行顺序。
典型反模式：goroutine A 加锁 → B 也调用 Flock 阻塞 → A 写完并 unlock → B 立即拿到锁开始写 → 但 A 可能还没完成 fsync，B 读到脏数据。锁只管“谁有权限操作”，不管“操作是否落地”。
- 必须在
unlock前显式调用file.Sync()，尤其在要求强持久化的场景（如 WAL 日志） - 不要把锁变量（如
*os.File）在 goroutine 间传递后各自加锁——锁的是 fd，不是 Go 对象，传参无意义 - 如果只是防止多个 goroutine 同时写同一文件，用
sync.Mutex更轻量；flock的价值只在跨进程协调
fsync 忘了调，一次 rename 没做对，或者在容器里没配好 inotify limit，都比锁函数本身更常导致问题。 
