JavaScript内存泄漏是本该回收的对象因引用未断开而滞留内存，导致堆内存持续上涨、页面卡顿甚至崩溃；常见原因包括事件监听器未解绑、定时器未清除、DOM节点残留引用及异步操作生命周期错配。
JavaScript内存泄漏不是“内存用多了”，而是本该被回收的对象，因为某些引用没断开，一直卡在内存里不释放——堆内存持续上涨，页面越来越卡，最终可能崩溃。
为什么 addEventListener 不配对 removeEventListener 就会泄漏
事件监听器本身是个函数，它闭包里可能引用着组件实例、大数组、图片数据等。一旦DOM元素被移除（比如弹窗关闭、路由跳转），但监听器还挂着，整个闭包链就动不了——GC无法回收，泄漏就发生了。
- 常见错误：用匿名函数绑定，导致无法解绑：
el.addEventListener('click', () => {...}) - 正确做法：用具名函数或保存监听器引用，卸载时显式清除
- Vue中在
onBeforeUnmount里统一清理；React中在useEffect返回函数里调用removeEventListener - 更省心方案：优先加
{ once: true }，适合只触发一次的场景
为什么 setInterval 忘记 clearInterval 是高频雷区
定时器回调函数会持有其定义时的作用域变量。哪怕页面已经跳走、组件早已销毁，只要定时器还在跑，这些变量就永远被“钉”在内存里——尤其是每秒执行一次的轮询，几小时下来可能吃掉几十MB。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 错误写法：
setInterval(() => doSomething(), 1000)，没存ID，无从清理 - 正确写法：
const timer = setInterval(...);，并在退出逻辑中调用clearInterval(timer) - 单页应用中，建议把所有定时器ID集中存在组件实例或Ref里，统一销毁
- 替代思路：用
setTimeout递归调用，每次执行完再决定是否继续，控制更精细
为什么 DOM 节点移除了，内存还下不去
这是典型的“僵尸DOM”：你调了 el.remove() 或清空了 parent.innerHTML，但JS里还留着 const btn = document.getElementById('submit') 这样的引用。浏览器看到还有JS变量指着它，就不敢回收整棵子树（包括样式、事件、子节点）。
- 典型现象：Memory 面板里出现大量
Detached HTMLDivElement类型对象 - 修复动作很简单：移除DOM后，立刻把对应变量设为
null，比如btn = null - 进阶方案：用
WeakMap存关联数据（键是DOM节点），节点被回收时，值自动失效；或用WeakRef+FinalizationRegistry做兜底 - 特别注意第三方库：ECharts、地图SDK等常内部缓存DOM，组件销毁前务必调用
dispose()或destroy()
最隐蔽的泄漏往往不在代码逻辑里，而在生命周期管理的“缝隙”中——比如异步请求返回时组件已卸载，回调里又更新了状态；或者Web Worker创建后没 terminate()。这些地方没有报错，但内存会缓慢爬升。定期用 Chrome 的 Memory 面板录三次快照对比，比等用户反馈“页面卡了”要早得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
