C# 2003年旧项目简单类Dispose中调用GC.Collect()是否可直接删除？

2003年对应.NET Framework 1.0/1.1刚发布的早期阶段，出现这种写法通常是以下几个原因导致的：

• 开发人员背景遗留：当时大量.NET开发者是从C/C++转型而来，习惯了手动管理堆内存，会错误地认为.NET中所有对象用完都需要手动执行销毁逻辑、主动触发GC才能释放内存，避免泄漏。
• 对IDisposable接口的认知错误：IDisposable的设计初衷是用于释放非托管资源，以及依赖非托管资源的托管对象。但早年社区对该接口的作用存在大量错误传播，很多开发者误以为只要是“用完需要释放”的类都要继承该接口，哪怕是纯托管的数据模型类也会照搬实现。
• 早期GC机制不完善+错误优化技巧传播：.NET Framework 1.x版本的GC策略成熟度远低于后续版本，当时社区流传着很多现在看来错误的性能优化技巧，比如“主动调用GC.Collect可以降低网站内存占用、提升吞吐量”，很多项目会无脑在Dispose方法中添加GC.Collect调用。
• 上下文错误关联：你贴出的数据层代码中对DataTable执行了Dispose操作，当年的开发者大概率错误认为和DataTable绑定的业务模型类也需要同步实现IDisposable，才能避免内存泄漏，属于无意义的跟风写法。

你的判断完全正确，这部分Dispose实现和GC.Collect调用没有任何实际价值，可以直接删除：

• ProjectAutostart属于纯托管的数据载体类，仅包含值类型属性，没有持有任何非托管资源，也没有持有数据库连接、文件句柄、网络流等需要主动释放的托管资源，完全不需要实现IDisposable接口。
• 手动调用GC.Collect反而会带来明确的性能损耗：GC默认的分代回收策略会自动选择合适的时机执行回收，手动强制触发全代回收会打乱GC的调度逻辑，大幅提升CPU占用，在网站高并发场景下负面影响会非常明显。
• 删除该逻辑不会带来任何副作用，既不会引发内存泄漏，也不会影响原有业务逻辑的运行，反而会降低不必要的性能开销。

注：数据层中对DataTable调用Dispose的逻辑是合理的，DataTable内部持有部分需要提前释放的托管资源，这部分代码不需要修改。

内容的提问来源于stack exchange，提问作者hwmaat