aspect-ratio 必须写在 img 的直接父容器上，不能写在 img 标签本身；因 img 是替换元素且默认 inline，不参与块级流计算，直接设置无效；正确做法是用语义化容器（如 product-card__image-wrap）并确保其 display 为 block/flex/grid、未脱离文档流、未显式设 height。
aspect-ratio 必须写在 img 的直接父容器上，不能写在 img 标签本身
浏览器把 aspect-ratio 当作容器级空间预留指令，而 img 是替换元素，默认 display: inline，不参与块级流计算。直接给 img 设 aspect-ratio: 16 / 9 在 Chrome 88+、Safari 15.4+ 中会被标记为 invalid，DevTools 里显示 crossed-out —— 它根本不起作用。
正确做法是包裹一层语义中性容器，比如：product-card__image-wrap 或 hero-banner__bg-wrap，并确保它：
-
display是block、flex或grid（不能是inline） - 没被
position: absolute或float脱离文档流 - 没显式设置
height（否则覆盖比例推导）
Element 命名要绑定具体组件，禁用泛称如 img-wrap 或 ratio-box
BEM 的 Element 必须表达“它在当前块里扮演什么角色”，而不是“它有什么技术特性”。product-card__image-wrap 明确表示“这是商品卡片里的图片容器”，而 product-card__img-wrap 或 product-card__ratio-box 暴露了实现细节，后续换成 video 或加 canvas 就得改类名。
常见错误包括：
- 用
product-card__responsive-wrap→ “responsive” 是行为，不是角色 - 用
product-card__aspect-wrap→ 把 CSS 属性名塞进类名，违反 BEM 不暴露实现原则 - 用
product-card__container→ 过于笼统，无法区分是图容器、文字容器还是操作按钮容器
修饰符控制语义形状，不控制断点或 DPR
尺寸相关修饰符只表达“这张图看起来像什么”，比如 product-card__image-wrap--square 表示“按正方形比例展示”，--wide 表示“宽屏比例”，--portrait 表示“竖构图”。这些修饰符本身不带媒体查询逻辑，也不决定用哪张图源。
真正的响应式适配靠两件事配合：
- CSS 中独立的
@media规则控制不同断点下的width、max-width或aspect-ratio值 -
<picture>+srcset控制资源选择，BEM 类名完全不参与
例如：product-card__image-wrap--square 在桌面端可能占满网格列，在移动端缩为 50% 宽，但类名不变 —— 变的是 CSS 里的 @media (max-width: 768px) 规则。
服务端必须提供宽高比元数据，否则 SSR 首屏仍会跳动
React/Vue 组件里动态拼 style="--ratio: {{w}} / {{h}}" 看似可行，但 SSR 渲染时若 CMS 没返回图片原始尺寸（比如只给了 URL），服务端就无法注入有效 aspect-ratio，首屏仍塌陷。这不是前端能 JS 补救的问题。
可靠方案只有两个：
- 后端 API 必须返回图片的
width和height字段（哪怕只是缩略图尺寸） - 模板层直接写死：
<div class="product-card__image-wrap product-card__image-wrap--square" style="aspect-ratio: {{width}} / {{height}}">
硬写保守值（如 16 / 9）虽能防抖动，但会导致严重裁切或留白 —— 尤其当实际图源是 1 / 1 头像或 4 / 3 产品图时，这个坑在画廊页和搜索结果页最容易暴露。
