必须按需加载、严格控制执行顺序、避免全局污染：通过特性检测（如if (!window.Promise)）判断缺失API，同步前置加载，防冲突，并对SharedArrayBuffer等无法polyfill的功能降级处理。
旧版浏览器 Polyfill 不能“一股脑全加”，必须按需加载、严格控制执行顺序、避免全局污染——否则轻则白跑几 KB JS，重则 Promise 被覆盖、fetch 报错、表单逻辑崩坏。
如何判断哪些 API 真的需要 polyfill
别看浏览器版本号决定要不要加，得用特性检测。比如 window.Promise 在 IE11 里存在但不支持 Promise.allSettled，window.fetch 在 IE 全系是 undefined，而 IntersectionObserver 在 IE 和旧 Android WebView 里直接报 ReferenceError。
- 优先检查全局对象属性是否存在：用
if (!window.AbortController)而不是if (isIE) - 某些 API 需更深检测：比如
input.type = 'date'后再查input.showPicker是否为函数，Safari 14 返回'date'但点不开日历 - HTML 标签类（如
<dialog>）没法靠 JS 检测是否渲染正常，得结合document.createElement('dialog').offsetHeight === 0这类 DOM 行为试探
加载顺序和执行时机怎么卡死
Polyfill 必须在任何业务代码之前同步执行，尤其涉及全局构造函数（Promise、fetch）的，晚了就来不及劫持。
-
<script>标签不能加async或defer，必须放在<head>最顶部或<body>开头 - 用 Webpack 打包时，别
import 'core-js/stable'在某个模块里——它得在入口文件第一行，且确保core-js的 UMD 版本被实际打包进 initial chunk - 像
html5shiv这种 DOM 前置依赖，必须用条件注释只给 IE8- 加载：<!--[if lt IE 9]><script src="html5shiv.min.js"></script><![endif]-->，且必须在任何 CSS<link>之前
多个 polyfill 共存时怎么防冲突
重复定义同一个全局 API 是最常见崩坏点，比如 es6-promise 和 core-js/stable/promise 同时加载，会导致 Promise.all() 返回值类型异常或 catch 不触发。
立即学习“前端免费学习笔记（深入）”；
- 查清每个 polyfill 的“补丁范围”：whatwg-fetch 只补
window.fetch，不碰Promise；但core-js默认全量补，要用core-js/stable/promise这种子路径按需引入 - 避免混用不同体系：不要同时引
@webcomponents/webcomponentsjs和document-register-element，后者已废弃且会覆盖前者注册逻辑 - 用
polyfill.io时注意 UA 字符串精度——它返回的脚本可能包含你根本不需要的模块（比如给 Chrome 90+ 返回Array.prototype.flat），反而增加解析开销
哪些东西根本没法 polyfill，得降级处理
别浪费时间找“完美 polyfill”，有些能力是宿主环境硬限制，强行模拟只会埋雷。
-
SharedArrayBuffer和Atomics：无安全可行方案，检测到不支持就得切回单线程轮询或禁用并发计算 -
Web Workers：IE9 及以下完全没Worker构造函数，polyfill 只能 fallback 到setTimeout分片，但无法真正并行 -
<dialog>和customElements.define()：IE 全系无可靠实现，@webcomponents/webcomponentsjs在 IE11 下也仅支持基础注册，生命周期钩子（connectedCallback）常丢失，建议直接用div+ 手动事件绑定降级
真正难的不是找到 polyfill，而是厘清“哪些行为必须由 JS 模拟”“哪些功能干脆砍掉更稳”——比如 input[type="date"] 在 Safari 14 上点不开，与其塞一个 full-size 日期组件，不如检测后换 type="text" + flatpickr 并统一服务端校验逻辑。
