关于释放COM对象的一篇很棒的文章是2.5释放COM对象（MSDN）。

我建议的方法是，如果Excel.Interop引用是非本地变量，则将其置空，然后调用GC.Collect（）和GC.WaitForPendingFinalizers（）两次。将自动处理本地范围的Interop变量。

这消除了为每个COM对象保留命名引用的需要。

以下是文章中的一个示例：

public class Test {

    // These instance variables must be nulled or Excel will not quit
    private Excel.Application xl;
    private Excel.Workbook book;

    public void DoSomething()
    {
        xl = new Excel.Application();
        xl.Visible = true;
        book = xl.Workbooks.Add(Type.Missing);

        // These variables are locally scoped, so we need not worry about them.
        // Notice I don't care about using two dots.
        Excel.Range rng = book.Worksheets[1].UsedRange;
    }

    public void CleanUp()
    {
        book = null;
        xl.Quit();
        xl = null;

        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }
}

这些话直接来自文章：

在几乎所有的情况下，取消RCW引用并强制垃圾收集将正确清理。如果同时调用GC.WaitForPendingFinalizers，垃圾收集将尽可能具有确定性。也就是说，在第二次调用WaitForPending Finalizers返回时，您将非常确定对象何时被清理。作为替代方案，您可以使用Marshal.ReleaseComObject。但是，请注意，您不太可能需要使用此方法。

这看起来确实太复杂了。根据我的经验，要让Excel正确关闭，只有三件关键的事情：

1：确保没有对您创建的excel应用程序的剩余引用（无论如何，您应该只有一个引用；将其设置为空）

2：调用GC.Collect（）

3:必须通过用户手动关闭程序或通过对Excel对象调用“退出”来关闭Excel。（请注意，“退出”的功能与用户试图关闭程序的功能相同，如果存在未保存的更改，即使Excel不可见，也会显示一个确认对话框。用户可以按“取消”，Excel将不会关闭。）

1需要在2之前发生，但3可以随时发生。

实现这一点的一种方法是用自己的类包装interop Excel对象，在构造函数中创建interop实例，并使用Dispose实现IDisposable

这将从程序的方面清理出优秀的东西。一旦Excel关闭（由用户手动或您调用退出），该过程将消失。如果程序已经关闭，那么进程将在GC.Collect（）调用中消失。

（我不确定它有多重要，但您可能需要在GC.Collect（）调用之后调用GC.WaitForPendingFinalizers（），但这并不是完全需要摆脱Excel进程。）

多年来，这对我来说毫无问题。请记住，虽然这是有效的，但实际上您必须优雅地关闭它才能工作。如果在清理excel之前中断程序（通常在调试程序时单击“停止”），则仍会累积excel.exe进程

您需要意识到Excel对您正在运行的文化也非常敏感。

您可能会发现，在调用Excel函数之前，需要将区域性设置为EN-US。这并不适用于所有函数，但适用于其中一些函数。

    CultureInfo en_US = new System.Globalization.CultureInfo("en-US"); 
    System.Threading.Thread.CurrentThread.CurrentCulture = en_US;
    string filePathLocal = _applicationObject.ActiveWorkbook.Path;
    System.Threading.Thread.CurrentThread.CurrentCulture = orgCulture;

即使您正在使用VSTO，这也适用。

有关详细信息：http://support.microsoft.com/default.aspx?scid=kb;我们；第320369季度

我不敢相信这个问题已经困扰了世界五年。。。。如果您已经创建了应用程序，则需要在删除链接之前先关闭它。

objExcel = new Excel.Application();  
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing)); 

关闭时

objBook.Close(true, Type.Missing, Type.Missing); 
objExcel.Application.Quit();
objExcel.Quit(); 

当您新建一个excel应用程序时，它会在后台打开一个excel程序。您需要在释放链接之前命令该excel程序退出，因为该excel程序不是您直接控制的一部分。因此，如果链接被释放，它将保持开放！

每个人都很好编程~~

“千万不要在COM对象中使用两个点”是避免COM引用泄漏的一条很好的经验法则，但Excel PIA会导致泄漏的方式比乍一看更明显。

其中一种方法是订阅任何Excel对象模型的COM对象公开的任何事件。

例如，订阅Application类的WorkbookOpen事件。

关于COM事件的一些理论

