aspect-ratio在旧浏览器中被静默丢弃，chrome≤87等环境完全不解析；唯一可靠fallback是padding-top百分比方案，需父容器relative定位、内容层absolute填充，并严格按顺序先写fallback再用@supports覆盖。
aspect-ratio 在旧浏览器中不是“不生效”，而是被静默丢弃——Chrome ≤87、Safari ≤15.3、IE/Edge ≤18、微信 X5、UC、旧安卓 WebView 都不认识这个属性，DevTools 里那行 CSS 可能直接标灰或消失。不能靠构建工具自动补，也不能指望 @supports 兜底，必须手动写 fallback。
padding-top 百分比是唯一可靠 fallback
它从 IE6 就稳定存在，原理简单：padding-top 的百分比值始终按父容器宽度计算，不依赖新特性。
- 公式固定：
padding-top: (height ÷ width) × 100%，比如16 / 9→56.25%，4 / 3→75%；手算错会导致比例严重失真 - 父容器必须设
position: relative，否则子元素position: absolute会相对于body定位 - 内容层要加
position: absolute; inset: 0（或top: 0; left: 0; width: 100%; height: 100%），否则内容会被 padding 区域“吞掉” - 别同时写
height: 0和padding-top后再加aspect-ratio——旧浏览器取height: 0，结果高度为 0
@supports 写法必须外置且顺序严格
@supports (aspect-ratio: 1/1) 在 Chrome 28+ 才支持，而很多老环境（如 IE、X5）连这个规则块都会跳过，所以降级逻辑绝不能包在里面。
- 正确顺序：先写 fallback 样式，再用
@supports覆盖 —— 旧浏览器执行第一段，新浏览器覆盖第二段 - 示例：
.ratio-box { position: relative; width: 100%; padding-top: 56.25%; }@supports (aspect-ratio: 16/9) { .ratio-box { padding-top: 0; aspect-ratio: 16/9; } } - 顺序反了（比如
aspect-ratio在前、padding-top在后）会导致部分 Safari 异常解析，甚至整条失效
Flex/Grid 容器里 aspect-ratio 会失效，这不是兼容性问题
aspect-ratio 只在元素有明确可推导宽度时才参与计算，而 flex 或 grid 的收缩/拉伸逻辑会先锁定尺寸，把比例约束挤掉。
- Flex 场景：子项若带
flex: 1或min-width: 0，会强制压缩；临时加flex-shrink: 0可验证是否为此问题 - Grid 场景：若列宽写死（如
grid-template-columns: 200px 200px），子项再设aspect-ratio也无效；改用1fr或minmax(0, 1fr)留弹性空间 - 视频/图片容器务必套一层
<div>：直接给 <code><video></video>或<img>设aspect-ratio基本无效（它们有固有宽高比，会覆盖该属性）Tailwind 用户特别注意：它不会自动 fallback
Tailwind 只负责把
aspect-[16/9]编译成aspect-ratio: 16 / 9，不注入任何兼容性代码。你没手动写pt-[56.25%] + relative + absolute结构，就不会有 fallback。-
pt-[56.25%]的百分比是按父容器宽度算的，必须配合relative定位父容器 - 内容层得用
absolute inset-0（或top-0 left-0 w-full h-full），否则会被 padding 区域“吞掉” - Safari 对斜杠语法
aspect-[16/9]解析极不稳定；更稳的写法是小数：aspect-[0.5625]（即9 ÷ 16），CSS 层面等价，且 Safari 15.4+ 兼容性可靠
@supports却不渲染aspect-ratio，微信 X5 可能连padding-top百分比都算错（需加will-change: transform防重绘错位），CMS 输出的卡片容器可能自带height: 100%，直接覆盖比例计算。这些干扰点，比属性本身更常导致失败。 -
