响应式组件应将“变”与“不变”分离：结构语义由BEM锁死，响应逻辑收敛至修饰符层，所有@media仅绑定单个BEM类名，不嵌套、不跨块、不依赖DOM层级。
响应式组件在设计系统里可复用且好维护，关键不是堆砌媒体查询，而是把“变”和“不变”彻底分离：结构与语义由 BEM 锁死，响应逻辑收敛到修饰符层，所有 @media 规则只绑定单个 BEM 类名，不嵌套、不跨块、不依赖 DOM 层级。
为什么直接写 .card { @media (min-width: 768px) { ... } } 是错的
这种写法看似简洁，但破坏了两个核心约束：一是 Sass 编译后仍生成嵌套选择器（如 .card .card__title），违反 BEM 单类名原则；二是响应逻辑被“藏”在 block 内部，无法被全局搜索、CI 校验或视觉回归工具定位。
常见错误现象：card--mobile 在首页生效，挪到弹窗里就失效——因为实际生效的是 .modal .card--mobile .card__content 这种组合选择器，而它根本没在设计系统文档里定义。
- 所有响应式规则必须显式声明触发类，例如只允许
.card--stacked或.card--grid作为@media的唯一选择器 - 禁止在
@layer components或_card.scss中用&生成媒体查询嵌套 - 修饰符名要表达设计意图，而非设备，
--responsive-grid✅，--on-tablet❌
@media 规则必须绑定到明确的 BEM 修饰符类
真正可维护的响应式，是让每个断点变化都对应一个可命名、可测试、可文档化的组件变体。比如卡片从单列变为网格，不是靠 JS 加 is-mobile，而是模板中显式写 <div class="card card--grid">，然后在 CSS 中：
立即学习“前端免费学习笔记（深入）”；
.card--grid {
display: grid;
}
@media (max-width: 767px) {
.card--grid {
display: block;
}
}
这样做的好处很实在：
- 调试时搜
card--grid就能定位全部响应逻辑，不用翻 10 个文件找 media 块 - stylelint 可用
selector-bem-pattern规则拦截.card .title类非法媒体查询 - 组件文档能直接标注“支持变体：card--grid（桌面）、card--stacked（移动端）”，设计师和前端对得上同一串字符
Block 修饰符 vs Element 修饰符：改哪里，决定类名挂哪
响应式改动范围决定了修饰符该写在 Block 还是 Element 上——这不是风格偏好，是作用域边界问题。
整块布局切换（栅格、折叠、方向变更）必须用 Block 修饰符：.product-list--stacked、.header--collapsed；仅内部元素自身排版微调（图标位置、间距、可见性）才用 Element 修饰符：.button__icon--right、.nav__item--hidden-mobile。
- 错误做法：给
.card__content加--mobile，结果这个修饰符在用户列表页也被复用，但语义已错乱 - 禁用跨 Block 的响应式类，如
hidden-on-mobile——它破坏了作用域，也违背 BEM 的块级封装前提 - Element 修饰符不能独立存在，必须依附于其 Block，
.button__icon--right永远不该脱离.button使用
现有项目补 BEM 响应式时最容易漏掉的三件事
不是重命名所有 class，而是守住高频、跨业务、易冲突的模块入口。很多团队卡在“以为加了 --mobile 就算响应式”，其实只是把旧问题换了个名字。
- 只改子元素 class，漏掉 Block 根：写了
.card__title--large却保留旧的.card，导致样式残留或优先级混乱 - 修饰符挂错层级：把
--large加在.card__footer上，而不是统一由.card--large控制整体缩放比例 - 和第三方组件库硬刚：试图覆盖
.el-table__cell的响应式行为，结果升级后全崩；稳妥做法是封装 wrapper：<div class="my-table"><el-table class="my-table__inner"></el-table></div>，只对.my-table和.my-table__inner写响应规则
真正的可维护性，体现在你删掉一个 @media 块时，不会让三个页面同时白屏——因为每个响应逻辑都归属清晰、命名明确、测试可覆盖。
