aspect-ratio在Chrome≤87中被静默丢弃，不解析、不报错、不回退；必须手动用padding-top百分比降级，配合position: relative和absolute定位，并确保@supports外置、顺序正确。
aspect-ratio 在旧版 Chrome（≤87）中根本不会被解析，不是“不生效”，而是浏览器压根不认识这个属性——它会被静默丢弃，DevTools 里直接划掉或根本不显示，也不会报错。所以不是加个前缀就能解决的事，必须用降级方案。
Chrome 87 及更早版本连 aspect-ratio 都不识别
Chrome 直到 88 版本才首次原生支持 aspect-ratio。在此之前（包括 87、86、80+），遇到该声明会直接跳过，CSS 解析器不处理、不警告、不 fallback。这意味着你写的那行 aspect-ratio: 16 / 9 对这些浏览器来说等于没写。
- 检查方法：打开 DevTools → Elements 面板，看该属性是否被划掉或完全不出现；Computed 面板里也找不到对应计算值
-
@supports (aspect-ratio: 1/1)在 Chrome ≤27 中也不支持，整块规则会被跳过——不能靠它兜底 - PostCSS 的
autoprefixer默认不处理aspect-ratio（无标准前缀），某些非官方插件反而会误删整行，上线前务必检查构建输出的 CSS 是否还存在该声明
为什么不能用 autoprefixer 或前缀解决
aspect-ratio 是一个全新语法特性，不是已有属性的变体，没有 -webkit-aspect-ratio 这种前缀形式。autoprefixer 只补前缀，不模拟缺失功能；它无法把 aspect-ratio: 16 / 9 转成 padding-top: 56.25%——这是语义断裂，必须手动实现。
- 构建工具不会自动帮你降级，所谓“兼容性开关”纯属误导
- IE、微信 X5 内核、UC、旧安卓 WebView 同样不支持，且多数连
@supports都不认 - 如果项目需覆盖 iOS 15.3 或微信 iOS 客户端（v8.0.4x），即使识别
aspect-ratio也可能渲染异常，建议统一降级
真正可用的 fallback 是 padding-top 百分比
这是从 IE6 兼容至今的稳定行为：padding-top 的百分比值始终基于父容器宽度计算，不依赖新特性，只靠三件事：position: relative（父）、padding-top（自身）、position: absolute（内容层）。
- 公式固定：
padding-top = (height ÷ width) × 100%，例如 4:3 →padding-top: 75%；手算错会导致比例失真 - 父容器必须设
position: relative，否则子元素position: absolute会相对于body定位 - 内容层要加
inset: 0或top: 0; left: 0; width: 100%; height: 100%，否则可能被 padding 区域“吞掉” - 顺序关键：先写 fallback（
padding-top），再用@supports覆盖为aspect-ratio；混写或顺序反了，旧浏览器可能解析失败
Flex/Grid 容器里 aspect-ratio 容易失效
在 display: flex 或 display: grid 父容器下，aspect-ratio 不是总能如预期工作。它只对块级或弹性/网格子项生效，但受 flex 项收缩逻辑干扰极大。
立即学习“前端免费学习笔记（深入）”；
- 子项若设了
flex-shrink: 1+ 窄容器，高度会被强制压扁；临时加flex-shrink: 0可验证是否为此问题 - 父容器是
flex-direction: column时，子项高度受父限制，aspect-ratio只能按宽度反推高度，结果常小于预期 -
min-width: 0会触发 flex 项收缩行为，导致比例约束被忽略；保留默认min-width: auto更安全 -
img或video有固有宽高比，同时设width: 100%和aspect-ratio可能冲突，需显式加height: auto
