Chrome真实内存压力需综合JS堆、Performance面板内存轨线及task-manager私有内存三类数据；requestIdleCallback在低端Android上常失效，应改用setTimeout限频+IntersectionObserver；Webpack需防多实例缓存；React中useEffect cleanup引用过期props会导致闭包泄漏。
怎么看 Chrome DevTools 里真实的内存快照差异
直接看 Memory 面板的「堆快照（Heap Snapshot）」不等于真实内存压力——它只反映 JS 堆，漏掉渲染进程、WebAssembly 模块、图像解码缓冲区、CSSOM 树等。真要评估基准线，得结合三类数据：JS 堆大小、Performance 面板中「内存」轨线（含 native memory）、以及任务管理器里对应渲染进程的私有内存（Private Memory）。
实操建议：
- 在 Chrome 地址栏输入
chrome://task-manager，勾选「Memory footprint」和「Network」列，按「Process」排序，找到你的页面对应渲染进程（通常含 URL 片段） - 用
Performance面板录制 30 秒空闲 + 交互（如滚动、切换 tab），启用「Memory」复选框，导出 JSON 后重点关注usedJSHeapSize和totalJSHeapSize的波动峰值，而非平均值 - 对比不同设备时，必须关闭所有无关标签页、禁用所有非必要扩展（尤其广告拦截类），否则
chrome://task-manager数值会严重失真
为什么 requestIdleCallback 在低端 Android 上几乎没用
它依赖浏览器主线程空闲调度，但低端设备上 UI 线程常被强制同步渲染（如强制重排、CSS 动画帧抖动）、或被 WebView 内核 bug 导致回调永不触发。实测发现部分 Android 8–10 的系统 WebView 中，requestIdleCallback 超过 5 秒未执行即被丢弃，且无 fallback 机制。
替代方案更可靠：
立即学习“前端免费学习笔记（深入）”；
- 对非紧急任务（如日志上报、非关键 DOM 清理），改用
setTimeout(fn, 0)+performance.now()手动限频：每 200ms 最多执行一次，避免连续抢占 - 用
IntersectionObserver替代 scroll 事件监听图片懒加载，减少帧率压力；注意设置rootMargin要足够大（如"200px"），否则低端机因布局计算慢，元素可能已划出视口才触发 - 对需批量处理的数据结构（如大型列表虚拟滚动中的缓存 Map），主动在
beforeunload或路由离开前调用map.clear()，别等 GC —— V8 在内存紧张时可能延迟回收
Webpack 构建产物里哪些 chunk 会悄悄吃掉首屏内存
不是体积大的 chunk 就最耗内存，而是那些带大量闭包引用、或动态 import 后未正确释放的模块。典型陷阱是：一个 utils.js 被 10 个页面异步加载，但内部维护了全局 cacheMap = new Map()，结果每个 chunk 实例都持有一份独立缓存，且无法被 GC。
排查与优化要点：
- 用
webpack-bundle-analyzer查看模块依赖图，重点标出被多个 entry 异步引用的工具模块；对这类模块，把缓存逻辑抽到单独的shared-cache.js并设为entry，确保单例 - 检查
SplitChunksPlugin配置：避免minSize: 10000这类硬阈值，改用cacheGroups按路径/正则拆分，防止小而散的工具函数被塞进 vendor chunk 又无法复用 - 在
module.rules中为.js添加parser: { requireEnsure: false }（若不用动态 require），可减少 Webpack 注入的 module wrapper 闭包层级，降低初始堆开销
React 应用里哪些 hook 用法会让内存泄漏从“偶发”变“必现”
useEffect 不配 return cleanup 是常识，但更隐蔽的是：在 cleanup 函数里引用了过期的 props 或 state，导致整个组件闭包无法释放。比如在定时器清理中用了 props.onSuccess，而该函数来自父组件重渲染，就会把父组件实例也钉在内存里。
安全写法的关键约束：
- 所有异步副作用（
setTimeout、fetch、addEventListener）的 cleanup 必须用ref存储取消信号（如AbortController或布尔标志），而不是依赖闭包变量 - 避免在
useCallback依赖数组里写[state]—— 若 state 是对象，每次更新都会生成新引用，导致子组件无法 memo；应改用useReducer或useMemo缓存派生值 - 自定义 hook 返回的函数，如果内部闭包了 props/state，必须显式文档化“调用者需自行管理生命周期”，否则业务方大概率漏写 cleanup
真正卡住基准线的，往往不是某一行代码，而是跨层引用链：一个滚动监听器 → 持有组件实例 → 持有 Redux store subscription → 持有整个 state 树。查的时候别只盯着堆快照顶部的“大对象”，先顺着 retained size 往下钻三级引用链，再决定砍哪一刀。
