--mobile 是语义标记而非自动适配机制，需配合 @media 或 matchMedia 手动控制；必须挂于 Block 最外层，所有相关样式须显式携带该修饰符前缀，禁止滥用通用类或混用其他语义。
移动端加 --mobile 修饰符不是“适配动作”，而是把媒体查询触发的状态显式暴露给 CSS 和 JS 的钩子；它本身不响应屏幕尺寸，必须配合 @media 规则或 matchMedia 监听才能生效。
为什么不能直接用 --mobile 类实现响应式
修饰符是静态类名，浏览器不会因为屏幕变小就自动加它。常见错误是写了 .nav__list--mobile { flex-direction: column; }，但 HTML 里始终只有 class="nav__list" —— 没有类，CSS 就不匹配。
-
--mobile是语义标记，表示“这个组件当前处于移动视口下的布局意图”，不是断点开关 - 真正决定是否启用该样式的，是
@media (max-width: 768px) { .nav__list--mobile { ... } }这类规则 - 若需动态控制（比如横竖屏切换），得用 JS 调用
matchMedia并手动增删类，不能依赖 CSS 自动推导 - 纯 CSS 方案下，
--mobile必须在 HTML 初始渲染时就存在，否则首屏会漏样式
--mobile 该挂在哪一层元素上
必须挂到最外层 Block 容器上，而不是子元素或全局工具类。例如导航菜单，应作用于 .nav__list，而非 .nav__item 或单独的 .mobile-only。
- 错误：
<div class="nav"><ul class="nav__list"><li class="nav__item--mobile">—— 子项无法独立表达整体布局意图 - 正确：
<ul class="nav__list nav__list--mobile">，再在 CSS 中写.nav__list--mobile .nav__item { display: block; } - 禁止抽成通用类如
.mobile或js-mobile—— 违反 BEM 封装原则，会导致样式泄露和选择器权重失控 - 若某组件在桌面/移动端结构差异极大（如轮播指示器从横向 dots 变为纵向 bars），应新建独立 Block（
carousel-vertical），而非强行复用--vertical修饰符
如何避免 --mobile 修饰符被样式覆盖或失效
移动端布局切换后，常出现激活态、字体大小、内边距等样式丢失，根本原因是父级修饰符没参与选择器链，导致基础规则优先级更高或未命中。
立即学习“前端免费学习笔记（深入）”；
- 所有依赖布局状态的样式，必须显式带上父级修饰符前缀，例如：
.nav__list--mobile .nav__item--active和.nav__list--desktop .nav__item--active分开写，不能只靠.nav__item--active继承 - 检查
overflow、height、max-height等父容器限制：即使加了--mobile，若.nav父容器设了height: 40px且overflow: hidden，垂直菜单仍会被截断 - 字体单位慎用
em：.nav__item--active若在--mobile下用了font-size: 1.2em，而父级.nav__list没设font-size，实际值将回退到根元素，可能意外缩小 - 推荐用
rem或clamp()配合修饰符变量，例如：.nav__list--mobile { --nav-item-font-size: 0.875rem; }，再由子元素消费
移动端 --mobile 与其它修饰符的组合逻辑
修饰符之间正交，可叠加，但顺序和声明位置影响最终效果。一个按钮同时需要移动适配和禁用态，应写成 class="btn btn--mobile btn--disabled"，而非 btn--mobile-disabled。
-
--mobile描述布局角色，--disabled描述交互状态，二者生命周期不同：前者随视口变化，后者随用户操作变化 - CSS 中不要写
.btn--mobile.btn--disabled { opacity: 0.4; }这类组合规则 —— 应保持每个修饰符只改自身职责范围内的属性，避免隐式耦合 - 若
--mobile需要重置某些基础样式（如移除桌面端的margin-right），应在修饰符规则里显式设为margin-right: 0，而不是依赖“未定义即继承” - 注意 iOS Safari 对伪类支持弱：别指望
.btn--mobile:disabled在所有机型上稳定生效，JS 主动加--disabled更可靠
真正容易被忽略的是：修饰符命名一旦定下，就锁死了它的语义边界。--mobile 永远只代表“移动视口下的布局意图”，不能偷偷塞进触摸优化、DPR 适配或夜间模式逻辑——那些都该由独立修饰符（如 --touch、--high-dpr、--dark）承担，否则维护成本会指数级上升。
