FileStream并发写会丢日志，因底层文件句柄不保证原子写入，多线程Write易致缓冲区错位、覆盖或截断；加lock有性能瓶颈且崩溃后数据可能未刷盘；MemoryMappedFile+Interlocked虽可行但跨平台兼容差、管理复杂；更务实方案是单生产者+无锁环形缓冲区+后台I/O线程刷盘，配合磁盘空间监控与错误降级机制。
为什么 FileStream 直接并发写会丢日志
因为底层文件句柄不保证原子写入，多个线程同时调用 Write 或 WriteAsync 会导致缓冲区错位、覆盖或截断。哪怕加了 lock，在高并发下也会成为性能瓶颈，且一旦异常中断（如进程崩溃），FileStream 可能残留未刷盘数据。
MemoryMappedFile + Interlocked 是可行路径，但别直接上
它能绕过内核锁，但实际落地很重：需手动管理偏移、边界、页对齐、序列化结构体，还要处理映射视图生命周期和跨进程同步。Windows 上表现尚可，Linux/macOS 兼容性差，.NET 6+ 虽支持跨平台映射，但 MemoryMappedFile.CreateFromFile 对追加写不友好，容易踩到“只读映射”或“长度固定”的坑。
- 日志条目必须定长，否则
Interlocked.Add算偏移会错乱 - 每次写前要检查剩余空间，满时需重建映射 —— 这本身就要加锁
- 崩溃后无法自动恢复写位置，得靠额外元数据文件或 checksum 校验
更务实的做法：单生产者 + 无锁环形缓冲区 + 后台线程刷盘
不是所有“无锁”都得靠 CAS 指令；用线程分工规避竞争，比硬刚原子操作更稳。核心是让业务线程只往内存队列投递，由专属 I/O 线程串行落盘。
- 用
System.Collections.Concurrent.ConcurrentQueue<t></t>存日志对象（轻量，无锁实现） - 避免直接存
string，改用ReadOnlyMemory<byte></byte>减少编码分配 - I/O 线程用
FileStream.WriteAsync+FileOptions.WriteThrough绕过系统缓存（注意：会降速，但保命） - 加
try/catch捕获IOException，失败时记录错误并跳过该条，别让单条坏日志卡死整个管道
示例关键片段：
var queue = new ConcurrentQueue<ReadOnlyMemory<byte>>();
// 生产者线程
queue.Enqueue(Encoding.UTF8.GetBytes($"[{DateTime.Now:O}] INFO: hello\n"));
// 消费者线程（单独 Task.Run）
while (!ct.IsCancellationRequested)
{
if (queue.TryDequeue(out var data))
{
await fileStream.WriteAsync(data, ct).ConfigureAwait(false);
await fileStream.FlushAsync(ct).ConfigureAwait(false);
}
else
{
await Task.Delay(1, ct).ConfigureAwait(false);
}
}
真正容易被忽略的点：文件滚动和磁盘满处理
无锁只解决并发写冲突，不解决磁盘爆满、权限丢失、路径不存在这些现实问题。一旦 WriteAsync 报 IOException，后续所有日志都会堆积在内存队列里，最终 OOM。
- 定期检查磁盘剩余空间（比如每 5 秒调用
DriveInfo.AvailableFreeSpace） - 滚动策略别依赖文件大小（
Length属性可能不准），改用写入字节数计数器 + 原子更新 - 当检测到写失败且重试 3 次仍无效，把剩余队列 dump 到临时内存流，再尝试写入备用路径（如
%TEMP%）
没做这些，所谓“无锁”只是把崩溃时机从秒级延迟到了小时级。
