ui线程执行同步文件io会导致界面假死；task.run仅转移阻塞而非真正异步；应优先使用file.readalltextasync等真正异步api，注意filestream需启用useasync参数，避免跨线程访问句柄。
文件IO在UI线程阻塞会导致界面假死
WinForms或WPF里直接用 File.ReadAllText、File.Copy 这类同步IO，会卡住当前线程。如果在UI线程调用，整个窗口就动不了——不是崩溃，是“没响应”，Windows会标为“未响应”。这不是C#特有，是同步阻塞IO的通病。
- 别在按钮点击事件里直接写
File.ReadAllBytes("large.log")，哪怕文件才几MB，也可能卡住几百毫秒 - WinForms中
Application.DoEvents()是饮鸩止渴，不能解决根本问题，还可能引发重入或状态不一致 - WPF里绑定命令执行同步IO，同样会让
CommandManager暂停路由，后续输入延迟
Task.Run 包裹同步IO不是万能解药
很多人一见阻塞就套 Task.Run(() => File.ReadAllLines(path))，看似“异步”了，实则只是把锅甩给线程池。这在多数场景可行，但要注意副作用：
- 线程池线程数有限（默认约
Environment.ProcessorCount * 500），大量并发文件读会挤占其他后台任务资源 - 大文件读取仍会持续占用线程池线程，期间该线程无法处理其他
Task - 没有真正利用系统级异步IO（如Windows的IOCP），纯属“伪异步”——只是换了个线程堵着
- 若路径是网络共享（如
\servershare ile.txt），某些SMB版本下Task.Run + 同步IO可能比直接同步更慢，因多了线程调度开销
真正异步IO必须用 xxxAsync 方法族
C# 4.5+ 的 FileStream 和 File 静态类提供了真正的异步支持，底层走IOCP，不占线程。但要注意：不是所有方法都等价。
- 优先用
File.ReadAllTextAsync(path, Encoding.UTF8)，它内部封装了FileStream异步打开+读取，比手动建FileStream更安全 -
FileStream构造时必须传useAsync: true（如new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, true)），否则即使调ReadAsync也退化为同步 -
StreamWriter.WriteAsync在未await前就关闭流，会抛ObjectDisposedException——因为异步写还没真正落盘 - ASP.NET Core 中若在
Controller里用同步IO，会快速耗尽ThreadPool，触发请求排队，错误日志里常见Timeouts are not supported on this stream（其实是底层被堵死）
跨线程访问文件句柄会直接报错
文件句柄（SafeFileHandle）本身不是线程安全的。一个 FileStream 实例创建在线程A，不能在B线程上调它的 Read 或 Dispose。
- 常见错误：在
Task.Run里打开文件，返回FileStream，主线程试图读——立刻抛InvalidOperationException: Stream was not readable或句柄无效 -
MemoryMappedFile是例外，它支持多进程/多线程共享，但需显式用CreateFromFile+SafeMemoryMappedHandle，且读写仍要自己加锁 - 若真需跨线程传递文件数据，正确做法是：在原线程完成读取（同步或异步），把字节数组或字符串传出；或用
Channel<byte></byte>等线程安全管道传递数据块
真正麻烦的是混合场景：比如WPF里拖拽多个大文件进界面，既要预览缩略图（需IO），又要实时更新进度条（需回UI线程），还要允许用户中途取消。这时候光靠 async/await 不够，得配合 IProgress<t></t> 和 CancellationToken，而且取消不一定立刻生效——底层IOCP操作一旦发起，只能等完成或超时，没法“强行中断”句柄。
