Polyfill 在 IE8–11 中需严格控制加载时机、检测顺序与执行环境：html5shiv 必须条件注释同步置于 head 顶部；fetch/Promise/AbortController 需链式检测并同步注入；dialog-polyfill 须 DOM ready 后注册；Custom Elements 和 template 无可靠 polyfill，应降级处理。
官方 Polyfill（如 @webcomponents/webcomponentsjs、dialog-polyfill、whatwg-fetch）不是“加一个 script 就完事”，必须卡准加载时机、检测逻辑和执行顺序，否则在 IE8–11 中大概率白引入甚至引发脚本错误。
html5shiv 必须用条件注释 + 同步加载
IE8 及以下根本不会解析 <header> 标签，html5shiv 的作用只是提前调用 document.createElement() 让这些标签进入 DOM，但它不处理样式、语义或表单属性。
- 必须放在
<head>最顶部，且在任何 CSS 和 JS 之前 - 只能用 IE 条件注释触发：
<!--[if lt IE 9]><script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv.min.js"></script><![endif]--> - 即使用了
html5shiv，CSS 中仍要显式写：header, section, article, nav, footer { display: block; }—— IE 默认把未知标签当 inline 元素 - Webpack 等打包工具中不能
import 'html5shiv'，它依赖全局document，得改用html5shiv-printshiv并确保执行早于 HTML 解析
fetch / Promise / AbortController 要链式检测 + 同步注入
fetch 在 IE 全系原生缺失，Babel 转译完全无效；且 fetch 依赖 Promise，而 AbortController 又是独立缺失项，三者缺一都会导致请求逻辑崩溃。
- 检测顺序不能错：
if (!window.Promise)→ 加载core-js/stable/promise（UMD 版），别用 ESM；if (!window.fetch)→ 加载whatwg-fetch；再if (!window.AbortController)→ 加载abortcontroller-polyfill -
whatwg-fetch必须同步加载（不能加async或defer），否则业务代码执行时会报fetch is not defined - 如果项目已用
axios，通常不用额外加fetchpolyfill —— 它内部 fallback 到 XHR，但注意withCredentials默认行为与原生fetch不一致 - 多个 polyfill 共存时（如
es6-promise+core-js），需确认是否重复定义Promise，否则Promise.allSettled行为可能异常
dialog-polyfill 注册前必须确保 DOM 已就绪
<dialog> 在 IE 全系、Edge ≤18 中无 DOM 接口支持，dialog-polyfill 是目前唯一可用的模拟方案，但它依赖真实 <dialog> 元素存在，且注册时机稍晚就会失败。
立即学习“前端免费学习笔记（深入）”；
- HTML 结构必须先写好：
<dialog id="myDialog">...</dialog>，不能靠 JS 动态插入后才注册 - 注册必须在 DOM ready 后执行：
document.addEventListener('DOMContentLoaded', () => { dialogPolyfill.registerDialog(document.getElementById('myDialog')); }); -
dialog-polyfill会插入一个相邻的.backdrop元素模拟::backdrop，CSS 中不能只写伪元素，得同时覆盖该 class - 不要在 Webpack 中
import dialogPolyfill from 'dialog-polyfill'—— IE11 不支持 ESM，得用<script src="dialog-polyfill.js"></script>方式引入 UMD 版本
Custom Elements 和 template 没有可靠 polyfill，该降级就降级
CustomElementRegistry 和 HTMLTemplateElement 在 IE 中完全不存在，@webcomponents/webcomponentsjs 的 polyfill 实际上只是“让代码不报错”，无法真正实现生命周期钩子或 Shadow DOM 行为。
-
@webcomponents/webcomponentsjs必须按需加载：custom-elements-es5-adapter.js（解决 ES5/ES6 混用） +custom-elements.min.js，不能全量引入 - IE 中
template.content返回空文档片段，无法克隆节点 —— 所有依赖<template>的逻辑都得 fallback 到innerHTML + document.createElement -
<dialog>、<slot>、<portal>这类新元素没有可用 polyfill，强行补只会掩盖问题；应直接用<div role="dialog">+ 手动 focus trap +z-index控制 - Web Components 相关 polyfill 在滚动频繁或节点大量更新时 CPU 占用高，且调试极其困难 —— 如果项目非强依赖，建议整块降级为普通 DOM 操作
最易被忽略的一点：所有 polyfill 的加载顺序和执行时机，比代码本身更关键。比如 html5shiv 放错位置，整个页面语义结构就塌了；whatwg-fetch 异步加载，fetch 调用直接报错；dialog-polyfill 在 DOM 尚未解析完就注册，registerDialog 会静默失败 —— 这些都不是语法问题，而是环境适配的硬约束。
