高并发下File.AppendAllText性能差因每次调用触发完整磁盘I/O，1000次调用≈1000次系统调用，导致线程阻塞、CPU空转；正确解法是内存队列+单消费者批量刷盘。
为什么直接 File.AppendAllText 在高并发下会拖垮性能
因为每次调用都触发一次磁盘 I/O，操作系统要加锁、寻道、刷缓存——哪怕日志只有几字节，也得走完整文件系统栈。1000 次调用 ≈ 1000 次系统调用，线程频繁阻塞，CPU 空转等 IO，吞吐直接掉到几百条/秒以下。
- 真实场景中，
Task.Run(() => File.AppendAllText(...))只是把阻塞挪到后台线程，没减少 IO 次数，还可能堆积大量待执行任务导致内存暴涨 - 用
StreamWriter配合AutoFlush = false能缓冲，但多线程写同一个实例会丢日志或抛ObjectDisposedException - 真正解法不是“更快地写文件”，而是“少写文件”：让日志先落内存队列，再由单个消费者线程攒够一批（比如 100 条或 100ms）统一刷盘
ConcurrentQueue<string></string> + 后台 Task 是最简可行方案
不用引入 Microsoft.Extensions.Logging 或第三方库也能快速落地，核心就三件事：入队、消费、防崩。
- 日志写入方只做
_queue.Enqueue(logLine)，零阻塞、无锁竞争，ConcurrentQueue原生线程安全 - 后台
Task.Run(async () => { while (!_cts.IsCancellationRequested) { await FlushBatchAsync(); await Task.Delay(100, _cts); } })控制节奏 - 必须用
CancellationToken管理生命周期：应用退出时主动await FlushBatchAsync()清空剩余日志，否则最后 100ms 的日志就丢了 - 别用
Thread.Sleep，它不响应取消；Task.Delay支持CancellationToken，且不会阻塞线程
批量写文件时 File.AppendAllLines 比循环 File.AppendAllText 快 5–10 倍
前者底层复用同一个 FileStream 打开一次、写完关闭；后者每行都打开/关闭文件，Windows 下尤其明显。
- 错误写法：
foreach (var line in batch) File.AppendAllText(path, line + "\n");→ 每行一次CreateFile系统调用 - 正确写法：
File.AppendAllLines(path, batch);→ 仅一次打开，内部用StreamWriter批量写入 - 如果需要严格顺序（比如带时间戳的日志），注意
ConcurrentQueue.TryDequeue是 FIFO，但多生产者入队时，逻辑时间序 ≠ 入队物理序；若要求绝对时间序，得在日志对象里记DateTime.UtcNow，写文件前按该字段排序（一般不需要） - 单次写入别超 1MB，否则
AppendAllLines内部数组分配过大，GC 压力陡增；建议单批控制在 500 行以内
容易被忽略的崩溃点：文件被占用、磁盘满、路径不存在
内存队列再稳，落地环节一出错，日志就静默丢失——而且毫无提示。
- 写文件前务必检查：
Directory.CreateDirectory(Path.GetDirectoryName(path))，否则AppendAllLines直接抛DirectoryNotFoundException - 捕获
IOException和UnauthorizedAccessException：常见于日志目录被其他进程独占锁定（如 Excel 正在打开日志 CSV）、UAC 权限不足、磁盘已满 - 失败后别重试原路径，应降级写入临时位置（如
Path.Combine(Path.GetTempPath(), "fallback.log")），并记录一条“主日志写入失败”的元日志 - 队列本身也要设上限（如
new ConcurrentQueue<string>().Count > 10000</string>），超限时丢弃旧日志或触发告警，避免 OOM
