同步io在c#中并非过时，而是适用于短小、确定性高且不阻塞关键路径的场景；异步io并非万能，盲目使用反而增加开销与调试难度。
同步IO在C#里不是“过时”，而是有明确适用边界
当文件操作是短小、确定性高、且不阻塞关键路径时，同步IO更简单、更可控。异步不是银弹，盲目套用 async/await 反而增加调度开销和调试复杂度。
哪些场景必须/推荐用同步IO（File.ReadLines、File.WriteAllText 等）
常见错误是以为“所有IO都该异步”，结果在控制台工具、配置加载、单元测试或启动阶段引入不必要的 async Main 和上下文切换。
- 读取小配置文件（appsettings.json 或本地
settings.ini：同步调用File.ReadAllText更快，无调度延迟 - 命令行工具中一次性读写日志/临时文件：没有并发压力，
FileStream同步构造 +Read比ReadAsync少一层状态机开销 - ASP.NET Core 中的静态文件预加载（如
wwwroot资源扫描）：发生在应用启动期，用同步IO可避免Task.Run误用或死锁风险 - 单元测试内模拟文件行为：同步API更容易Mock，比如用
MemoryStream配合StreamReader，不用处理ValueTask生命周期
异步IO真正起作用的条件（FileStream.ReadAsync、StreamWriter.WriteAsync）
异步IO的价值只在「高延迟 + 高并发」场景兑现。磁盘本身延迟低（毫秒级），但网络驱动器（SMB/NFS）、加密文件系统、或杀毒软件挂钩时，IO可能卡住几百毫秒——这时异步才真正释放线程。
- Web API 响应大文件下载（>10MB）：用
FileStream.ReadAsync避免线程池饥饿，尤其在linux上ThreadPool默认较小 - 后台服务持续轮询多个目录（
FileSystemWatcher+ 批量读取）：单次读可能不慢，但并发10+个文件流时，同步阻塞会拖垮吞吐 - 与
HttpClient或数据库IO混合编排：统一用异步可避免.Result或.Wait()引发的死锁（尤其在ui或旧ASP.NET上下文）
注意：File.copy 默认同步，但 File.Copy(source, dest, true) 不会自动变异步；真要异步复制得自己用 FileStream + CopyToAsync。
容易被忽略的坑：同步API也可能“假异步”
有些看似同步的方法底层用了异步逻辑，比如 File.ReadAllBytes 在.NET 6+ 对小文件会走内存映射（MemoryMappedFile），实际不触发磁盘IO；但若文件被其他进程锁定，它仍会同步阻塞——这点和 ReadAllBytesAsync 行为一致，只是堆栈更浅。
-
Directory.GetFiles是同步但可能极慢（尤其UNC路径），它不提供异步版本，别指望加await就能提速 -
FileStream构造函数默认同步打开，但传入FileOptions.Asynchronous才启用真正的重叠IO（windows）或epoll（Linux），否则ReadAsync只是线程池包装 - 在
async void方法里调用同步文件IO（如事件处理器），一旦出错（UnauthorizedAccessException），异常会直接炸掉进程，无法被try/catch捕获
最常被绕过的事实：同步IO的“慢”往往来自路径解析、权限检查、符号链接展开这些前置步骤，而非读写本身。优化时先看 dotnet-trace 采样，别急着改 async。