GC.Collect 是 .NET 强制触发垃圾回收的 API，但并非立即清空内存；它仅发出高优先级回收请求，实际执行受 GC 状态、引用关系、finalizer 队列等影响。
GC.Collect 是什么，它真能“立刻清内存”吗？
GC.Collect 是 .NET 提供的强制触发垃圾回收的 API，但它**不是“立即清空所有内存”的万能按钮**。它只是向运行时发出一个高优先级请求：尽快执行一次垃圾回收（默认阻塞式、全代回收）。实际是否立刻执行、能否回收到你期望的对象，取决于当前 GC 状态、线程调度、对象是否仍被引用、是否在 finalizer 队列中等。尤其要注意：GC.Collect() 不会等待 finalizer 运行完毕——这意味着依赖析构函数释放资源的对象，其非托管内存可能还没真正释放。
哪些真实场景下可以谨慎用 GC.Collect？
绝大多数业务代码里写 GC.Collect() 都是反模式。只有极少数明确可控、可测量、有前后空闲窗口的场景才值得考虑：
- 长时间后台任务（如导出 2GB Excel、批量图像处理）刚结束，确认已释放大量大对象（>85KB），且接下来有数秒以上无重负载的“安静期”
- Unity 中切换场景前，配合
GC.WaitForPendingFinalizers()和GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce做一次可控清理（否则 LOH 碎片可能卡帧） - 编写性能压测工具时，调用
GC.Collect()+GC.WaitForPendingFinalizers()+GC.Collect()（二次）来获得更干净的内存基线，排除 GC 干扰
常见误用和踩坑点
很多人以为“内存涨了就 Collect 一下”，结果反而拖慢程序：
- 频繁调用
GC.Collect(0)或GC.Collect()会打断 GC 自身的分代节奏，导致本该低开销的 Gen 0 回收变成高成本的 Gen 2 扫描，CPU 占用飙升 - 在 UI 线程或高频循环里调用，会造成明显卡顿（它是阻塞性回收）
- 没配
GCSettings.LargeObjectHeapCompactionMode就直接GC.Collect()，对 LOH 几乎无效——85KB+ 的数组、大字符串、大 List 依然堆着不整理 - 误以为调用后
GC.GetTotalMemory(true)返回值变小 = 内存真被系统还回去了——其实只是托管堆压缩了，操作系统层面的内存释放由 GC 异步决定，不一定立刻返还
比 Collect() 更值得关注的替代方案
真正解决内存问题，靠的不是手动回收，而是减少“制造垃圾”：
- 用
Span<t></t>/Memory<t></t>替代string.Substring()或Array.Copy()，避免隐式分配 - 大集合复用（
List<t>.Clear()</t>+Capacity预设）而非反复 new - 及时将大对象引用设为
null（尤其在 long-lived 对象中持有短生命周期大缓存时） - 对非托管资源，必须实现
IDisposable+using，不能指望GC.Collect()触发 finalizer 来清理文件句柄、GDI 对象等
GC 是个聪明但不透明的后台管家；你给它清晰的引用生命周期，它比你手动 Collect 更可靠、更高效。强行插手，往往是在教编译器做事。
