GC.Collect()不是清内存开关，默认只回收第0代，大对象常进LOH或第2代，强制回收需GC.Collect(2)但开销大且LOH不压缩，效果受限于根引用和工作集机制。
GC.Collect() 不是“清内存开关”，调用它大概率让内存问题更难诊断、性能更差。
GC.Collect() 默认只扫第0代，大对象根本碰不到
你刚 new byte[1024 * 1024] 分配了一个 1MB 数组？它几乎立刻晋升到第2代（或直接进 LOH），而 GC.Collect() 默认只触发 Gen 0 回收——相当于打扫客厅却不管地下室和仓库。
- 想强制清理第2代，得写
GC.Collect(2)，但会暂停所有托管线程（Stop-The-World），开销极大 - 大对象堆（LOH）默认不压缩，
GC.Collect(2)对它也基本无效，除非提前设GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce - Server GC 模式下（ASP.NET 默认），
GC.Collect()只影响当前线程绑定的 heap，其他 CPU 核心上的 heap 不动
调用后内存没降？不是 GC 失效，而是对象还在被根引用
GC.GetTotalMemory(true) 下降 ≠ 任务管理器内存下降。前者反映托管堆已回收的字节数；后者看的是进程工作集（Working Set），受操作系统调度影响，可能缓着不还。
- 如果
GC.GetTotalMemory(true)没降，说明对象仍被“根”持有着：比如事件没取消订阅（button.Click += handler忘了-=）、Timer还在运行、静态集合（static Dictionary<int, byte[]>）一直存着大缓冲区 - 别靠任务管理器判断 GC 效果，用
GC.CollectionCount(0)/GC.CollectionCount(2)看实际回收次数，或用 dotMemory / VS Diagnostic Tools 观察对象引用链
哪些场景真能用 GC.Collect()？就那几个窄口子
绝大多数业务代码里写 GC.Collect() 都是错的。只有极少数可控、低频、明确目标的场景才考虑：
- 内存压力测试前：用
GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();清掉 pending finalizer 和残留对象，获得干净基线 - 长时间空闲前（如 WinForms 主窗口最小化后）：主动释放可回收资源，降低驻留内存
- 诊断
IDisposable是否生效：配合GC.KeepAlive()和 finalizer 日志，验证非托管资源是否真被释放 - 极少数嵌入式或容器环境，内存限制严苛且可控，需手动干预 GC 节奏（但仍优先优化分配）
比 Collect() 更该盯住的三个地方
真正卡住内存的，从来不是 GC 不勤快，而是你无意中给它塞了一堆“假活对象”：
- 静态缓存：检查所有
static字段，尤其是Dictionary、ConcurrentBag、HashSet—— 它们会长期 hold 住对象，阻止晋升和回收 - 事件泄漏：UI 控件、
INotifyPropertyChanged、Rx.NET 的Subscribe()，没Unsubscribe()就等于挂了个强引用 - 大对象滥用：85KB+ 的数组、字符串、
List<T>直接进 LOH，不压缩、难回收；改用Span<byte>、ArrayPool<byte>.Shared.Rent()或分块处理
GC 是后台自动运行的系统级服务，不是你手里的扫帚。它失效的信号，永远藏在你代码里那些没断开的引用、没释放的订阅、没池化的对象背后。
