FileStream加锁在分布式环境下无效，因其仅作用于单机内核，跨节点无法感知；应改用Redis分布式锁或数据库/对象存储等原子性更强的方案。
为什么 FileStream 加锁在分布式环境下完全无效
单机上的 FileStream 锁（比如 FileShare.None 或 Lock()）只作用于当前进程或本机操作系统内核，跨机器时根本看不到对方的锁。两个服务实例同时写同一个网络共享路径（如 \nasshareconfig.json），它们各自拿到的是本地句柄，互不感知——这不是“锁没生效”，而是压根没设计成支持分布式协调。
常见错误现象：IOException 提示“文件正由另一进程使用”从不出现；反而出现数据截断、JSON 解析失败、配置覆盖丢失等静默损坏。
- 使用场景：多节点定时任务写日志归档到 SMB 共享；微服务共用 NFS 挂载点更新缓存文件
- 参数差异：
FileOptions.DeleteOnClose或FileShare.ReadWrite不解决根本问题，只是让冲突更隐蔽 - 性能影响：强行用
Monitor或MemoryMappedFile做本地同步，对跨节点毫无意义，还拖慢单机吞吐
用 DistributedLock.Redis 实现跨节点文件操作互斥
真正起作用的是外部协调服务，Redis 是最轻量且可靠的选项。C# 生态中 DistributedLock.Redis 库封装了租约续期、自动释放和故障检测，比手撸 SET key value EX 30 NX 更稳妥。
实操建议：
- 锁粒度必须精确到具体文件路径，例如
lock:file://appsettings.prod.json，避免用宽泛前缀如lock:config - 超时时间（
TimeSpan）要明显长于最大预期写入耗时（比如写 10MB 文件预计 2s，设为 15s），否则可能被误释放 - 务必在
try/finally中调用lockHandle.Dispose()，否则 Redis 锁残留会导致后续所有节点阻塞 - 不要把锁逻辑嵌在
using (var fs = File.Open(...))里——文件打开后若锁提前过期，仍会出问题
简短示例：
using var redis = ConnectionMultiplexer.Connect("redis:6379");
using var provider = new RedisDistributedSynchronizationProvider(redis.GetDatabase());
using var handle = await provider.AcquireLockAsync($"lock:file://{filePath}", TimeSpan.FromSeconds(15));
if (!handle.IsAcquired) throw new InvalidOperationException("无法获取分布式锁");
// 此时才安全地 File.WriteAllText(filePath, content);
替代方案：改用原子性更强的存储机制
如果业务允许，彻底绕开“多节点争抢写文件”这个反模式，比加锁更健壮。
常见做法：
- 用数据库代替配置文件：SQL Server 的
UPDATE ... OUTPUT或 PostgreSQL 的INSERT ... ON CONFLICT DO UPDATE天然支持行级强一致性 - 用对象存储（如 S3 兼容接口）配合 ETag 条件写入：
PutObjectRequest.IfMatch可防止覆盖非预期版本 - 写临时文件 + 原子重命名（仅限支持 rename 的文件系统）：
File.Move(tempPath, finalPath)在 NTFS 或 ext4 上是原子的，但 NFS/SMB 不保证 - 禁用直接文件写入：所有修改走 API 网关，由单点服务落盘，其他节点只读
脑裂发生时，FileSystemWatcher 会成为帮凶
很多人用 FileSystemWatcher 监听配置变更后触发重载，但在脑裂场景下，它会同时在多个节点上报同一事件——不是因为监听错了，而是因为每个节点都独立看到了文件被修改的底层通知。
这导致所有节点并发 reload，进一步加剧状态不一致。更危险的是，如果 reload 过程包含初始化静态资源或单例，可能引发类型加载冲突或内存泄漏。
- 解决方案不是关掉
FileSystemWatcher，而是加一层“变更确认”：只有成功获取到对应文件的分布式锁后，才执行 reload - 避免监听整个目录：
NotifyFilter.LastWrite足够，去掉FileName和DirectoryName，减少误触发 - Windows 上注意
EnableRaisingEvents = true后，首次启动时不会触发已存在的文件变更，需手动补一次检查
真正的难点不在代码怎么写，而在于判断“这个文件是否真的必须被多节点同时写”。大多数所谓“共享配置”其实只需要一个权威源，其余节点做只读缓存+带版本号轮询。一旦接受这点，很多锁和重试逻辑就自然消失了。
