FileStream读写二进制文件的关键在于缓冲管理、同步/异步选择及异常与资源泄漏防范；构造后不能直接Read，因打开模式决定文件指针位置；Read/Write不保证读写满指定字节数，须检查返回值并循环处理；短生命周期用using，长生命周期需手动Dispose；小文件同步更稳，异步需显式指定FileOptions.Asynchronous。
直接说结论：用 FileStream 读写二进制文件，核心不是“怎么打开”，而是“要不要自己管理缓冲、是否需要同步/异步、以及如何避免 IOException 或资源泄漏”——多数人卡在后两者。
为什么 FileStream 构造后不能直接读？
常见错误是 new 出 FileStream 就立刻调用 Read，结果返回 0 字节或抛 IOException。根本原因是：文件指针默认在开头，但若以 FileMode.Create 或 FileMode.Truncate 打开（尤其写入场景），会清空文件并把指针留在开头；而若以 FileMode.Append 打开，则指针自动定位到末尾，此时 Read 必然失败。
实操建议：
- 读取前务必确认打开模式是
FileMode.Open或FileMode.OpenOrCreate，且文件存在可读内容 - 写入前若需保留原内容，别用
FileMode.Create；改用FileMode.OpenOrCreate+Seek定位 - 不确定当前指针位置时，用
Position属性查看，用Seek(0, SeekOrigin.Begin)重置
Read 和 Write 的字节数不等于你传的 count 参数？
这是 FileStream 最反直觉的一点：Read(buffer, offset, count) 不保证读满 count 字节，它只承诺“最多读 count”，实际返回值才是真实读取数。网络流或管道流更明显，但本地文件在磁盘忙、权限变化或遇到 EOF 时也会提前返回。
实操建议：
- 永远检查
Read返回值，用循环读直到返回 0（表示 EOF） - 不要假设一次
Read就能读完整个文件；大文件必须分块处理 - 写入同理：
Write不抛异常 ≠ 写成功，但一般本地文件写入失败会直接抛IOException，所以重点防读不全
用 using 管 FileStream 还是手动 Close？
99% 场景该用 using，但有例外：如果你把 FileStream 传给另一个长期存活的对象（比如某个自定义 BinaryReader 持有它），再用 using 就会导致提前释放底层句柄，后续操作直接崩出 ObjectDisposedException。
实操建议：
- 短生命周期操作（如单次读配置、存缓存）——无脑
using - 长生命周期持有（如日志写入器复用一个
FileStream）——手动Dispose，且确保所有使用者都清楚生命周期归属 - 永远别在
finally里只调Close()；Dispose()才真正释放句柄，Close()只是别名
异步读写为什么有时比同步还慢？
对小文件（ReadAsync/WriteAsync 可能因线程调度开销和完成端口初始化反而更慢。.NET 默认启用 UseAsync = true（Windows 上走 I/O Completion Ports），但若文件句柄是通过 FileOptions.Asynchronous 显式创建的，才真正启用底层异步；否则只是线程池模拟。
实操建议：
- 大文件（>1MB）或网络共享路径，优先用
ReadAsync避免阻塞 UI 或请求线程 - 小文件且性能敏感，用同步 API 更稳；可用
Task.Run(() => { /* 同步读 */ })包一层，比纯异步更可控 - 确认是否真启用了异步：构造
FileStream时显式传FileOptions.Asynchronous，否则ReadAsync可能退化为同步
真正难的不是语法，是判断什么时候该跳过 FileStream 直接用 File.ReadAllBytes，什么时候又该上 MemoryMappedFile——这些边界往往出现在日志轮转、音视频帧处理或数据库页缓存里，而不是教程里的“Hello World.bin”。
