用 FileStream 配合 FileShare.Read 实现写入独占但允许并发读，关键在于打开文件时声明共享策略而非运行时加锁；需手动构造 FileStream 指定 FileAccess.Write 和 FileShare.Read，并推荐原子替换临时文件以避免脏读。
用 FileStream 配合 FileShare.Read 实现写入独占但允许并发读
关键不是“加锁”，而是打开文件时明确告诉操作系统：我只写，不拦别人读。C# 默认的 File.OpenWrite 会用 FileShare.None，直接把其他所有访问（包括读）全堵死，这是最常踩的坑。
正确做法是手动构造 FileStream，把 FileShare 设为 Read：
using var fs = new FileStream("data.txt", FileMode.Open, FileAccess.Write, FileShare.Read, 4096, FileOptions.None);注意点：
-
FileAccess.Write表示你只打算写，系统不会给你读权限，避免误读旧内容 -
FileShare.Read允许其他进程/线程同时用FileAccess.Read打开该文件——但不能写 - 缓冲区大小（4096）建议显式指定，避免默认 0 导致同步 I/O 拖慢写入
- 别用
File.WriteAllText或StreamWriter直接封装路径——它们内部默认不共享读，会悄悄覆盖掉你的意图
为什么 FileStream.Lock 不适合这个场景
FileStream.Lock 是字节范围锁，属于应用层逻辑锁，不被操作系统文件系统识别。另一个进程用 notepad.exe 或 cat 去读，完全感知不到这个锁，照样能打开、读取甚至覆盖文件——它根本没起作用。
真正需要的是打开时的共享策略，不是运行时加锁。常见错误现象：
- 自己代码里调
Lock后，发现 Python 脚本还能正常open(..., 'r')读文件 → 因为 Lock 不影响其他进程的打开行为 - 写入中途被另一个程序删掉或移动文件 → 这和锁无关，是 Windows 文件句柄生命周期问题，需靠重试或监听
FileSystemWatcher - 多个写入方同时用
FileShare.Read打开 → 写冲突照旧发生，这方案只解决“读不被阻塞”，不解决“多写并发”
写入完成前如何防止读到脏数据
允许并发读，不代表读操作能自动避开未写完的内容。Windows 下文件长度变更和数据落盘不同步，读者可能读到截断或中间状态。稳妥做法是分两步：
- 写入临时文件（如
data.txt.tmp），用完整FileStream写完并调用fs.Flush()+fs.Dispose() - 再用
File.Replace("data.txt.tmp", "data.txt", null)原子替换——这个操作在 NTFS 上是原子的，读方要么看到旧全量，要么看到新全量 - 如果必须单文件、流式写入（比如日志追加），就只能靠读者自行检查文件末尾是否完整（例如校验行结尾、JSON 是否闭合），没有银弹
跨进程 vs 同进程线程间，处理方式完全不同
同进程内多线程写同一文件，FileStream 本身不是线程安全的，即使共享策略设对了，也得加 lock 或用 ConcurrentQueue 排队写入；而跨进程场景下，lock 关键字毫无意义——它只锁当前进程内的线程。
所以判断依据很实际：
- 如果你的“其他读操作”来自另一个 .NET 进程、PowerShell、Python 或记事本 → 只看
FileShare设置是否正确 - 如果你只是在 ASP.NET Core 多个 controller action 里并发写同一个文件 → 必须加进程内同步（如
static readonly object _writeLock = new();） - 混合场景（既有多线程又跨进程）？那就得组合：进程内用
lock，打开文件时仍坚持FileShare.Read
最容易被忽略的是：很多人以为设了 FileShare.Read 就万事大吉，结果上线后发现高并发时读到了半截 JSON 或 CSV 错行——那不是锁的问题，是写入没做完就被读了，得靠原子替换或客户端容错逻辑兜底。
