相关疑难解决方法(0)

解决了

关于这个问题,网上有很多矛盾的信息.感谢@John,我设法解决了闭包(如下所示)不是内存泄漏的原因,即使在IE8中 - 它们并不像人们所说的那样普遍.事实上,我的代码中只发生了一次泄漏,事实证明并不难解决.

从现在开始,我对这个问题的回答是:
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 …