HTML页面本身不支持内存消耗操作，所谓内存占用实为浏览器解析渲染及脚本执行中JS引擎、DOM树等机制引发；优化核心在于控制JS行为与资源生命周期。
HTML 页面本身不支持“内存消耗”这个操作——它没有内存分配、释放或监控的原语；所谓“HTML 页面消耗内存”，其实是浏览器在解析、渲染、执行脚本过程中，由 JavaScript 引擎、DOM 树、CSSOM、渲染管线等底层机制引发的内存占用。想控制或替代“内存消耗”，本质是优化 JS 行为与资源生命周期。
为什么 document.createElement 多次调用会悄悄吃内存
每次调用 document.createElement 创建节点，若未显式移除或未被 GC 回收，就可能滞留 DOM 树中；更隐蔽的是，绑定过事件监听器（尤其用匿名函数）、附带闭包引用、或通过 dataset 存了大对象，都会阻止垃圾回收。
- 真实场景：表格无限滚动中反复
appendChild新行，但旧行没remove()也没用innerHTML = ''清空父容器 - 验证方式：打开 Chrome DevTools → Memory 面板 → 拍摄堆快照，筛选
Detached HTMLDivElement类型，数量异常高即存在泄漏 - 安全做法：优先复用节点（
DocumentFragment或池化），移除前手动解绑removeEventListener，避免对全局对象或长生命周期对象形成强引用
JSON.parse 大字符串后不释放，比想象中更难 GC
看似无害的一行 const data = JSON.parse(largeJsonString)，如果 data 被意外保留在闭包、全局变量、或作为某个对象的属性长期持有，V8 就无法回收整个解析后的对象图——尤其当其中含 Date、RegExp、嵌套数组等非纯数据结构时，GC 压力更大。
- 典型陷阱：把 API 返回的完整响应体缓存进
window.cache，后续只取cache.items[0]，却忘了清空原始大对象 - 缓解策略：用
structuredClone（需检查浏览器支持）做浅层裁剪；或直接用JSON.parse配合 reviver 函数边解析边过滤字段，避免生成全量对象 - 注意点：
JSON.stringify后再parse并不能释放原始内存——只是多建了一次副本，原对象仍存活
用 WeakMap 和 WeakRef 替代“手动内存管理”
JavaScript 没有 malloc / free，但 WeakMap 和 WeakRef 提供了弱持有能力，是目前最接近“替代内存消耗”的语言级方案：它们不阻止目标对象被 GC，适合做元数据关联或临时缓存。
立即学习“前端免费学习笔记（深入）”；
-
WeakMap键必须是对象，值可以是任意类型；常用于给第三方 DOM 节点挂载私有状态，而无需担心泄漏 -
WeakRef+deref()适合持有可选依赖，比如一个计算结果缓存，允许底层数据被回收后自动失效 - 限制很明确：二者都不能遍历，也不能防止主对象被回收；不要试图用
WeakRef保活对象——那是反模式
真正难的不是写个 freeMemory() 函数，而是识别哪些引用链是隐式的、跨模块的、或由第三方库悄悄建立的。现代前端框架（React/Vue）内部已大量使用 WeakMap 管理实例状态，但业务代码里仍常见 addEventListener 忘卸载、setTimeout 闭包持有了整个组件作用域、或用 Object.assign({}, hugeObj) 做深拷贝却不释放源对象——这些细节，才是内存问题反复出现的根因。
