Go中实现多进程文件安全访问需用操作系统级建议锁，推荐gofrs/flock库跨平台封装flock(2)/LockFileEx；锁作用于专用锁文件而非业务文件，依赖所有进程主动协作，TryLock()配合超时更安全。
在 Go 中实现多进程文件安全访问，核心是使用操作系统级的文件锁（advisory lock），而非语言内置的互斥机制。Go 标准库不直接提供跨进程文件锁，但可通过 syscall 或第三方封装（如 github.com/gofrs/flock）调用底层 flock(2)（Unix/Linux/macOS）或 LockFileEx（Windows）系统调用。
使用 flock 库实现可移植的文件锁
gofrs/flock 是最常用、轻量且跨平台的方案，自动适配不同系统调用，无需手动处理 syscall 细节。
- 安装：
go get github.com/gofrs/flock - 基本用法：打开文件后创建锁对象，调用
Lock()或TryLock()获取排他锁 - 锁基于文件描述符，进程退出时内核自动释放（即使 panic 或 kill -9）
示例：
import "github.com/gofrs/flock"
file, _ := os.Create("/tmp/myapp.lock")
defer file.Close()
lock := flock.NewFlock("/tmp/myapp.lock")
ok, _ := lock.TryLock()
if !ok {
log.Fatal("无法获取锁，另一个实例正在运行")
}
defer lock.Unlock() // 程序退出前务必释放
// ✅ 此处执行独占操作（如写配置、更新状态文件等）
注意 lock 文件与业务文件的关系
文件锁作用于“锁文件”本身，不是对业务文件加锁。常见误区是试图对日志文件或数据库文件直接加锁 —— 这既无效也不安全。
- 正确做法：为某个资源逻辑（如“全局计数器更新”）单独定义一个锁文件（如
/var/lock/myapp-counter.lock） - 锁文件内容无关紧要，甚至可以为空；关键是其 inode 和 flock 系统调用的语义
- 多个进程对同一锁文件调用
flock()才能形成互斥，不同路径的锁文件互不影响
避免常见陷阱
文件锁是建议性（advisory），不是强制性（mandatory）。它的有效性完全依赖所有参与者主动检查并遵守。
- ❌ 不调用
Lock()/Unlock()的进程会绕过锁 —— 锁只对“合作方”有效 - ❌ 在 fork 后未关闭锁文件描述符，可能导致子进程意外持有锁（flock 锁在 fork 后由父子进程共享，需显式 close 或 dup）
- ❌ 使用
os.Rename或os.Remove删除锁文件不会释放锁；锁在文件描述符关闭或进程终止时才释放 - ✅ 推荐始终用
TryLock()配合超时或重试，避免无限阻塞
替代方案对比：syscall vs flock vs advisory vs mandatory
原生 syscall.Flock 可用但不推荐：Windows 不支持，Linux/macOS 行为细节需自行处理（如 syscall.LOCK_EX | syscall.LOCK_NB），易出错且不可移植。
- flock 库：封装完善、自动重试、错误分类清晰、测试充分 —— 生产首选
- 信号量或命名管道：更重，适用于复杂协调场景，非文件锁本意
- 数据库行锁 / Redis 分布式锁：适合服务化架构，但引入外部依赖，不适合纯本地文件协作
- Mandatory locking：Linux 支持但需挂载选项 + setgid + mode bit，实际极少启用，且 Go 无标准支持，不建议
