Windows环境下分布式文件锁的生效机制依赖NFSv4有状态协议、SMB OpLock或外部协调服务，通过跨机器锁状态托管与租约续期实现全局互斥，而非本地API。
windows 环境下分布式文件锁的生效机制，核心在于跨进程、跨机器对同一文件资源的协调控制，而非单机本地锁。它不依赖 windows 自带的 lockfile 或 lockfileex（这些仅作用于本机进程间），而是通过有状态的网络协议或外部协调服务实现真正意义上的“分布式”语义。
依赖 NFSv4 协议原生支持
NFSv4 是 Windows Server 支持的、具备内建分布式锁能力的主流方案。与早期 NFSv2/v3 不同，NFSv4 设计为有状态协议，将锁管理直接集成在协议栈中：
- 客户端和服务端各自维护 seqid（序列号），每次 lock/open 操作递增并校验，确保请求不重复、不丢失、不乱序；
- 锁状态由 NFS 服务器统一托管，所有挂载该共享的 Windows 客户端都向同一服务端发起锁申请，实现全局互斥；
- 支持租约（lease）机制：客户端需定期续约，超时未续则服务端自动释放锁，避免死锁或悬挂锁。
基于 SMB 协议的 Opportunistic Locking（OpLock）
在 Windows 域环境或 Azure 文件共享中，SMB 协议通过 Opportunistic Locking 提供类分布式锁行为：
- 当客户端首次打开文件时，SMB 服务器可授予 Level1 OpLock（读/写缓存锁），允许本地高速缓存并延迟回写；
- 一旦其他客户端尝试访问同一文件，服务器立即向持有锁的客户端发送 Break 通知，强制其回写并降级或释放锁；
- 虽非严格强一致锁，但在多数协作场景（如 Office 文档并发编辑）中，它提供了高效且可感知的冲突协调能力。
借助外部协调服务（如 ZooKeeper / Redis）
纯应用层实现时，Windows 应用可通过调用 REST 或 TCP 接口，接入跨平台分布式协调服务：
- 例如使用 Redis 的
SET key value NX PX 30000实现租约式锁，value 为唯一 client ID，配合定时心跳续期； - ZooKeeper 利用临时顺序节点 + Watch 机制，让多个 Windows 进程竞争创建子节点，序号最小者获得锁；
- 关键点在于：锁的“生效”不发生在文件系统层，而由应用主动检查锁状态后再执行文件 I/O，属于 应用级咨询锁（Advisory Locking），需所有参与者自觉遵守。
WinFsp 中的用户态锁不构成分布式锁
需特别注意：WinFsp 作为 Windows 用户态文件系统框架，其内部使用的 FspFileNodeAcquireExclusive、自旋锁等，仅作用于本机 WinFsp 驱动与用户态服务之间的通信路径，不具备跨机器可见性。它们解决的是单机内多线程/IRP 并发问题，不是分布式文件锁的组成部分。