COM类通过回调接口公开一组事件。为了订阅事件，客户端代码可以简单地注册实现回调接口的对象，COM类将调用其方法以响应特定事件。由于回调接口是一个COM接口，因此实现对象的职责是减少它为任何事件处理程序接收的任何COM对象（作为参数）的引用计数。

Excel PIA如何公开COM事件

Excel PIA将Excel应用程序类的COM事件公开为常规的.NET事件。每当客户端代码订阅.NET事件（强调“a”）时，PIA都会创建实现回调接口的类的实例，并将其注册到Excel中。

因此，为了响应来自.NET代码的不同订阅请求，许多回调对象被注册到Excel中。每个事件订阅一个回调对象。

用于事件处理的回调接口意味着，PIA必须为每个.NET事件订阅请求订阅所有接口事件。它不能挑挑拣拣。在接收到事件回调时，回调对象检查关联的.NET事件处理程序是否对当前事件感兴趣，然后调用该处理程序或无提示地忽略回调。

对COM实例引用计数的影响

所有这些回调对象都不会减少它们接收的任何COM对象（作为参数）对任何回调方法的引用计数（即使是被忽略的回调方法）。它们只依赖CLR垃圾收集器来释放COM对象。

由于GC运行是非确定性的，这可能导致Excel进程延迟的时间比预期的长，并造成“内存泄漏”的印象。

解决方案

目前唯一的解决方案是避免PIA的COM类事件提供程序，并编写自己的事件提供程序来确定是否释放COM对象。

对于Application类，这可以通过实现AppEvents接口，然后使用IConnectionPointContainer接口将实现注册到Excel来完成。Application类（以及使用回调机制公开事件的所有COM对象）实现IConnectionPointContainer接口。

首先，在执行Excel互操作时，您永远不必调用Marshal.ReleaseComObject（…）或Marshal.FinalReleaseComObject（.）。这是一个令人困惑的反模式，但任何有关此的信息（包括来自Microsoft的信息）都是不正确的，这些信息表明您必须从.NET手动释放COM引用。事实上，.NET运行时和垃圾收集器正确地跟踪和清理COM引用。对于您的代码，这意味着您可以删除顶部的整个`while（…）循环。

其次，如果要确保在进程结束时清理进程外COM对象的COM引用（以便Excel进程关闭），则需要确保垃圾收集器运行。您可以通过调用GC.Collect（）和GC.WaitForPendingFinalizers（）来正确地执行此操作。两次调用此操作是安全的，并且可以确保周期也被彻底清理（尽管我不确定是否需要，我希望能有一个示例来说明这一点）。

第三，当在调试器下运行时，本地引用将被人为地保持活动状态，直到方法结束（以便本地变量检查工作）。因此，GC.Collect（）调用对于从同一方法中清除rng.Cells等对象无效。您应该将执行GC清理中的COM互操作的代码拆分为单独的方法。（这是我的一个关键发现，来自@nightcoder在这里发布的答案的一部分。）

因此，一般模式为：

Sub WrapperThatCleansUp()

    ' NOTE: Don't call Excel objects in here... 
    '       Debugger would keep alive until end, preventing GC cleanup

    ' Call a separate function that talks to Excel
    DoTheWork()

    ' Now let the GC clean up (twice, to clean up cycles too)
    GC.Collect()    
    GC.WaitForPendingFinalizers()
    GC.Collect()    
    GC.WaitForPendingFinalizers()

End Sub

Sub DoTheWork()
    Dim app As New Microsoft.Office.Interop.Excel.Application
    Dim book As Microsoft.Office.Interop.Excel.Workbook = app.Workbooks.Add()
    Dim worksheet As Microsoft.Office.Interop.Excel.Worksheet = book.Worksheets("Sheet1")
    app.Visible = True
    For i As Integer = 1 To 10
        worksheet.Cells.Range("A" & i).Value = "Hello"
    Next
    book.Save()
    book.Close()
    app.Quit()

    ' NOTE: No calls the Marshal.ReleaseComObject() are ever needed
End Sub

关于这个问题有很多虚假信息和困惑，包括MSDN和Stack Overflow上的许多帖子（尤其是这个问题！）。

最终说服我仔细研究并找出正确建议的是博客文章Marshal.ReleaseComObject Considered Dangerous，以及发现在调试器下引用保持活动的问题，这让我之前的测试感到困惑。