结论：无需为老内核单独写逻辑，应通过@supports+语义化html+分层css实现渐进增强；html须裸跑可用，css按能力分层交付，避免资源浪费与渲染异常。
直接说结论：不用为老内核单独写一套逻辑，而是用 @supports + 语义化 HTML + 层级 CSS 规则控制增强粒度——这样既避免 polyfill 负担，又能让 IE11、Edge Legacy、Chrome 80+、Safari 14+ 各取所需。
怎么用 @supports 安全地叠加新特性
@supports 是渐进增强的开关，不是“检测浏览器”，而是“检测能力”。它比 UA 字符串或 document.documentMode 更可靠，且不触发 JS 加载阻塞。
- 别写
@supports (display: grid)然后整个重排版——这会让不支持的浏览器彻底失去布局结构；应该只用它增强局部模块，比如表单字段对齐或卡片间距 - 组合条件要谨慎：
@supports (display: grid) and (gap: 1rem)比单写display: grid更安全，因为旧版 Safari 支持grid但不支持gap - 和媒体查询嵌套时，先写断点，再套
@supports：@media (min-width: 768px) { @supports (container-type: layout) { ... } }，避免在小屏设备上浪费计算
HTML 结构必须能“裸跑”
所谓“裸跑”，是指去掉所有 CSS 和 JS 后，页面仍具备完整信息层级与可操作性。这是渐进增强的地基，不是可选项。
- 表单控件必须带
label且绑定for或包裹输入项，否则 VoiceOver 和 IE11 的键盘导航会失效 - 导航菜单用
nav+ul+li+a，别依赖 JS 渲染菜单结构；JS 只负责加 class 控制展开/收起 - 图片必须有
alt，且关键图文信息不能只靠 CSS::before插入——IE11 不渲染伪元素内容，也不会读出
CSS 层级规则怎么写才不踩坑
渐进增强的 CSS 不是“补丁式覆盖”，而是按能力分层交付：基础层 → Flex/Grid 增强层 → 容器查询层 → view-transition 动效层。
- 基础层用
float+inline-block+max-width实现多栏，兼容 IE9+；不要用display: flex作为默认布局 - Flex 增强层用
@supports (display: flex)包裹，仅调整对齐、换行、顺序，不改动 DOM 结构 - 容器查询（
@container）目前仅 Chrome 117+ / Safari 16.4+ 支持，必须用@supports (container-type: inline-size)包裹，且 fallback 到媒体查询断点 - 慎用
prefers-reduced-motion：它在 Edge Legacy 中被忽略，在 Firefox 100 之前不支持值为reduce的判定，建议只用于过渡时长降级，不用于禁用核心交互
最容易被忽略的是：渐进增强不是“让新浏览器更好看”，而是“让旧浏览器不崩溃”。很多团队把 @supports 当成功能开关，却忘了它不解决资源加载顺序——CSS 文件本身得按能力分拆，否则低版本浏览器仍会下载并解析不支持的属性，引发渲染卡顿或样式错乱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
