File.ReadAllBytesAsync 更安全，因其基于 IOCP 不阻塞线程；而 Task.Run 包裹同步方法仅占用线程池，高并发易耗尽资源。
为什么 File.ReadAllBytesAsync 比 Task.Run(() => File.ReadAllBytes(...)) 更安全
直接用同步 API 包一层 Task.Run 看似“异步”，实则只是把线程池线程占用了，没释放 I/O 线程，高并发下容易耗尽线程池。而 File.ReadAllBytesAsync 底层走的是真正的 I/O 完成端口（IOCP），不阻塞线程。
- Windows 上必须用
FileStream构造时传useAsync: true，否则即使调用ReadAsync也会退化为同步读（.NET 6+ 默认开启，但旧项目或显式构造FileStream时仍需注意） -
File.ReadAllTextAsync默认 UTF-8，若文件是 GB2312 或 UTF-16，必须显式传Encoding.GetEncoding("GB2312")，否则乱码且无提示 - 大文件（>100MB）别用
ReadAllBytesAsync，它会一次性分配完整内存块，OOM 风险高；应改用流式处理：FileStream+StreamReader.ReadLineAsync或分块ReadAsync
写文件时 FileStream 的 FileOptions.Asynchronous 必须显式指定吗
在 .NET 5+ 中，只要构造 FileStream 时传了 useAsync: true（这是 FileStream 构造函数的布尔参数），底层就会自动设置 FileOptions.Asynchronous。但如果你手动传 FileOptions 参数，就必须包含它——漏掉会导致 WriteAsync 实际走同步路径。
- 错误写法：
new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.None, 4096, FileOptions.SequentialScan)→ 缺少Asynchronous，WriteAsync会同步执行 - 正确写法：
new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.None, 4096, FileOptions.Asynchronous | FileOptions.SequentialScan) - 更省心的方式：用
File.OpenWrite不行（它不支持 async），优先用File.Create或直接 newFileStream并明确设useAsync: true
await using 和 DisposeAsync 在文件操作中到底该谁负责关闭
文件句柄是稀缺资源，不及时释放会导致“Too many open files”错误（尤其 Linux 容器环境）。await using 是最稳妥的选择，它会在作用域结束时自动调用 DisposeAsync，且能保证异常路径下也释放。
- 别写
try/finally+stream.Close()，Close()是同步的，且不等同于DisposeAsync() - 如果手动调
DisposeAsync()，必须await它——不 await 就相当于“发起关闭但不管结果”，句柄可能延迟释放甚至泄漏 - 常见坑：
return stream.ReadAsync(...)后忘记await using，导致流对象被返回、外部无法控制生命周期
实际项目里怎么组织异步文件读写的错误重试和日志
磁盘满、权限不足、网络共享断开——这些不是代码 bug，而是运行时环境问题，必须可观察、可重试、可降级。
- 用
ExceptionDispatchInfo.Capture(e).Throw()保留原始堆栈，别简单throw new IOException(..., e) - 对
UnauthorizedAccessException、DirectoryNotFoundException这类非瞬态错误，不重试；对IOException（如“正在使用另一个进程”）可加指数退避重试 3 次 - 日志里至少记清：
Path、Operation（Read/Write）、FileSize（如果已知）、Exception.Message，避免只记“文件操作失败”
真正难的不是写出 async/await，是判断哪一步该等、哪一步不能等、哪一步失败后该沉默还是报警。比如配置文件读取失败，服务该直接退出；而用户上传临时文件失败，可能只需返回 503 并提示稍后重试。
