冗余 polyfill 占用指新版浏览器已原生支持 es2015+ 等特性，但网站仍无条件加载全量 polyfill（如 core-js），导致内存驻留、执行损耗和泄漏；需通过任务管理器、memory 堆快照比对、network/sources 检查及 performance 录制交叉验证识别。
新版浏览器普遍已原生支持 ES2015+、IntersectionObserver、ResizeObserver、AbortController 等特性，但很多网站仍通过构建工具（如 Webpack、Vite）或 CDN 加载完整 polyfill 包（如 core-js、@babel/polyfill），导致重复加载、无用代码执行和内存驻留——这些就是典型的“冗余 polyfill 占用”。识别它不靠猜测，而要结合运行时行为与资源快照交叉验证。
看任务管理器里有没有“静默高内存”的 polyfill 进程
打开 Chrome 或 Edge 的内置任务管理器（Shift + Esc），重点关注类型为“标签页”的条目：
- 按“内存”列排序，找到内存占用明显高于同站其他页的页面（例如 >120MB）；
- 右键该标签页 → “检查”，在 Console 中输入
self.__core-js-shared__或typeof Promise、typeof IntersectionObserver，确认浏览器本就支持却仍加载了 polyfill； - 若发现
core-js相关全局变量存在，且页面未做特性检测就直接 import 全量包，基本可判定为冗余加载。
用 Memory 面板比对堆快照中的 polyfill 对象残留
在开发者工具中打开 Memory 面板，执行三次操作：
- 首次：刚加载完页面，点击 Take snapshot（堆快照）；
- 第二次：滚动、切换 Tab、触发懒加载等典型交互后，再拍一张；
- 第三次：等待 5–10 秒（让 GC 自动运行），再拍一张。
切换到 Comparison 视图，筛选构造函数名含 Promise、Map、Set、WeakMap 或 core-js 的对象。若这些对象在第三张快照中仍大量存在、且数量持续增长，说明 polyfill 创建的代理对象未被回收——这是执行损耗叠加内存泄漏的典型信号。
查 Network 和 Sources，确认 polyfill 是否被无条件注入
刷新页面，打开 Network 面板，过滤 .js 请求，重点观察：
- 是否存在
polyfills.js、vendor.js、core-js-bundle.js等命名文件，且体积 >150KB； - 该文件是否在
中通过<script></script>同步加载（而非动态 import 或特性检测后加载）； - 点开该 JS 文件，在 Sources 面板中搜索
IntersectionObserver、AbortSignal等关键词——若源码中包含完整重写逻辑，而当前浏览器已原生支持，则属冗余。
用 Performance 面板抓取主线程阻塞点
在 Performance 面板中录制 3–5 秒页面加载过程，关注以下区域：
- 在“Main”轨道中查找长任务（>50ms），展开后看调用栈是否频繁出现
core-js/modules/或es.promise路径； - 查看“Bottom-Up”视图，排序后若
Parse HTML或Function Call下有大量 polyfill 相关函数排在前列，说明初始化阶段就在做无意义补丁； - 特别留意首次绘制（FP）和首次内容绘制（FCP）前的 JS 执行耗时——如果 polyfill 占据其中 30% 以上，就构成可感知的执行损耗。
真正有效的 polyfill 应该是按需、惰性、可丢弃的。一旦发现它在现代浏览器里常驻内存、反复构造、阻塞主线程，就该从构建配置中移除全量包，改用 core-js/stable + features 按需引入，或用 usage 模式由 Babel 自动注入。
