FileStream是底层字节流操作类，需搭配StreamReader等包装器处理字符串或对象；适用于控制缓冲区、文件共享、指针定位及大文件分块读写，且必须显式Dispose以释放系统句柄。
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(string path, FileMode mode, FileAccess access, FileShare share)，四个参数里前三个决定行为，最后一个常被忽略却极易出错：
-
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()
读写中文字符串时为什么总乱码？
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，哪怕字节全对上，解出来的字符串也完全不对——编码必须全程一致。
