不能用单一修饰符控制响应式图片，因为BEM修饰符需表达语义意图而非混杂媒体查询、JS状态与布局职责；否则导致类名冗长、维护困难、职责混乱。
响应式图片在 BEM 下不能靠 img--responsive 这种笼统修饰符一招鲜，必须把「尺寸控制」「加载状态」「布局上下文」拆开管理，否则很快会写出 img--responsive--lazy--square@md--loaded 这类不可读、不可维护的类名。
为什么不能用单一修饰符控制响应式图片
BEM 修饰符不是开关集合器，而是语义化意图的表达。把屏幕适配、加载状态、宽高比全塞进一个修饰符里，等于把媒体查询逻辑、JS 状态、CSS 布局职责混在一起——结果就是：改个断点要动 HTML 类名，换张图要重写 CSS，加个骨架屏还得新增修饰符。
常见错误现象：
- 写
gallery__img--sm然后在 CSS 里@media (max-width: 768px) { .gallery__img--sm { width: 100%; } }—— 修饰符名暴露了断点值，违反“不暴露实现细节”原则 - 用
img--cover同时控制background-size: cover和object-fit: cover—— 元素类型（<img>vs<div>）不同，语义冲突 <li>在 JS 中根据 <code>window.innerWidth动态切换--mobile/--desktop修饰符 —— 容易漏掉 resize 监听、节流不当、与 CSS @media 不同步 - 块名必须绑定具体组件，如
product-card__image、hero-banner__bg，不单独用img或responsive-img - 尺寸相关修饰符只表达语义，如
product-card__image--square对应aspect-ratio: 1 / 1，--wide对应aspect-ratio: 16 / 9，具体数值由 CSS 层叠或容器查询控制 - 加载状态修饰符独立存在：
product-card__image--loading控制 opacity + transition，--loaded触发 fade-in 动画，不参与尺寸计算 - 真正的屏幕适配逻辑写在
@media规则里，例如：@media (max-width: 768px) { .product-card__image--square { width: 100%; } }而不是让 JS 去加--mobile - 父容器（如
product-card__figure）设置max-width: 100%和height: 0+padding-bottom维持宽高比 -
product-card__image自身设为position: absolute; top: 0; left: 0; width: 100%; height: 100%; object-fit: cover; - 需要等比缩放时，用
product-card__image--contain修饰符覆盖object-fit: contain，而非修改 width - 背景图场景统一走
hero-banner__bg块，用background-size: cover+@media调整容器尺寸，不碰img标签
正确做法：用 BEM 分离三类控制维度
每张响应式图片的展示逻辑，实际由三个正交维度决定：它属于哪个组件块（block）、处在什么状态（modifier）、被放在什么布局上下文里（通过父级修饰符或容器查询）。BEM 要求这三者不耦合。
实操建议：
如何避免 max-width: 100% 和 width: 100% 的误用
对 <img> 元素，直接写 width: 100% 很危险——它会让图片强行拉伸到父容器宽度，可能远超原始分辨率；而 max-width: 100% 才是安全底线，但仅靠它还不够。
在 BEM 结构中，应把尺寸约束下沉到容器层级：
容易被忽略的关键点：容器查询还没普及，@media 仍是主力
很多人以为用了 BEM 就能天然支持容器查询（container queries），其实不然。目前主流浏览器对 @container 支持仍有限，且 BEM 本身不提供容器能力。所以现阶段，所有基于“父容器尺寸”的响应式逻辑，依然得靠 @media + 显式类名组合来兜底。
这意味着：如果你的 gallery__thumb 可能出现在侧边栏（窄）或模态框（宽）两种上下文中，不能指望它自动响应父容器宽度变化——必须由外层组件主动加修饰符，比如 sidebar__gallery--compact 或 modal__gallery--full，再配合对应媒体查询规则。否则，BEM 的“可复用性”就只停留在命名层面，实际样式还是硬编码的。
