“千万不要在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不关闭的原因，即使在读取和创建时为每个对象创建直接引用，也需要使用“For”循环。

For Each objWorkBook As WorkBook in objWorkBooks 'local ref, created from ExcelApp.WorkBooks to avoid the double-dot
   objWorkBook.Close 'or whatever
   FinalReleaseComObject(objWorkBook)
   objWorkBook = Nothing
Next 

'The above does not work, and this is the workaround:

For intCounter As Integer = 1 To mobjExcel_WorkBooks.Count
   Dim objTempWorkBook As Workbook = mobjExcel_WorkBooks.Item(intCounter)
   objTempWorkBook.Saved = True
   objTempWorkBook.Close(False, Type.Missing, Type.Missing)
   FinalReleaseComObject(objTempWorkBook)
   objTempWorkBook = Nothing
Next

关于释放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。但是，请注意，您不太可能需要使用此方法。

这对我正在进行的一个项目起到了作用：

excelApp.Quit();
Marshal.ReleaseComObject (excelWB);
Marshal.ReleaseComObject (excelApp);
excelApp = null;

我们了解到，在使用Excel COM对象时，将其每个引用都设置为空非常重要。这包括单元格、工作表和所有内容。

Excel不会退出，因为应用程序仍保留对COM对象的引用。

我猜您调用了COM对象的至少一个成员，而没有将其分配给变量。

对我来说，它是excelApp.Worksheets对象，我直接使用它，而没有将它分配给变量：

Worksheet sheet = excelApp.Worksheets.Open(...);
...
Marshal.ReleaseComObject(sheet);

我不知道C#在内部为WorksheetsCOM对象创建了一个包装器，但我的代码没有发布它（因为我不知道），这也是Excel没有卸载的原因。

我在这个页面上找到了我的问题的解决方案，它也有一个关于C#中COM对象用法的好规则：

切勿对COM对象使用两点。

因此，有了这些知识，正确的方法是：

Worksheets sheets = excelApp.Worksheets; // <-- The important part
Worksheet sheet = sheets.Open(...);
...
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(sheet);

尸检后更新：

我希望每一位读者都能非常仔细地阅读Hans Passant的回答，因为它解释了我和许多其他开发人员偶然遇到的陷阱。几年前我写这个答案时，我不知道调试器对垃圾收集器的影响，得出了错误的结论。为了历史起见，我的答案保持不变，但请阅读此链接，不要走“两点”的道路：了解.NET中的垃圾收集和使用IDisposable清理Excel互操作对象

正如其他人所指出的，您需要为使用的每个Excel对象创建一个显式引用，并对该引用调用Marshal.ReleaseComObject，如本知识库文章所述。您还需要使用try/finally来确保始终调用ReleaseComObject，即使抛出异常也是如此。即，代替：

Worksheet sheet = excelApp.Worksheets(1)
... do something with sheet

你需要做一些事情，比如：

Worksheets sheets = null;
Worksheet sheet = null
try
{ 
    sheets = excelApp.Worksheets;
    sheet = sheets(1);
    ...
}
finally
{
    if (sheets != null) Marshal.ReleaseComObject(sheets);
    if (sheet != null) Marshal.ReleaseComObject(sheet);
}

如果要关闭Excel，还需要在释放Application对象之前调用Application.Quit。

正如您所看到的，只要您尝试做任何稍微复杂的事情，这很快就会变得非常笨拙。我用一个简单的包装类成功地开发了.NET应用程序，该类包装了Excel对象模型的一些简单操作（打开工作簿、写入范围、保存/关闭工作簿等）。包装器类实现IDisposable，在它使用的每个对象上仔细地实现Marshal.ReleaseComObject，并且不向应用程序的其他部分公开任何Excel对象。

但这种方法不能很好地适应更复杂的需求。

这是.NETCOM互操作的一大缺陷。对于更复杂的场景，我会认真考虑用VB6或其他非托管语言编写ActiveX DLL，您可以将与进程外COM对象（如Office）的所有交互委托给它。然后，您可以从.NET应用程序中引用此ActiveX DLL，因为您只需要发布这一个引用，所以事情会变得更加简单。