应立即排查内存泄漏：检查未解绑事件监听器、闭包持有dom、全局变量未清理、第三方实例重复创建；用chrome内存快照对比detached dom和重复构造函数；采用虚拟滚动、复用canvas上下文、iframe隔离第三方脚本。

页面内存持续上涨，performance.memory 显示 usedJSHeapSize 越来越大怎么办

直接看 performance.memory.usedJSHeapSize 是最快速的判断依据。如果它随滚动、切换、反复操作持续增长（比如每次点击增加 2–5 MB），基本可确认存在内存泄漏，不是“页面大所以吃内存”的合理现象。

常见诱因是事件监听器未解绑、闭包持有 DOM 引用、全局变量缓存未清理、第三方库（如图表、编辑器）实例重复创建但没销毁。

• 用 chrome://inspect → Memory → “Take heap snapshot” 对比操作前后的快照，筛选 Detached DOM tree 或重复出现的构造函数（如 Chart、Editor）
• 监听器必须配对移除：element.addEventListener('click', handler) 后，销毁时务必调用 element.removeEventListener('click', handler)；匿名函数无法移除，别这么写
• Vue/React 组件中，mounted / useEffect 里添加的定时器、事件、观察者，必须在 unmounted / 依赖数组为空的清理函数里清除

大量 DOM 节点导致内存飙升，但又不能删减内容怎么办

DOM 节点本身不占多少内存，但每个节点附带样式计算、布局信息、事件绑定、JS 引用链后，1 万个 div 可能吃掉 80+ MB。真实瓶颈不在“有没有”，而在“是否全量挂载且活跃”。

虚拟滚动（virtual scrolling）是唯一靠谱解法：只渲染视口内 + 少量缓冲区的节点，其余用空白占位元素撑开滚动高度。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 原生可用 IntersectionObserver + 手动控制 display: none 或 remove()，但注意避免频繁重排；更推荐用成熟方案如 vue-virtual-scroller 或 react-window
• 慎用 innerHTML = longString 一次性插入数万节点；改用 document.createDocumentFragment() 批量构建再 append，减少重排次数
• 避免给每个列表项绑定独立 onclick，改用事件委托：listEl.addEventListener('click', e => { if (e.target.matches('.item')) {...} })

Canvas 或 WebGL 渲染后内存不释放，canvas.getContext('2d') 持续占着怎么办

getContext 返回的上下文对象会强引用 canvas 元素及其像素数据，即使 canvas 从 DOM 移除、变量置为 null，若上下文仍被闭包持有，内存就无法回收。

• 显式调用 context.clearRect(0, 0, canvas.width, canvas.height) 清空像素数据（尤其大图绘制后）
• 不再使用时，手动断开引用：context = null; canvas.width = 1; canvas.height = 1;（设回 1×1 可强制释放底层纹理）
• WebGL 场景下，必须手动调用 gl.deleteTexture、gl.deleteBuffer 等，浏览器不会自动回收 GPU 资源
• 避免在 requestAnimationFrame 回调中反复 getContext——复用已有 context，不要每次都取

第三方 SDK（如埋点、客服、广告）悄悄吃内存，怎么排查和限制

这类脚本往往不暴露清理接口，自行维护长生命周期对象、轮询定时器、监听全局事件，且代码压缩混淆，很难直接 debug。但可通过加载方式和运行沙箱约束其影响范围。

• 用 iframe 加载非核心第三方脚本（如客服浮窗），设置 sandbox="allow-scripts" 并限定域名，主页面内存不受其直接影响
• 动态加载后记录 script 标签引用，需要时可 script.remove() + 清理其注入的全局变量（如 window._qmsg = undefined），但需提前查清 SDK 的卸载方法（有些提供 destroy()）
• 限制其执行时间：用 setTimeout(() => { /* 加载逻辑 */ }, 0) 延迟加载，或监听 visibilitychange，页面隐藏时暂停其定时器（部分 SDK 支持 pause()）

内存问题最难缠的不是“爆了”，而是“缓慢爬升+偶发卡顿”——它往往混在正常业务逻辑里，等用户反馈才察觉。真正关键的不是堆大小数字，而是引用链是否可控、资源生命周期是否明确。一旦发现某类操作后内存不回落，立刻截快照、找 Detached、查闭包，别等它变成线上事故。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！