解决了
关于这个主题，网络上有很多相互矛盾的信息。感谢@John，我设法确定闭包（如下文所用）不是内存泄漏的原因，而且——即使在 IE8 中——它们并不像人们声称的那样普遍。事实上，我的代码中只发生了 1 个泄漏，这证明修复并不难。
从现在开始，我对这个问题的回答将是：
AFAIK，IE8 泄漏的唯一时间是在全局对象上附加事件/处理程序时。( window.onload, window.onbeforeunload,...)。要解决这个问题，请参阅下面我的回答。
重大更新：
我现在完全迷失了......经过一段时间的文章和新旧文章的挖掘后，我至少留下了一个巨大的矛盾。尽管之一的JavaScript的大师的（道格拉斯·克罗克福德）说：
由于 IE 无法完成其工作并回收循环，因此我们必须完成它。如果我们明确打破循环，那么 IE 将能够回收内存。根据微软的说法，闭包是内存泄漏的原因。这当然是非常错误的，但它导致微软在如何处理微软的错误方面给程序员提供了非常糟糕的建议。事实证明，在 DOM 端很容易打破循环。在 JScript 端破解它们几乎是不可能的。
正如@freakish 指出的，我下面的代码片段类似于 jQuery 的内部工作方式，我对我的解决方案感到非常安全，不会导致内存泄漏。同时我发现了这个 MSDN 页面，其中的部分Circular References with Closures是我特别感兴趣的。下图几乎是我的代码如何工作的示意图，不是吗：
唯一的区别是我没有将我的事件侦听器附加到元素本身的常识。
尽管如此Douggie是相当明确的：闭包是不是在IE MEM-泄漏的根源。这种矛盾让我不知道谁是对的。
我还发现泄漏问题在 IE9 中也没有完全解决（找不到链接 ATM）。
最后一件事：我还了解到 IE 在 JScript 引擎之外管理 DOM，这让我在<select>基于 ajax 请求更改元素的子元素时遇到麻烦：
function changeSeason(e)
{
var xhr,sendVal,targetID;
e = e || window.event;//(IE...
targetID = this.id.replace(/commonSourceFragment/,'commonTargetFragment');//fooHomeSelect -> barHomeSelect
sendVal = this.options[this.selectedIndex].innerHTML.trim().substring(0,1);
xhr = prepareAjax(false,(function(t)
{
return function()
{
reusableCallback.apply(this,[t]);
}
})(document.getElementById(targetID)),'/index/ajax');
xhr({data:{newSelect:sendVal}});
}
function reusableCallback(elem)
{
if (this.readyState === 4 && this.status === 200)
{
var data = JSON.parse(this.responseText);
elem.innerHTML = '<option>' + data.theArray.join('</option><option>') + '</option>';
}
}
如果 IE 真的像 JScript 引擎一样管理 DOM，那么使用此代码不释放选项元素的几率有多大？
我特意添加了这个片段作为示例，因为在这种情况下，我将作为闭包作用域一部分的变量作为参数传递给全局函数。我找不到关于这种做法的任何文档，但根据 Miscrosoft 提供的文档，它应该打破任何可能发生的循环引用，不是吗？
警告：冗长的问题...（抱歉）
我已经编写了几个相当大的 JavaScript 来在我的 Web 应用程序中进行 Ajax 调用。为了避免大量回调和事件，我充分利用了事件委托和关闭。现在我写了一个函数，让我想知道可能的内存泄漏。虽然我知道 IE > 8 比它的前辈更好地处理闭包，但公司政策仍然支持 IE 8。
下面我提供了一个我正在讨论的示例，在这里您可以找到一个类似的示例，虽然它不使用 ajax，但使用 setTimeout，结果几乎相同。（当然，您可以跳过下面的代码，直接看问题本身）
我想到的代码是这样的：
function prepareAjax(callback,method,url)
{
method = method || 'POST';
callback = callback || success;//a default CB, just logs/alerts the response
url = url || getUrl();//makes default url /currentController/ajax
var xhr = createXHRObject();//try{}catch etc...
xhr.open(method,url,true);
xhr.setRequestMethod('X-Requested-with','XMLHttpRequest');
xhr.setRequestHeader('Content-type','application/x-www-form-urlencoded');
xhr.setRequestHeader('Accept','*/*');
xhr.onreadystatechange = function()
{
callback.apply(xhr);
}
return function(data)
{
//do some checks on data before sending: data.hasOwnProperty('user') etc...
xhr.send(data);
}
}
所有非常简单的东西，除了onreadystatechange回调。在直接绑定处理程序时，我注意到 IE 的一些问题：xhr.onreadystatechange = callback;，因此匿名函数。不知道为什么，但我发现这是使其工作的最简单方法。
正如我所说，我使用了很多事件委托，因此您可以想象，访问触发 ajax 调用的实际元素/事件可能会很有用。所以我有一些看起来像这样的事件处理程序：
function handleClick(e)
{
var target,parent,data,i;
e = e || window.event;
target = e.target || e.srcElement;
if (target.tagName.toLowerCase() !== 'input' && target.className !== 'delegateMe')
{
return true;
}
parent = target;
while(parent.tagName.toLowerCase() !== 'tr')
{
parent = parent.parentNode;
}
data = {};
for(i=0;i<parent.cells;i++)
{
data[parent.cells[i].className] = parent.cells[i].innerHTML;
}
//data looks something like {name:'Bar',firstName:'Foo',title:'Mr.'}
i = prepareAjax((function(t)
{
return function()
{
if (this.readyState === 4 && this.status === 200)
{
//check responseText and, if ok:
t.setAttribute('disabled','disabled');
}
}
})(target));
i(data);
}
如您所见，onreadystatechange回调是函数的返回值，它target在调用回调时提供对元素的引用。多亏了事件委托，当我决定从 DOM 中删除它时（我有时会这样做），我不再需要担心可能绑定到该元素的事件。
然而，在我看来，回调函数的调用对象对于 IE 的 JScript 引擎及其垃圾收集器来说可能太过分了：
Event ==> handler ==> prepareAjax 是一个非常正常的调用序列，但是回调参数：
[匿名。func（参数 t = target）返回匿名。F（可以访问 t，然后返回目标）]
===> 传递给匿名回调函数，使用 .apply 方法调用 xhr 对象，然后是prepareAjax 函数的私有变量
我已经在 FF 和 chrome 中测试了这种“结构”。它在那里工作得很好，但是这种在关闭后关闭时的调用堆栈，每次传递对 DOM 元素的引用都会在 IE 中成为一个问题（尤其是 IE9 之前的版本）？
不，我不会使用 jQuery 或其他库。我喜欢纯 JS，并且想尽可能多地了解这种被严重低估的语言。代码片段不是实际的复制粘贴示例，但提供了 IMO，很好地表示了我如何在整个脚本中使用委托、闭包和回调。因此，如果某些语法不太正确，请随时纠正它，但这当然不是这个问题的内容。