syscall.flock 在 linux/macos 上需用 os.o_create|os.o_rdwr 打开文件，再以 syscall.lock_ex|syscall.lock_nb 非阻塞加锁；锁绑定 fd 而非路径，进程退出自动释放，但显式解锁更清晰。
syscall.Flock 在 Linux/macOS 上怎么用才不阻塞又安全
Go 标准库没直接暴露 flock，得靠 syscall.Flock 手动调用，但它的行为和系统调用强绑定——不是跨平台的“锁文件”抽象，而是对底层 flock(2) 的直通。这意味着它只在支持 flock 的系统（Linux、macOS、FreeBSD）有效，Windows 完全不认。
常见错误是打开文件后立刻 syscall.Flock(fd, syscall.LOCK_EX)，结果程序卡死：因为默认是阻塞式加锁。实际中多数场景需要非阻塞尝试，比如后台任务轮询时不想等。
- 加锁前务必用
os.O_CREATE | os.O_RDWR打开文件，只读打开（os.O_RDONLY）在某些内核版本下可能无法获得写锁 - 非阻塞加锁必须用
syscall.LOCK_EX | syscall.LOCK_NB，否则会挂起整个 goroutine - 锁是与文件描述符（fd）绑定的，不是与文件路径。同一个文件用不同
os.OpenFile打开两次，得到两个独立 fd，互不影响锁状态 - 进程退出时内核自动释放锁，不用手动
syscall.Flock(fd, syscall.LOCK_UN)—— 但显式释放更清晰，尤其调试时
file, err := os.OpenFile("state.lock", os.O_CREATE|os.O_RDWR, 0644)
if err != nil {
log.Fatal(err)
}
defer file.Close()
err = syscall.Flock(int(file.Fd()), syscall.LOCK_EX|syscall.LOCK_NB)
if err != nil {
if err == syscall.EWOULDBLOCK {
log.Println("锁已被占用，跳过")
return
}
log.Fatal(err)
}
为什么不能用 os.Chmod 或 os.Rename 模拟文件锁
有人试过用 os.Create("lock.tmp") → os.Rename("lock.tmp", "lock") 做“原子占位”，这在单机上看似可行，但本质是竞态漏洞：rename 是原子的，但检查 + 创建 + 重命名是三步，中间可能被其他进程插入。而且它完全不解决“持有锁期间文件被并发修改”的问题。
更隐蔽的问题是 NFS：NFSv3 及更早版本根本不保证 rename 的跨节点原子性，A 机器 rename 成功，B 机器可能还看到旧文件；而 flock 在 NFS 上行为不可靠，但至少语义明确——它要么失败，要么真的锁住（取决于挂载选项）。
立即学习“go语言免费学习笔记（深入）”；
-
flock锁的是“打开的文件描述符”，不是文件路径。同一文件被多次 open，每个 fd 都可独立加锁（但通常不这么干） - 用
os.Chmod改权限模拟锁？权限变更不具原子性，且无法感知谁“持有”了锁 - 临时文件 + pid 写入？pid 可能已退出，没人清理，变成死锁假象
syscall.Flock 和 github.com/gofrs/flock 库的关键区别
github.com/gofrs/flock 是封装了 syscall.Flock 的常用逻辑，但它加了一层 Go 风格的 API 和跨平台兜底（Windows 下用 CreateFile 的共享模式模拟）。如果你只跑 Linux，自己调 syscall.Flock 更轻量；如果要同时支持 Windows，别硬刚 syscall，直接用这个库。
注意它默认也是阻塞的，想非阻塞得调 TryLock()，不是 Lock()。另外它内部把锁文件路径作为唯一标识，而原生 flock 不关心路径——所以用库时别传一个 symlink 路径，否则不同符号链接指向同一文件，会被当成不同锁。
- 库的
Unlock()必须显式调用，它不会随 file.Close() 自动释放 - 库内部用了
os.O_CREATE | os.O_RDWR打开锁文件，所以首次调用NewFlock()会创建文件，权限是 0644 - 自己封装
syscall.Flock时，记得 close fd 前 unlock，否则锁残留到进程结束
锁住的到底是什么：文件内容？文件元数据？还是别的
flock 锁的是“内核中的 inode + 进程 fd 组合”，它不阻止别人读写文件内容，也不阻止 chmod、chown 等元数据操作。它的作用纯粹是进程间协调：告诉其他也调用 flock 的进程“我现在正在用这个文件，请勿同时执行某段逻辑”。
典型误用是以为加了 flock 就能防止并发写入文件——其实不能。它不提供 I/O 同步，只是信号量。真要保护文件内容，得配合 os.WriteFile 前加锁、写完再解锁，且所有写入方都遵守同一把锁。
- 多个 goroutine 共享同一个
*os.File并发调flock是安全的，因为锁粒度在 fd 层 - 但若每个 goroutine 自己
os.OpenFile同一路径，就等于各自拿了一个新 fd，互相看不到对方的锁 - 锁不继承给子进程。fork 出的子进程不会自动持有父进程的 flock，除非显式 dup fd
flock 的代码起作用。任何绕过它的读写，它都管不了。真正难的不是调用函数，而是让所有相关代码路径都走同一套锁约定。 
