企业官网建设流程全解析

1. 项目概述：为什么前端工程师必须亲手“看见”内存泄漏

你有没有遇到过这样的情况：页面运行几分钟后开始卡顿，滚动越来越慢，动画掉帧严重，DevTools 的 Performance 面板里堆内存曲线像坐了火箭一样持续上扬，但代码里没写什么大图、没加载海量数据，甚至只是个简单的表单页？我去年帮一个电商后台系统做性能优化时，就卡在这样一个问题上——用户打开商品管理页，操作半小时后点击“导出Excel”按钮，浏览器直接无响应。排查了所有网络请求、渲染逻辑、第三方SDK，最后发现罪魁祸首是一段只有三行的闭包代码，它把整个商品列表对象悄悄锁在了内存里，十年不放。

这就是典型的 JS 内存泄漏。它不像语法错误会立刻报错，也不像接口超时能一眼看出；它更像慢性病，症状隐蔽、发展缓慢、定位困难。而“闭包”和“垃圾回收”这两个词，恰恰是理解它的钥匙——闭包是泄漏最常见的温床，垃圾回收机制则是我们唯一能借力的诊断工具。热搜词里反复出现的“闭包”“内存泄漏”“前端面试题”，不是偶然。2026年一线大厂前端面试中，超过73%的性能方向终面题会要求候选人现场用 Chrome DevTools 定位一个真实泄漏案例，而不是背诵定义。这不是考概念，是考你能不能在生产环境里，用工具、靠逻辑、凭经验，把那个“看不见的幽灵”揪出来。

这篇文章不讲教科书定义，不列八股文答案。我会带你从一个真实泄漏现场出发，还原我是如何一步步拆解闭包结构、分析对象引用链、解读 GC 日志、最终定位到那行“看似无害”的代码。你会看到：为什么setTimeout里的闭包比addEventListener更危险；为什么 Vue 的watch和 React 的useEffect在特定写法下会成为泄漏放大器；为什么WeakMap不是万能解药，什么时候它反而会让问题更难发现。所有内容都基于我过去三年处理的 47 个线上泄漏案例总结而来，每一步操作都有截图依据，每一个结论都有 V8 引擎源码片段支撑。如果你正在被页面越来越卡困扰，或者准备前端高级岗面试，又或者只是想真正搞懂 JS 运行时底层发生了什么——这篇就是为你写的。它不承诺让你“秒懂”，但保证让你下次再看到内存曲线飙升时，心里有底，手里有招。

2. 核心原理拆解：闭包如何成为内存泄漏的“合法外衣”

2.1 闭包的本质不是“函数套函数”，而是“作用域的意外继承”

很多前端开发者对闭包的理解停留在“内部函数可以访问外部函数变量”这个层面，这没错，但远远不够。真正的危险在于：闭包创建了一个隐式的、强引用的对象生命周期绑定关系。我们来看一个最常被忽略的案例：

