Go 跨进程文件锁的平台差异与替代策略

Go 做跨进程互斥时，最容易踩的坑不是“有没有一个 Lock 函数”，而是把不同平台的锁语义误当成同一种能力。Go 标准库没有统一的跨平台文件锁 API：Unix 常见的是 flock，Windows 则通常通过 LockFileEx 锁定文件字节区间。两者都依赖文件句柄，但竞争、继承、网络文件系统和释放方式并不完全相同。

如果程序只在同一台机器的固定系统上运行，可以按平台封装系统调用；如果部署在容器集群、共享盘或多副本服务中，优先考虑数据库唯一约束、Redis 租约或单实例协调服务。下面只讨论系统调用、竞争与清理，不把锁标记文件包装成万能方案。

先区分进程内锁与跨进程锁

sync.Mutex 保护的是一个 Go 进程里的内存对象。两个进程即使打开同一个路径，也各自拥有不同的 Mutex，彼此不会看到对方的加锁状态。跨进程锁必须把状态放到操作系统能共同识别的对象上，通常是同一个文件句柄、同一个文件的字节范围，或外部协调服务中的同一个键。

因此，先写清楚三个条件：参与者是否都在同一台机器、访问的是本地文件还是网络挂载、非合作进程是否也必须被阻止。只有“同机 + 合作进程 + 文件本身就是共享资源”时，平台文件锁才比较自然。

Unix 与 Windows 的锁语义不是一回事

在 Unix 系统上，flock 常用于对整个文件申请共享锁或排他锁。它通常是协作式的：愿意调用同类锁 API 的进程会遵守，直接用另一个文件描述符读写的程序不一定会被阻止。Linux 手册还特别提醒，NFS、SMB 等网络文件系统可能改变锁的传播方式，不能把本地磁盘上的观察结果直接推广到远端挂载。

Windows 的 LockFileEx 面向文件的字节范围，可以请求共享或排他访问，也可以选择竞争失败立即返回或等待。锁和文件句柄绑定，关闭句柄或进程结束后，系统会释放相应锁，但程序仍应显式解锁并关闭句柄，避免把资源释放延迟交给系统。

这也是 Go 项目通常采用平台文件拆分的原因：Unix 文件调用 golang.org/x/sys/unix.Flock，Windows 文件调用 golang.org/x/sys/windows.LockFileEx，公共层只暴露 Acquire、Release 和“竞争失败”的错误语义。不要在公共文件里直接引用某个平台的句柄类型，再期待交叉编译自动解决差异。

按平台封装获取与释放

以 Unix 为例，获取锁的关键是保持文件句柄存活到临界区结束，并在所有返回路径释放。LOCK_NB 表示不等待，适合由上层决定重试、排队还是退出；如果省略它，系统调用可能一直等待，导致服务关闭或请求取消无法及时生效。

// 文件：lock_unix.go；实际项目应通过文件名或构建标签限制到 Unix 平台。
package filelock

import (
	"errors"
	"os"

	"golang.org/x/sys/unix"
)

var ErrBusy = errors.New("file lock is busy")

// Acquire 打开锁文件并立即尝试排他锁；返回的文件句柄必须由调用方释放。
func Acquire(path string) (*os.File, error) {
	f, err := os.OpenFile(path, os.O_CREATE|os.O_RDWR, 0600)
	if err != nil {
		return nil, err // 打不开文件时不要把权限错误伪装成竞争失败。
	}
	// 非阻塞模式把“暂时被占用”交给调用方决定重试策略。
	if err := unix.Flock(int(f.Fd()), unix.LOCK_EX|unix.LOCK_NB); err != nil {
		_ = f.Close() // 加锁失败也要关闭句柄，避免泄漏。
		return nil, ErrBusy
	}
	return f, nil
}

// Release 先解锁再关闭句柄，确保临界区结束后及时归还资源。
func Release(f *os.File) error {
	if err := unix.Flock(int(f.Fd()), unix.LOCK_UN); err != nil {
		_ = f.Close()
		return err
	}
	return f.Close()
}

