本文介绍如何在 go 中实现兼容 linux 和 windows 的非阻塞文件写锁，满足读操作无锁、写操作需独占且失败立即返回的需求，避免使用 unsafe 或系统特定调用。
本文介绍如何在 go 中实现兼容 linux 和 windows 的非阻塞文件写锁，满足读操作无锁、写操作需独占且失败立即返回的需求，避免使用 unsafe 或系统特定调用。
在构建多进程协作的 Go 应用（如日志轮转器、配置同步服务或分布式缓存本地代理）时，常需确保对同一文件的写入互斥，而读取可并发进行——即“读不阻塞、写需独占、获取失败不等待”。Go 标准库未提供跨平台文件锁抽象，syscall.Flock 仅在 Unix 系统可用，Windows 则需依赖 syscall.LockFileEx 等 Win32 API，直接跨平台调用既不可移植又易出错。
最佳实践是面向接口编程 + 构建标签（build tags）分发平台特化实现，兼顾可维护性、可测试性与零依赖。核心思路如下：
- 定义统一锁接口；
- 为各平台提供独立、符合语义的实现；
- 通过构建标签自动选择实现，主逻辑完全无条件分支；
- 所有实现均遵循“非阻塞写锁”语义：成功返回 nil，失败返回 ErrLockUnavailable（非 os.ErrPermission 等模糊错误），绝不挂起 goroutine。
✅ 接口定义（推荐置于 lock/lock.go）
// lock/lock.go
package lock
import "os"
// Locker 封装跨平台文件锁行为
type Locker interface {
// TryLock 尝试以独占模式锁定文件。若文件已被其他进程锁定，立即返回 ErrLockUnavailable。
// 调用者负责确保 *os.File 已打开（O_RDWR 或 O_WRONLY），且支持底层锁机制。
TryLock(*os.File) error
// Unlock 释放锁（通常为幂等操作，失败可忽略）
Unlock(*os.File) error
}
var (
// ErrLockUnavailable 表示无法获取写锁（如被占用或权限不足），是 TryLock 唯一预期错误
ErrLockUnavailable = &lockError{"file is locked by another process"}
)
type lockError struct{ msg string }
func (e *lockError) Error() string { return e.msg }
func (e *lockError) Is(target error) bool { return target == ErrLockUnavailable }? Linux/macOS 实现（lock/flock_linux.go）
//go:build linux || darwin
// +build linux darwin
package lock
import (
"os"
"syscall"
)
func (f *flockImpl) TryLock(fd *os.File) error {
err := syscall.Flock(int(fd.Fd()), syscall.LOCK_EX|syscall.LOCK_NB)
if err != nil {
if err == syscall.EWOULDBLOCK {
return ErrLockUnavailable
}
return err
}
return nil
}
func (f *flockImpl) Unlock(fd *os.File) error {
return syscall.Flock(int(fd.Fd()), syscall.LOCK_UN)
}
type flockImpl struct{}
var Default = &flockImpl{}? Windows 实现（lock/filelock_windows.go）
//go:build windows
// +build windows
package lock
import (
"os"
"syscall"
"unsafe"
)
const (
lockExclusive = 0x00000002
lockFailImmediately = 0x00000001
)
var (
kernel32 = syscall.NewLazyDLL("kernel32.dll")
procLockFileEx = kernel32.NewProc("LockFileEx")
procUnlockFileEx = kernel32.NewProc("UnlockFileEx")
)
type overlapped struct {
Internal uintptr
InternalHigh uintptr
Offset uint32
OffsetHigh uint32
hEvent syscall.Handle
}
func (w *winImpl) TryLock(fd *os.File) error {
h := syscall.Handle(fd.Fd())
var ol overlapped
ret, _, err := procLockFileEx.Call(
uintptr(h),
uintptr(lockExclusive|lockFailImmediately),
0, // dwReserved
0xffffffff, // nNumberOfBytesToLockLow (all)
0, // nNumberOfBytesToLockHigh
uintptr(unsafe.Pointer(&ol)),
)
if ret == 0 {
if err == syscall.ERROR_LOCK_VIOLATION {
return ErrLockUnavailable
}
return err
}
return nil
}
func (w *winImpl) Unlock(fd *os.File) error {
h := syscall.Handle(fd.Fd())
var ol overlapped
ret, _, err := procUnlockFileEx.Call(
uintptr(h),
0, // dwReserved
0xffffffff, // nNumberOfBytesToLockLow
0, // nNumberOfBytesToLockHigh
uintptr(unsafe.Pointer(&ol)),
)
if ret == 0 {
return err
}
return nil
}
type winImpl struct{}
var Default = &winImpl{}? 使用示例（安全写入模式）
package main
import (
"fmt"
"os"
"your-module/lock" // 替换为实际路径
)
func writeWithLock(filename string, data []byte) error {
f, err := os.OpenFile(filename, os.O_RDWR|os.O_CREATE, 0644)
if err != nil {
return err
}
defer f.Close()
// 尝试获取写锁
if err := lock.Default.TryLock(f); err != nil {
if errors.Is(err, lock.ErrLockUnavailable) {
fmt.Println("⚠️ 写锁不可用，跳过写入")
return nil // 或返回自定义重试逻辑
}
return fmt.Errorf("failed to acquire lock: %w", err)
}
defer func() { _ = lock.Default.Unlock(f) }() // 确保释放
// 执行原子写入（例如 truncate + write）
if err := f.Truncate(0); err != nil {
return err
}
_, err = f.Write(data)
return err
}
func main() {
if err := writeWithLock("config.json", []byte(`{"mode":"prod"}`)); err != nil {
panic(err)
}
}⚠️ 关键注意事项
- 文件句柄生命周期：*os.File 必须在 TryLock 前打开，并保持有效直至 Unlock 完成；不要在锁期间关闭文件。
- 读操作无需干预：按题设要求，读取始终允许，无需调用任何锁方法——os.ReadFile / ioutil.Read 等可直接使用。
- 锁粒度是文件，非内容：flock 和 LockFileEx 均作用于整个文件描述符，不支持区域锁（range lock）。若需细粒度控制，请考虑数据库或 Redis 等外部协调服务。
- 测试建议：为每个平台实现编写单元测试（利用 //go:build + go test -tags=linux），并用 os.TempDir() 创建临时文件验证锁行为。
- 替代方案警示：避免使用端口绑定、临时文件标记等“伪锁”方案——它们存在竞态（TOCTOU）、清理困难、且无法保证文件级一致性。
通过该设计，你获得了一个轻量、标准、可测试且真正跨平台的文件写锁工具，既尊重各系统原生语义，又将复杂性完全隔离在实现层，业务代码专注逻辑而非平台适配。
