不建议在常规代码中主动调用GC.Collect()，因其可能降低性能；仅在极少数场景（如大对象释放后空闲期、Unity场景切换前、性能测试）谨慎使用，并需配合GC.WaitForPendingFinalizers()确保回收完成。
在C#中，GC.Collect()确实能触发垃圾回收，但**不建议在常规代码中主动调用**——.NET的垃圾回收器（GC）是自动、智能且高度优化的，手动干预往往适得其反，甚至降低性能。
什么时候可以考虑调用 GC.Collect()
极少数明确可控的场景下，才可谨慎使用：
- 长时间运行的后台任务（如导出大文件、批量处理）结束后，已知释放了大量大对象（>85KB），且接下来有一段明显的空闲期
- 在Unity等特定引擎中，为控制帧率或内存峰值，在加载新场景前做一次清理（需配合
GC.WaitForPendingFinalizers()） - 编写性能测试或诊断工具时，用于排除GC干扰，获得更干净的内存快照
正确调用方式不止 GC.Collect()
单纯调用GC.Collect()并不保证立即回收所有可回收对象，尤其涉及终结器（finalizer）的对象。完整流程应包括：
-
GC.Collect();—— 触发回收（可指定代数，如GC.Collect(2)强制回收第2代） -
GC.WaitForPendingFinalizers();—— 等待所有待终结对象完成清理 -
GC.Collect();（可选）—— 再次回收，确保终结器释放的内存也被纳入
比强制回收更有效的做法
真正影响GC效率和内存占用的，通常是代码习惯：
- 及时将大对象引用设为
null（尤其在长生命周期对象中持有短生命周期大数组/缓存时） - 使用
using语句或显式调用Dispose()释放非托管资源，避免因Finalize拖慢GC - 避免频繁分配小对象（如循环中新建
string、List），改用池化（ArrayPool、StringBuilder）或复用 - 对超大对象（如>85KB的数组），考虑是否真需要一次性加载，或改用流式处理
基本上就这些。日常开发中，信任GC，聚焦于写好资源管理和对象生命周期，比琢磨何时调用GC.Collect()有用得多。
