响应式布局应由媒体查询控制而非设备后缀类名；修饰符需表达状态意图（如--narrow、--stacked），禁止--mobile等设备绑定命名，断点须变量化并按min-width升序置于文件末尾。
响应式布局不该靠类名后缀区分设备，而应由媒体查询控制视觉表现；所有带@sm、--mobile、--tablet的修饰符都是错的，它们既无效又不可维护。
为什么--mobile这类修饰符根本不起作用
浏览器不解析类名里的@或mobile，.sidebar--mobile和.sidebar--compact在 CSS 里没有任何区别——真正起作用的是@media规则本身。硬塞设备词进类名只会带来三类问题：
-
el.classList.add('sidebar--mobile')这种写法无法触发任何断点逻辑，纯属徒劳 - 当设计改用容器查询（
@container）或用户偏好（prefers-reduced-motion）时，所有--mobile类都得重命名，重构成本爆炸 - 不同开发者对“mobile”理解不一致：有人指
480px，有人指768px，JS 切换时容易错配
响应式该用什么语义命名修饰符
修饰符必须表达「状态意图」，不是设备类型。它要能脱离屏幕尺寸独立存在，且加/删后视觉变化可预测：
- 用
--narrow代替--mobile：窄态可能由小屏触发，也可能由用户折叠侧边栏触发 - 用
--stacked代替--tablet：堆叠意图适用于页脚列、卡片列表、表单字段等多种场景 - 用
--drawer代替--hidden-on-mobile：抽屉是明确的状态，且可被 JS 控制开关，不绑定设备 - 禁止
--justify-between这类纯 CSS 属性映射名，应改用--spaced等业务语义词，方便未来用gap替代
媒体查询必须绑定到具体 Block，不能全局堆砌
把所有响应式规则塞进responsive.css会破坏 BEM 的模块自治原则。每个 Block 应自己管理自己的断点逻辑：
立即学习“前端免费学习笔记（深入）”；
-
@media (min-width: 768px) { .site-footer__column { width: 50%; } }——只影响页脚列，不影响其他模块 - 避免
@media (max-width: 768px) { .button { padding: 8px 12px; } }——这会覆盖.button--large的语义，破坏变体一致性 - 断点值必须收口为变量：
$bp-md: 768px，禁止在类名或 CSS 中硬编码768px - 所有
@media块统一放在文件末尾，按min-width升序排列，避免max-width/min-width混用导致 768px 精确宽度下规则冲突
复杂组件的响应式必须靠嵌套上下文，不是靠类名层级
仪表盘卡片、网格列表这类结构，响应式逻辑不能写在子元素修饰符里，而应由父级 Modifier 或 CSS 自定义属性驱动：
- 不要写
.chart-card__body--collapsed-mobile，保持基础类名.chart-card__body不变 - 用父级 Modifier：
.chart-card--compact .chart-card__body { max-height: 200px; } - 在媒体查询中切换 Modifier：
@media (max-width: 480px) { .chart-card { --chart-card-mode: compact; } }，再用var(--chart-card-mode)配合content-visibility或max-height控制 - 内层网格（如卡片列表）必须升格为独立 Block：
.card-grid，而不是.dashboard__main-content__card-grid——BEM 不允许三层嵌套
最易被忽略的一点：BEM 的响应式不是“给不同设备写不同类名”，而是“让类名稳定，让 CSS 规则随上下文动态生效”。一旦开始拼接@符号或设备词，就等于放弃 BEM 的核心价值——语义锁定与协作可预测性。
