我们一直在使用“Drip”来尝试确定为什么其中包含 UpdatePanel 的页面往往会使用大量客户端内存。对于一个定期回发的页面，我们看到 Drip 检测到 0 个泄漏。然而，当我们添加一个更新面板时，更新面板内的每个 DOM 对象都会出现泄漏（根据 Drip）。
我不确定 Drip 是否足够可靠以报告这类事情 - 报告的泄漏似乎表明 Drip 正在稍微修改页面。
有人对这个有经验么？我应该恐慌并停止使用 Microsoft Ajax 吗？我并没有怀疑微软，但对我来说它可能会这么糟糕似乎很可疑。
此外，如果您知道比 Drip 更好的工具，那也会有所帮助。
根据ASP.NET AJAX in Action，p。257
就在用更新的 HTML 替换旧标记之前，检查面板中的所有 DOM 元素是否有 Microsoft Ajax 行为或附加到它们的控件。为了避免内存泄漏，与 DOM 元素关联的组件被释放，然后在替换 HTMl 时销毁。
据我所知，更新面板中的任何 asp.net ajax 组件都被处理以防止内存泄漏，但其中的任何其他内容都将被接收到的 html 替换。
因此，如果您在响应的目标容器中没有任何 asp.net ajax 组件，则它与使用任何其他 js 框架/ajax 请求的内部 html 替换基本相同，所以我会说这只是如何浏览器处理这个，而不是导致这个的asp.net ajax。
此外，虽然它可能是“泄漏”的，但它可能是设计使然，这意味着浏览器可能尚未回收 dom 元素并释放它们。此外，滴水可能会导致那些泄漏，因为它附着在那些 dom 元素上。
这很有可能。这几乎是我们假设的（浏览器问题，不一定是 Ajax）。
我们现在的问题是，许多人通过 Citrix 环境访问此应用程序，每个页面不断创建 DOM 对象而不释放它们，Citrix 环境在使用一段时间后开始抖动。我在网上看到过类似的投诉（尤其是当您愚蠢到可以通过 Citrix 访问 Ajax 网站时），但这并没有让我感觉更好，这是预期的行为。
我现在想知道是否有人想出了一个聪明的解决方法。我们还有一个客户端应用程序，我们在其中使用 .NET BrowserControl 来访问这些网站，而不仅仅是直接的 IE7，所以如果有人知道秘密 API 调用（FreeStaleDomObjectsFTW()），我们可以从堆栈的那一端使用，那将也很有用。
您可以附加到PageRequestManager 类的 pageLoading 事件并通过面板更新属性并删除每个中的 DOM 元素。