c#如何使用FileStream_c#FileStream看这一篇就够了_保姆级教程

很多人一碰到文件操作，第一反应就是File.ReadAllText。但真要处理大文件、多进程共享访问，或者需要精准控制读写位置时，FileStream才是那个绕不开的底层角色。这玩意儿没那么复杂，但坑也不少。

先说几个核心判断：FileStream 不是万能的文件操作入口，它只负责“字节流”这一层，想直接读写字符串或对象，得自己套上 StreamReader、BinaryWriter 等包装器——否则你会卡在乱码、截断、EOF异常上。

什么时候必须用 FileStream 而不是 File.ReadAllText？

这个问题很关键。当你需要控制：缓冲区大小、文件共享模式（比如边写边被其他进程读）、指针位置（跳过头部、追加到中间）、或处理超大文件（避免一次性加载进内存）时，FileStream 是绕不开的底层选择。举个例子：

• File.ReadAllBytes 会把整个文件读进内存，1GB 文件就占 1GB RAM；FileStream 可以分块读取，配合 BufferedStream 控制内存占用
• 多个进程要同时访问同一文件？必须用 FileShare.ReadWrite 构造 FileStream，File 静态方法默认独占
• 需要从第 1024 字节开始读？fs.Position = 1024 直接设，静态方法做不到

简而言之，静态方法图的是方便，FileStream 图的是掌控力。场景不同，选择就不同。

FileStream 构造函数参数怎么选？关键三参数

大家最常用的FileStream重载是 FileStream(string path, FileMode mode, FileAccess access, FileShare share)。四个参数里，前三个决定行为，最后一个FileShare常被忽略——却偏偏是并发场景下翻车的头号原因。

• FileMode：不是“打开/创建”这么简单。Create 会清空已有内容；OpenOrCreate 才是“有就开、没就建”；Append 自动把 Position 设到末尾，但必须搭配 FileAccess.Write
• FileAccess：如果只读却传 ReadWrite，打开时就抛 UnauthorizedAccessException；反之，用 Read 打开只写文件会失败
• FileShare：默认 None，意味着其他线程/进程立刻被拒。调试时常见错误：IOException: The process cannot access the file...，八成是忘了设 FileShare.Read

记住这三条选择法则，能省下不少调试时间。

不手动调用 Dispose() 或不用 using 会怎样？

这个问题比想象中严重。FileStream 持有操作系统句柄（handle），.NET 的 GC 不保证及时回收它。后果很直接：

• 文件被“占用”，后续 File.Delete 抛 IOException
• 并发场景下，未释放的句柄数达到系统上限（Windows 默认约 16K），新 FileStream 创建直接失败
• 即使显式调用 Close()，也不等于释放句柄（它只是把内部状态置为 Closed），必须走 Dispose()

正确写法永远是：

using (var fs = new FileStream("log.bin", FileMode.Append, FileAccess.Write, FileShare.Read)){    fs.Write(buffer, 0, buffer.Length);} // 这里自动 Dispose()

这个模式比try-catch-finally干净得多，也安全得多。不仅FileStream如此，所有实现了IDisposable的资源类，都应该用using包裹。

读写中文字符串时为什么总乱码？

这个问题，说到底，是编码理解不到位。FileStream 只认字节，不认识字符编码。直接 fs.Write(Encoding.UTF8.GetBytes("你好")) 写进去没问题，但反过来，如果用 fs.Read 读出字节再用 Encoding.Default.GetString() 解码，大概率乱码——因为 Default 是系统 ANSI 编码（如 GBK），而你写的是 UTF-8。

处理办法也很直接：

• 写字符串：先 Encoding.UTF8.GetBytes(str)，再 fs.Write()
• 读字符串：先 fs.Read() 到字节数组，再 Encoding.UTF8.GetString(bytes)
• 更省事的做法：用 StreamWriter / StreamReader 包一层，它们内部自动处理编码，但注意构造时显式传 Encoding.UTF8，别依赖默认值

真正容易被忽略的点是：同一个文件，写入用 UTF-8，读取用 UTF-16，哪怕字节全对上，解出来的字符串也完全不对——编码必须全程一致。这是基本功，但也是翻车频率最高的坑。