Windows 适配层需要把句柄转换为 Handle，准备 Overlapped 结构，再调用 LockFileEx；解锁时使用对应的 UnlockFileEx。公共层不应假设 Windows 的“锁住整个文件”与 Unix 的 flock 完全等价，因为 Windows API 明确以字节区间描述锁定范围。

跨平台封装至少要统一三件事：竞争失败是否立即返回、调用方如何取消等待、释放失败是否记录并影响任务结果。仅仅让两个平台都返回一个 error，却不定义 ErrBusy 与真实 I/O 错误的区别，排障时仍会混乱。

原子占位为什么不能冒充完整文件锁

如果目标只是“同一目录下只允许一个任务创建某个工作标记”，可以使用 O_CREATE|O_EXCL 做原子占位。它依赖文件系统的创建竞争：第一个成功创建者成为占位者，其他进程得到已存在错误。但这个文件本身不是由操作系统自动维护的锁；持有者崩溃后，标记可能一直留在磁盘上。

// tryMarker 只表达“抢到一个名字”，不等于可自动恢复的租约。
func tryMarker(path string) (*os.File, error) {
	// O_EXCL 要和 O_CREATE 一起使用，避免两个进程同时创建成功。
	f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0600)
	if err != nil {
		return nil, err // 已存在、权限不足和磁盘错误应由上层分别处理。
	}
	// 写入持有者信息，便于人工排查；它不能单独证明持有者仍然存活。
	_, writeErr := f.WriteString("owner=process-specific\n")
	if writeErr != nil {
		_ = f.Close()
		_ = os.Remove(path) // 只有确认本次创建成功后，才清理自己的标记。
		return nil, writeErr
	}
	return f, nil
}

func releaseMarker(path string, f *os.File) error {
	if err := f.Close(); err != nil {
		return err
	}
	// 生产环境删除前应再次确认持有者标识，不能盲删他人的新标记。
	return os.Remove(path)
}

如果采用这个方案，应额外设计持有者标识、过期时间和恢复规则。例如把进程 ID 写进去并不可靠：进程可能已经退出，新的进程也可能复用相同 ID。更稳妥的做法是随机实例标识加租约时间，并让续租和接管规则由单独协议定义。没有这些规则时，不要让清理任务定时删除“看起来很旧”的锁文件。

什么时候改用数据库、Redis 或单实例服务

当多个副本不共享同一块本地磁盘，或者任务本身需要在故障后自动接管时，本地文件锁的边界已经不够。数据库可以用唯一键约束表达“同一个资源只能有一个有效持有者”；Redis 可以用带过期时间的 SET key value NX PX 表达临时租约，但释放时必须校验 value 是自己的实例标识，不能直接删除同名键。

如果业务已有队列或调度器，也可以把互斥下沉到单消费者、分区键或任务状态机。它们比共享文件更适合跨主机，但会引入网络分区、时钟、续租、幂等和故障转移问题。文件锁不是“低级方案”，只是它解决的是本地文件访问竞争；把它拿来协调集群任务，才是边界错位。

三个排查问题

为什么两个 Go 进程都拿到了锁？

先确认两边是否真的调用同一种系统锁、是否打开了同一个路径，以及文件是否位于网络挂载。若一边只使用 sync.Mutex 或直接写文件，另一边的协作式 flock 不会自动替它补上规则。

进程退出后要不要删除锁文件？

如果使用的是句柄型系统锁，锁状态通常随句柄释放，锁文件可以作为稳定对象保留；如果使用的是原子标记，删除动作必须确认标记仍属于当前持有者，不能依据文件年龄直接删除。

为什么本地正常，容器或共享盘却异常？

检查挂载类型、锁传播语义和容器是否共享同一文件系统。若参与者跨主机或锁必须跨网络可靠接管，应把互斥状态迁移到数据库、Redis 或专门协调服务，而不是继续堆叠本地文件标记。

最终判断可以压缩成一句话：同机文件竞争用平台适配层，简单占位用原子创建并补齐恢复协议，跨主机任务则把所有权放进可观察、可续租的外部协调系统。先确定竞争边界，再选择锁 API，清理逻辑才不会反过来制造新的并发事故。