）
选 polyfill 前先看这三件事
不是所有 polyfill 都适合你的项目。比如
dialog-polyfill
依赖 CSS 注入和全局事件代理，而你用 Shadow DOM 封装组件，它就可能失效；又或者你在 Next.js / SSR 环境里直接 import，会报
window is not defined
。
实操建议：
确认 polyfill 是否支持你的运行环境（SSR？微前端？Web Component？）
检查它是否修改原生原型（如给
HTMLElement.prototype.showModal
赋值）——某些安全策略（CSP）会阻止
优先用「按需加载」：只在检测到不支持时才
import('dialog-polyfill').then(...)
，避免拖慢现代浏览器首屏
手动降级比硬套 polyfill 更可控的场景
对简单语义标签（如
），polyfill 没意义——它本就不影响渲染，只是增强语义。但像
的
size
属性在 Safari 旧版有 bug，这时写个
if ('size' in HTMLSelectElement.prototype)
判断再加 class 控制高度，比引入整套表单 polyfill 更轻量。
实操建议：
优先用特性检测 + CSS fallback（例如
display: dialog
不支持？补
.dialog-fallback { position: fixed; z-index: 1000; }
）
对交互逻辑，封装成函数（如
showDialog(el)
），内部根据支持度调用原生方法或模拟逻辑
避免在 HTML 源码里写两套结构（一套新标签 + 一套 div class），维护成本高且容易不同步
真正麻烦的从来不是“有没有 polyfill”，而是它和你的构建链路、样式隔离、事件流是否打架。上线前务必在目标最低浏览器里打开 DevTools，手动删掉 polyfill 脚本，看页面是否退化成可操作状态——这才是降级是否成立的唯一标准。
