using语句是强制资源释放机制，非可选语法糖；因gc只回收托管内存，不处理文件句柄等非托管资源，而using由编译器转为try-finally，确保dispose()必调且及时。
using 语句不是“可选语法糖”，而是防止非托管资源泄漏的强制手段——只要对象实现了 IDisposable，又在作用域内创建并使用，就必须用 using（或等价的 try/finally）包裹，否则资源大概率不会被及时释放。
为什么 using 会自动调用 Dispose() 而不是靠 GC？
.NET 的垃圾回收器（GC）只管托管内存，对文件句柄、数据库连接、GDI 对象这些非托管资源完全无感。即使对象被 GC 回收，其持有的句柄可能仍卡在系统里，直到进程退出。而 using 是编译器生成的 try/finally 结构，确保无论是否抛异常，Dispose() 都会被执行一次。这不是“更方便”，而是唯一能控制释放时机的方式。
- GC 不保证何时运行，甚至可能全程不触发 finalizer
-
Dispose()是显式释放逻辑，Finalize()（析构函数）只是最后兜底，且不可靠 - 像
FileStream、SqlConnection、Bitmap这类类型，文档和 IDE 都会明确标出实现了IDisposable，就是提醒你：必须用using或手动try/finally
多个资源怎么写才安全？嵌套 vs 同行声明的区别
两种写法都合法，但行为不同，容易踩坑的是释放顺序和变量作用域。
- 嵌套写法（推荐）：
using (var conn = new SqlConnection(s)) using (var cmd = new SqlCommand(sql, conn)) { conn.Open(); cmd.ExecuteNonQuery(); }→ 先释放cmd，再释放conn，符合依赖关系；每个变量作用域清晰，无法跨层误用 - 同行声明（仅限同类型）：
using (var conn1 = new SqlConnection(s1), conn2 = new SqlConnection(s2)) { ... }→ 两者类型必须一致，且释放顺序不确定（由编译器决定），不适用于有依赖关系的资源（比如StreamReader依赖FileStream） - 混合类型不能同行声明：写
using (var fs = new FileStream(...), sr = new StreamReader(...))会编译失败
C# 8+ 的声明式 using 有什么实际影响？
这种写法：
using var stream = new FileStream("log.txt", FileMode.Append);
stream.Write(data);看起来省了一层缩进，但它把释放时机绑定到了**当前作用域末尾**，而不是代码块末尾。这意味着：- 它等价于把
using声明放在方法开头，但释放点是整个方法 return / throw 之前 - 如果方法很长、有多个 early-return 分支，资源生命周期可能比预期长，增加占用时间
- 不能用于需要提前释放的场景（比如循环中每次打开一个新文件，必须用块级
using控制粒度） - 变量名在作用域内可重新赋值，但再次赋值不会触发前一个对象的
Dispose()—— 仅首次赋值的对象会在作用域结束时释放
Dispose() 被调了，为什么还会报 ObjectDisposedException？
常见原因不是 Dispose() 没调，而是调了之后又去访问已释放的资源。典型表现：
- 在
using块外继续使用该变量（如stream.Read()），.NET 多数实现会立刻抛ObjectDisposedException - 自定义
IDisposable类没加disposed标志位，在Dispose()后未校验状态就允许调用其他方法 - 多线程环境下，一个线程刚
Dispose()，另一个线程同时调用Read()→ 竞态导致异常 - 错误地在
Finalize()中重复释放同一块非托管内存（忘了调GC.SuppressFinalize(this)）
真正难调试的点在于：这个异常往往不发生在 using 块里，而是在后续某次不经意的属性访问或方法调用中突然冒出——所以关键不是“怎么写 using”，而是“写完后别碰它”。
