syscall.flock 在 linux/macos 上失败主因是文件未用 os.o_rdwr 或 os.o_wronly 打开，os.o_rdonly 不支持 lock_ex；需显式加 lock_nb 防阻塞，并区分 ebadf（fd 无效）、ewouldblock（锁被占）、einval（nfs 等不支持）；windows 无 flock 系统调用，应使用 go-flock 等跨平台库；sync.mutex 无法替代文件锁，因它仅作用于进程内内存；选 lobsterlock 或 go-flock 取决于是否需原子性、阻塞等待及 nfs 支持，关键注意锁路径绝对性、同文件系统及及时释放。
syscall.Flock 在 Linux/macOS 上为什么加不上锁
直接调用 syscall.Flock 失败，大概率是文件没用 os.O_RDWR 或 os.O_WRONLY 打开——os.O_RDONLY 无法申请 LOCK_EX，内核会返回 syscall.EBADF。这不是权限问题，是 POSIX 规范限制：写锁必须基于可写 fd。
- 必须用
os.OpenFile(path, os.O_RDWR, 0)，不能带os.O_CREATE或os.O_TRUNC，否则可能拿到新 inode，锁失效 -
LOCK_NB必须显式加上，否则 goroutine 会永久阻塞（syscall.Flock(fd, syscall.LOCK_EX)默认阻塞） - 错误判断要区分：
syscall.EWOULDBLOCK或syscall.EAGAIN是锁被占的正常情况；syscall.EBADF是 fd 问题；syscall.EINVAL常见于 NFS 或某些容器挂载路径不支持 flock
Windows 下 syscall.Flock 编译就报错怎么办
不是兼容性问题，是 Windows 根本没有 flock(2) 系统调用，syscall.Flock 在 Windows 上未定义，编译阶段就会失败。硬加 //go:build !windows 只能绕过编译，但掩盖了语义断裂——Linux 上靠 fd 绑定锁，Windows 上锁绑定的是路径+句柄，重命名或硬链接后行为完全不同。
- 别自己封装
windows.LockFileEx，容易漏掉OVERLAPPED初始化、超时设置、错误码映射等细节 - 直接用
github.com/go-flock/flock：它通过构建标签自动分发实现，对外统一提供flock.TryLock()和flock.Unlock() - 注意
flock库默认使用临时文件 +os.Rename原子提交，比原生LockFileEx更贴近 Unix 语义，且对 NFS 友好
为什么 sync.Mutex 加了还是写乱文件
sync.Mutex 完全无效——它只锁当前进程内的内存变量，另一个进程（哪怕只是 echo "x" >> config.json）完全不受影响。常见错误是：多个 Pod 同时写 ConfigMap 挂载的文件、crontab 脚本和 Go 程序并发改日志、K8s 重启后旧进程残留导致双写。
- 现象包括：
file.Truncate(0)被并发执行导致内容清空、os.WriteFile覆盖部分字节、读取时遇到EOF或乱码 - 根本原因：文件锁是内核资源，
sync.Mutex是用户态运行时资源，二者作用域不在同一层 - 真正需要进程间互斥时，必须用文件系统级原语：flock（Unix）、
LockFileEx（Windows）、或基于原子 rename 的方案
用 lobsterlock 还是 go-flock
两者都跨平台，但设计哲学不同：lobsterlock 基于临时文件 + os.Mkdir 原子性（类似 mkdir 的“创建即锁”语义），go-flock 封装系统原生锁并 fallback 到 rename。前者更轻、无系统调用依赖，后者更贴近传统锁语义、支持阻塞等待。
- 选
lobsterlock如果：部署环境受限（如某些嵌入式容器无完整 syscall 支持）、只需要简单互斥、锁持有时间极短 - 选
go-flock如果：需要兼容已有 flock 使用习惯、要求锁能响应 context.Context 超时、或需在 NFS 上稳定工作 - 共同陷阱：锁路径必须是绝对路径；锁文件和目标文件不能跨文件系统（
rename不原子）；锁对象没defer unlock就return，会导致死锁
defer f.Close() 再加锁，解锁前 fd 已关，锁就没了；而跨挂载点的相对路径，会让不同进程锁住不同文件。这些细节不写进代码注释，过三个月自己都得 debug 半天。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
