using语句能保证FileStream释放，因编译后等价于try/finally，无论是否抛异常都会调用Dispose()；但若构造失败、跨作用域持有引用或显式Close()则可能引发泄漏或误用。
using语句是否真能保证FileStream释放
能，但前提是不手动调用 Dispose() 或在 using 块外持有引用。C# 的 using 语句会在块结束时自动调用 Dispose()，而 FileStream 的 Dispose() 会关闭底层操作系统句柄并释放资源。
常见误判点：有人看到文件仍被占用或抛出 ObjectDisposedException，就怀疑 using 失效——其实多是因异常未被捕获导致后续逻辑误用已释放对象，或跨作用域返回了 FileStream 实例。
FileStream在using中抛异常会不会漏释放
不会。无论 using 块内是否抛出异常，Dispose() 都会被调用。这是 using 编译后等价于 try/finally 的保障机制。
- 即使
Read()或Write()抛出IOException，FileStream仍会进入finally并释放句柄 - 但注意：如果异常发生在构造函数（如路径非法、权限不足），
FileStream实例根本没创建成功，自然无须释放 - 若需在异常后做清理（如记录日志、重试），应在
using外层加try/catch，而非干扰using本身
哪些操作会让using失效或引发资源泄漏
真正破坏资源释放的不是 using 写法本身，而是绕过它或干扰其生命周期的行为：
- 把
FileStream赋值给类字段或静态变量，导致 GC 无法回收，Dispose()不再被触发 - 在
using块内返回该流（如return fs;），调用方拿到的是已释放对象，后续读写必崩 - 显式调用
fs.Close()后又让using再次调用Dispose()——虽然FileStream对重复调用有防护，但属于冗余且易混淆的操作 - 用
File.OpenRead()等工厂方法获得流后，仍需用using包裹，不能认为“系统造的就不用管”
FileStream释放后还能访问文件吗
不能。释放后句柄关闭，任何对 Stream 的读写、Position 获取、Length 访问都会抛 ObjectDisposedException。
容易忽略的一点：FileStream 默认启用缓冲（bufferSize > 0），但缓冲区内容在 Dispose() 时会自动刷新（Flush()）并提交到磁盘——除非你显式传入 leaveOpen: true 或设 useAsync: false 且未调用 Flush()，否则不必额外担心数据丢失。
若需延迟释放（比如多个方法共用一个流），就别用 using，改用手动 try/finally + Dispose()，并确保只有一个可信入口负责释放。