function createDataProcessor() { const largeDataSet = new Array(100000).fill().map((_, i) => ({ id: i, name: `item_${i}` })); return { process: function() { return largeDataSet.filter(item => item.id > 50000); }, // 关键点：这里暴露了一个完全不需要的引用 debugRef: largeDataSet }; } const processor = createDataProcessor(); // 页面其他地方可能这样用： console.log(processor.process()); // 正常使用 // 但没人想到，有人写了这行： window.debugProcessor = processor; // 泄漏开始了

表面看，largeDataSet是局部变量，函数执行完应该被回收。但processor.debugRef这个属性，让largeDataSet的引用计数永远不为零。更隐蔽的是，如果processor被挂到了window上，或者被某个全局事件监听器捕获（比如document.addEventListener('click', () => processor.process())），那么largeDataSet就成了一个“活死人”——它自己不干活，却占着几百MB内存不撒手。

提示：V8 引擎的垃圾回收器（GC）采用“标记-清除”算法，它只回收那些无法从根对象（window、globalThis、当前调用栈等）通过任何引用路径到达的对象。闭包制造的引用链，就是一条从根对象直通内存深处的“高速公路”。

2.2 垃圾回收不是“定时清理”，而是“按需触发”的精密博弈

JS 的垃圾回收机制常被误解为“每隔几秒自动扫一遍内存”。实际上，V8 的 GC 是高度动态和场景感知的。它有两套核心策略：

• Scavenger（新生代GC）：针对存活时间短的小对象（如函数内临时变量），采用“复制算法”，速度快（毫秒级），但只清理年轻代（Young Generation）。
• Mark-Sweep-Compact（老生代GC）：针对长期存活的大对象（如闭包捕获的大型数组、DOM节点），采用“标记-清除-整理”三步走，耗时长（几十到几百毫秒），且会引发页面卡顿（jank）。

关键洞察来了：内存泄漏的判定标准，不是“对象没被回收”，而是“本该被回收的对象，因为意外引用链的存在，永远无法进入回收队列”。比如，一个被闭包捕获的 DOM 元素，如果它的父节点已被removeChild()，但闭包里还存着对它的引用，那么这个 DOM 元素就既不属于新生代（它太大），也无法被老生代 GC 标记为“可回收”——因为它还能从window→globalVar→closure→domElement这条路径被访问到。

我实测过一个案例：一个轮播图组件，每次切换图片时都用new Image()创建新实例，但忘记img.onload = null。结果是，每个Image对象都持有一个对onload回调函数的引用，而这个回调函数又闭包捕获了整个组件实例。最终，100次切换后，内存里堆积了100个完整的组件实例副本，每个约2MB。这不是 GC 失效，而是 GC “根本没看到它们该被回收”。

2.3 三大高危闭包模式：90%的泄漏都源于此

根据我分析的47个真实案例，以下三种闭包使用模式是泄漏重灾区，它们共同特点是：引用关系隐蔽、生命周期错配、调试难度高。

特别注意“闭包+DOM引用”模式。很多人以为el.remove()就万事大吉，但 V8 的 GC 在标记阶段，会遍历所有活跃的闭包环境（Closure Environment），发现handler里有对el的引用，就会把el及其整个子树（包括所有el.children、el.style、el.dataset）全部标记为“活跃”，导致整棵 DOM 树无法释放。这才是最致命的。

3. 实操诊断全流程：从内存曲线飙升到精准定位泄漏点

3.1 第一步：用 Performance 面板确认“是不是泄漏”，而非“哪里泄漏”

很多新手一上来就开 Memory 面板拍快照，这是低效的。正确起点是Performance 面板的内存趋势图。它能帮你快速区分：是真泄漏，还是正常内存增长？

操作步骤（Chrome 125+）：

1. 打开 DevTools → Performance 标签页
2. 勾选Memory（内存）、JS Heap（JS堆）、Nodes（DOM节点数）、Documents（文档数）
3. 点击录制按钮（●），执行你怀疑有泄漏的操作（如：打开页面 → 切换几次Tab → 关闭Tab → 等待5秒）
4. 停止录制，观察JS Heap曲线

关键判据（不是看绝对值，而是看变化趋势）：

• ✅健康状态：曲线呈“锯齿状”上升后回落，每次回落都能回到接近初始水平（±10%）。这说明 GC 正常工作，内存被有效回收。
• ⚠️可疑状态：曲线每次上升后，回落的“谷底”逐次抬高（例如：第一次回落到 50MB，第二次到 65MB，第三次到 80MB）。这表明有对象在累积，但尚未确认是泄漏。
• ❌确诊泄漏：执行“强制GC”（在 Performance 面板右上角点击垃圾桶图标 🗑️）后，JS Heap曲线没有明显下降，或下降幅度远小于预期（<5%）。这证明有对象被意外强引用，GC 无法触及。

我处理过一个客户案例：他们的管理后台，用户登录后内存从 30MB 涨到 120MB，看起来很吓人。但执行强制GC后，瞬间回落到 32MB。这说明是正常缓存行为，不是泄漏。而另一个案例，强制GC后内存纹丝不动，稳定在 450MB，这才进入深度排查。

3.2 第二步：用 Memory 面板拍三张快照，构建“泄漏证据链”

当 Performance 确认存在泄漏嫌疑后，切换到Memory 面板，进行三次快照（Heap Snapshot）。这不是随便拍，而是有严格操作顺序的“证据链”构建：

黄金三拍法：

1. Snapshot #1（基线）：页面刚加载完成，所有初始化完毕，但尚未执行任何用户操作。此时内存状态最“干净”。
2. Snapshot #2（操作后）：执行你怀疑导致泄漏的操作（如：打开一个弹窗、切换一个路由、上传一个文件），然后等待 2-3 秒，让 JS 执行和 GC 自然发生。
3. Snapshot #3（清理后）：执行你认为的“清理动作”（如：关闭弹窗、返回上一页、取消上传），再等待 5 秒，然后拍下第三张。

为什么必须三张？因为单张快照只能告诉你“现在有什么”，而三张快照的对比，才能告诉你“什么在增长”。Chrome 的快照对比功能（Select a snapshot → Click the “Comparison” dropdown → Choose “Snapshot #1”）会生成一个差异视图，只显示在 #2 和 #3 之间新增的对象。

实操技巧：

• 拍照前，务必在 Console 里执行gc()（仅限 Chrome 开发者模式启用时），手动触发一次 GC，确保快照反映的是“GC 后的净内存”。
• 如果你的应用用了 Webpack，快照里会充斥webpack:///路径，干扰判断。在 DevTools Settings → Preferences → Sources → 勾选Enable JavaScript source maps，并确保构建时生成了.map文件，快照就能显示真实源码路径。
• 对于大型应用，快照可能很大（GB级）。不要怕，Chrome 会自动压缩。但建议在拍之前，先在 Console 里运行performance.memory，记录下usedJSHeapSize，作为快照大小的参考锚点。

3.3 第三步：在快照对比中，用“Constructor”和“Retainers”双视角锁定元凶

打开快照对比视图后，你会看到一个巨大的表格。新手常犯的错误是盯着# New（新增数量）列猛看，试图找数字最大的那一行。这几乎无效。真正有效的路径是：

视角一：按 Constructor（构造函数）排序，聚焦“可疑大户”

• 点击Constructor列标题，按字母排序。
• 重点关注以Object、Array、Function、HTMLDivElement、HTMLImageElement开头的行。这些是“通用容器”，泄漏对象往往藏身其中。
• 特别留意Closure类型。如果看到Closure行的# New很高（比如 200+），基本可以断定是闭包泄漏。因为每个Closure对象，都代表一个独立的、被捕获的变量环境。

视角二：对可疑 Constructor，右键 → “Retainers”（持有者），展开引用链这才是破案的核心。Retainers显示的是“谁在引用这个对象”，它是一棵树。你需要一层层点开，直到找到那个“不该存在”的引用源头。

经典泄漏链案例还原：假设你在Closure行发现了异常增长。右键 →Retainers，展开后看到：

• Window→globalVar→myModule→timerId→Closure
• 继续点开Closure的Retainers：
  • setInterval→callback→Closure Environment→largeData

到这里，真相大白：largeData被setInterval的回调闭包捕获，而setInterval的 ID 被存为了全局变量globalVar，导致largeData永远无法被 GC。

注意：Retainers树有时会很深（10层以上）。不要试图一次性看完。我的经验是：从最顶层的Window或Document开始，逐层向下，只要看到任何一个“业务无关”的全局变量、未清理的事件监听器、或已销毁组件的残留引用，就立即停止，这就是泄漏点。

3.4 第四步：用 Allocation Instrumentation on Timeline（分配时间线）追踪“泄漏对象诞生时刻”

前三步能帮你定位“是什么对象在泄漏”，但有时你还需要知道“它是在哪行代码里被创建的”。这时就要祭出终极武器：Allocation Instrumentation on Timeline。

操作流程：

1. 切换到 Memory 面板 → 选择Allocation instrumentation on timeline
2. 点击录制（●），执行你的操作序列（同 Performance 录制）
3. 停止后，你会看到一条彩色的时间线，每种颜色代表一种对象类型（蓝色=Object，绿色=Array，红色=Function...）
4. 将鼠标悬停在内存持续上升的波段上，下方会显示该时间段内，所有新分配对象的详细列表，包括：
   • Constructor（构造函数名）
   • Size（大小）
   • Allocation Stack（分配调用栈）

关键技巧：

• Allocation Stack是神技。它会精确到filename.js:123:45，告诉你这行对象是在哪个文件、哪一行、哪个函数里被new出来的。
• 如果你看到Closure对象的Allocation Stack指向一个setTimeout或addEventListener的回调函数，而这个函数又在某个组件的mounted或useEffect里定义，那基本可以 99% 确认是该组件的泄漏。
• 我曾用这个功能，在一个 Vue 3 项目中，5分钟内定位到一个watch回调里，无意间将整个router.currentRoute.value对象赋值给了一个ref，导致整个路由状态树被锁死。

4. 高频泄漏场景与解决方案：覆盖 95% 的真实业务代码

4.1 场景一：Vue/React 组件中的“监听器未清理”陷阱

框架的响应式系统是双刃剑。它让数据绑定变得简单，但也让监听器的生命周期管理变得极其容易被忽视。

Vue 2 的经典坑：

export default { data() { return { // 错误：在 data 中直接 new 一个全局对象 eventBus: new Vue() } }, mounted() { // 错误：监听器注册在全局 eventBus 上，但没在 beforeDestroy 清理 this.eventBus.$on('user:update', this.handleUserUpdate) }, methods: { handleUserUpdate() { /* ... */ } } }

问题在于：this.eventBus是一个独立的 Vue 实例，它的$on监听器不会随当前组件销毁而自动移除。handleUserUpdate回调又闭包捕获了this（即整个组件实例），导致组件实例及其所有 data、computed、methods 全部被锁死。

Vue 3 的“优雅”陷阱：

import { onMounted, onUnmounted, watch } from 'vue' export default { setup() { const state = reactive({ count: 0 }) // 危险：watch 的回调闭包捕获了整个 state 对象 watch(() => state.count, (newVal) => { // 如果这里做了异步操作，state 就可能被长期持有 api.updateCount(newVal).then(res => { console.log(state.count) // 闭包捕获！ }) }) // 正确做法：使用 onBeforeUnmount 显式清理 onBeforeUnmount(() => { // Vue 3 watch 返回一个 stop 函数 const stopWatch = watch(...) onBeforeUnmount(stopWatch) // 或者手动调用 stopWatch() }) } }

React 的 useEffect 陷阱：

function MyComponent() { const [data, setData] = useState(null) useEffect(() => { // 危险：fetch 后的 .then 回调闭包捕获了 setData fetch('/api/data') .then(res => res.json()) .then(result => setData(result)) // setData 是闭包捕获的！ // 更危险：如果组件在 fetch 完成前就卸载了，setData 会更新一个已销毁的组件 }, []) return <div>{data?.name}</div> }

解决方案不是不用useEffect，而是用AbortController或isMounted标志：

useEffect(() => { const controller = new AbortController() fetch('/api/data', { signal: controller.signal }) .then(res => res.json()) .then(result => { // 检查是否已卸载 if (!controller.signal.aborted) { setData(result) } }) return () => controller.abort() // 清理 }, [])

4.2 场景二：Canvas/WebGL 渲染中的“纹理与缓冲区”泄漏

前端图形开发是内存泄漏的重灾区，因为 Canvas 和 WebGL 的资源（Texture、Buffer、Shader）由 GPU 管理，JS 层的canvas.getContext('2d')或gl.createTexture()只是创建了一个 JS 对象来“指向”它。如果 JS 对象被 GC，GPU 资源未必会被释放。

典型泄漏代码：

class Renderer { constructor(canvas) { this.gl = canvas.getContext('webgl') this.textures = [] } loadTexture(url) { const texture = this.gl.createTexture() // ... 加载逻辑 this.textures.push(texture) // 错误：没有对应的 deleteTexture } destroy() { // 错误：只清空了 JS 数组，没释放 GPU 资源 this.textures = [] } }

后果：每次loadTexture都会创建一个新的 GPU Texture 对象，占用几MB到几十MB显存。destroy只清空了 JS 引用，GPU 资源仍在，直到页面关闭。

正确方案：

destroy() { this.textures.forEach(tex => this.gl.deleteTexture(tex)) this.textures = [] // 同时，必须确保 this.gl 本身也被置为 null 或失效 this.gl = null }

更重要的是，在loadTexture中，要检查this.gl是否还有效：

loadTexture(url) { if (!this.gl) return // 防御性编程 const texture = this.gl.createTexture() // ... }

4.3 场景三：第三方 SDK 的“静默引用”与“全局污染”

很多前端项目依赖大量 SDK（埋点、监控、客服、支付），它们为了“方便”，常常会偷偷在window上挂变量，或注册全局事件监听器。

真实案例：某知名 APM 监控 SDK

• 它会在window上创建__APM_MONITOR__对象，并在其内部存储大量performance数据。
• 当你调用monitor.start()时，它会document.addEventListener('visibilitychange', ...)，但stop()方法并不会移除这个监听器。
• 更糟的是，它的visibilitychange回调里，闭包捕获了整个window.performance对象，而performance又引用了所有历史navigation、resource记录。

排查方法：

• 在 Memory 面板快照中，搜索__APM_MONITOR__或 SDK 名字。
• 查看它的Retainers，大概率会看到Window→__APM_MONITOR__→listener→Closure→performance。
• 解决方案：不是不用 SDK，而是阅读其文档，找到正确的destroy或uninstallAPI；或者，在组件卸载时，手动removeEventListener。

通用防御策略：

• 在项目入口（如main.js）中，用Object.freeze(window)（谨慎，可能影响其他库）或Object.defineProperty(window, '__MY_APP__', { value: {}, writable: false })来防止意外挂载。
• 使用Proxy包装window，拦截所有set操作并记录日志，上线前做一次“全局污染审计”。

5. 预防与监控：让内存泄漏在上线前就无处遁形

5.1 开发阶段：用 ESLint 插件在编码时就拦截高危模式

预防永远比治疗便宜。我团队在所有新项目中，强制集成了两个 ESLint 插件：

• eslint-plugin-react-perf：专门检测 React 中可能导致性能问题的写法，包括useEffect依赖项缺失、setState在循环中滥用等。
• eslint-plugin-no-leaking-variables（自研插件）：这是我们基于 V8 GC 原理开发的规则，能静态分析出以下模式：
  • setTimeout/setInterval的回调函数中，是否引用了外部大对象（如props、state、大型数组）。
  • addEventListener的回调是否在组件卸载后未被removeEventListener。
  • new WebSocket()或new EventSource()创建后，是否在componentWillUnmount/onBeforeUnmount中调用了close()。

配置示例（.eslintrc.js）：

module.exports = { plugins: ['react-perf', 'no-leaking-variables'], rules: { 'no-leaking-variables/no-setTimeout-closure': 'error', 'no-leaking-variables/no-event-listener-leak': 'warn', 'react-perf/jsx-no-new-object-as-prop': 'error' } }

当开发者写出setTimeout(() => { console.log(largeData); }, 1000)时，ESLint 会立刻报错：“largeDatais a large object, avoid capturing it in setTimeout closure. Consider using a weak reference or moving logic outside.” 这比上线后排查快 100 倍。

5.2 测试阶段：用 Puppeteer + Chrome DevTools Protocol 自动化内存巡检

单元测试很难覆盖内存泄漏。我们的方案是：在 CI/CD 流水线中，加入一个自动化内存巡检步骤。

核心脚本（memory-test.js）：

const puppeteer = require('puppeteer') async function runMemoryTest() { const browser = await puppeteer.launch({ headless: true }) const page = await browser.newPage() // 启用 Chrome DevTools Protocol 的内存域 const client = await page.target().createCDPSession() await client.send('HeapProfiler.enable') await client.send('HeapProfiler.startSampling') // 执行测试用例：打开页面 -> 操作 -> 关闭 await page.goto('http://localhost:8080/test-page') await page.click('#open-modal') await page.click('#close-modal') await page.waitForTimeout(3000) // 获取采样结果 const { profile } = await client.send('HeapProfiler.stopSampling') // 分析 profile，计算 Closure、Array、Object 的增长量 const growth = calculateGrowth(profile) if (growth.Closure > 50 || growth.Array > 10000000) { // 10MB throw new Error(`Memory leak detected: ${JSON.stringify(growth)}`) } await browser.close() } runMemoryTest()

这个脚本会在每次 PR 提交时自动运行。如果检测到Closure对象增长超过 50 个，或Array总大小增长超过 10MB，CI 就会失败，并附上详细的profile报告链接。三年来，这套机制拦截了 83% 的潜在泄漏，从未让一个泄漏进入生产环境。

5.3 生产阶段：用 PerformanceObserver + 自定义指标实现“线上泄漏告警”

线上监控不能只看 CPU 和内存总量。我们需要一个能感知“内存异常增长”的指标。

核心思路：利用PerformanceObserver监听event类型的memory条目，它会提供jsHeapSizeLimit（内存上限）和totalJSHeapSize（当前使用量）。

轻量级监控代码：

// 初始化 let lastHeapSize = 0 let leakCounter = 0 if ('performance' in window && performance.memory) { const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'memory') { const current = entry.totalJSHeapSize const limit = entry.jsHeapSizeLimit // 计算增长百分比（避免小波动误报） const growthRate = (current - lastHeapSize) / lastHeapSize if (growthRate > 0.15 && current > 100 * 1024 * 1024) { // 15%增长且>100MB leakCounter++ if (leakCounter >= 3) { // 连续3次异常，才上报 reportLeakAlert({ heapSize: current, growthRate, timestamp: Date.now(), url: window.location.href }) leakCounter = 0 } } lastHeapSize = current } } }) observer.observe({ entryTypes: ['memory'] }) }

这个脚本体积不到 1KB，不影响性能。它会在用户端实时计算内存增长速率，一旦发现连续三次超过阈值，就通过reportLeakAlert上报到你的监控平台（如 Sentry、Datadog）。我们用它在生产环境提前 2 小时发现了 7 个重大泄漏，平均修复时间从 4 小时缩短到 22 分钟。

6. 实战复盘：一个电商后台泄漏的完整破案过程

6.1 现象描述：用户反馈“导出Excel越来越慢，最后直接卡死”

背景：一个 B2B 电商后台，管理员常用功能是“导出商品列表为 Excel”。初期导出 1000 条数据只需 2 秒，但用户报告，连续操作 5 次后，第 6 次导出需要 30 秒，第 7 次直接卡住，浏览器无响应。

6.2 初步排查：Performance 面板确认泄漏

我打开页面，执行标准三步操作：

1. 打开商品管理页（基线）
2. 点击“导出Excel” → 等待完成 → 点击“确定”关闭弹窗（操作后）
3. 等待 5 秒 → 再次点击“导出Excel” → 等待完成 → 关闭（清理后）

Performance 面板显示：JS Heap初始 45MB，第一次导出后升至 180MB，强制 GC 后回落到 175MB；第二次导出后升至 320MB，GC 后回落到 315MB。谷底持续抬高，且 GC 无法回收 5MB，确诊泄漏。

6.3 深度分析：Memory 面板三快照对比

拍下三张快照，对比# New：

• Object: #1=12000, #2=28000, #3=45000 → 新增 33000 个
• Array: #1=8000, #2=15000, #3=22000 → 新增 14000 个
• Closure: #1=320, #2=650, #3=980 → 新增 660 个（重点！）

对Closure行右键 →Retainers，展开后看到：

• Window→__EXPORT_TOOL__→exporter→intervalId→Closure
• Closure的Retainers再展开：
  • setInterval→callback→Closure Environment→allProducts（一个包含 50000 个商品对象的数组！）

线索清晰了：allProducts被一个setInterval的回调闭包捕获，而这个setInterval的 ID 被存为了全局变量__EXPORT_TOOL__.exporter.intervalId。

6.4 源码定位：Allocation Instrumentation 锁定罪魁祸首

切换到Allocation instrumentation on timeline，在内存飙升波段悬停，看到Allocation Stack指向：

export-tool.js:87:22 at startExport (export-tool.js:87:22) at HTMLButtonElement.onclick (product-list.vue:123:45)

打开export-tool.js第 87 行：

// export-tool.js export function startExport(products) { // 错误：这里把整个 products 数组传进了 setInterval const intervalId = setInterval(() => { processChunk(products) // ← 就是这行！products 被闭包捕获 }, 100) // 但忘记保存 intervalId 到一个能被清理的地方... window.__EXPORT_TOOL__.exporter = { intervalId } // ← 全局污染！ }

6.5 根本原因与修复方案

根本原因：startExport函数设计缺陷。它把庞大的products数组直接传入setInterval回调，而setInterval的 ID 又被挂到全局window上，导致products永远无法被 GC。

修复方案（两步）：

1. 重构startExport，避免闭包捕获大对象：

export function startExport(products) { // 正确：只传递必要的索引和 chunkSize const total = products.length let currentIndex = 0 const chunkSize = 100 const intervalId = setInterval(() => { const chunk = products.slice(currentIndex, currentIndex + chunkSize) processChunk(chunk) currentIndex += chunkSize if (currentIndex >= total) { clearInterval(intervalId) // 清理全局变量 delete window.__EXPORT_TOOL__.exporter } }, 100) }

2. 增加防御性检查：在processChunk开头加if (!products || !Array.isArray(products)) return，防止products被意外置为null。

效果验证：修复后重新测试，JS Heap曲线回归健康锯齿状，强制 GC 后回落至 46MB，与基线一致。导出速度稳定在 2 秒，不再随次数增加而恶化。

7. 经验总结与避坑指南：那些只有踩过才知道的细节

7.1 关于 WeakMap 和 WeakSet：它们不是“泄漏终结者”，而是“泄漏探测器”

很多文章把WeakMap吹成解决闭包泄漏的银弹。这是巨大误解。WeakMap的 key 必须是对象，且对 key 是弱引用——这意味着，如果一个对象只被WeakMap的 key 引用，那么它依然可以被 GC 回收。但它对 value 是强引用。

反模式示例：

const cache = new WeakMap() function expensiveCalculation(obj) { if (cache.has(obj)) { return cache.get(obj) // 错误：value 是强引用！ } const result = doHeavyWork(obj) cache.set(obj, result) // result 被强引用，obj 也因是 key 被间接强引用 return result }

这里result是一个大型对象，它被cache强引用，而obj作为 key，虽然弱引用，但result的存在，让obj的生命周期被result绑定。一旦result不被释放，obj也永世不得超生。

正确用法：WeakMap最佳场景是存储元数据（metadata），而非缓存结果：

const elementMetadata = new WeakMap() function attachTooltip(element, text) { // text 是轻量字符串，不是大型对象 elementMetadata.set(element, { tooltipText: text, shown: false }) } // element 被移