CSS BEM命名规范实现无限滚动加载状态（Loading修饰符）

如何给无限滚动容器定义 loading 修饰符

直接使用 --loading 是一个常见误区——它没有说明“谁在加载”，也不符合 BEM 的语义层级。无限滚动的加载状态必须绑定到具体 Block（例如 list 或 feed），而不是泛泛的 loading。 正确的做法是将加载态视为 Block 的一种行为变体。例如，.list--loading 表示整个列表处于加载中；如果需要更精细的控制（比如只控制底部加载提示的显隐），则使用 Element 修饰符：.list__loader--loading。 - --loading 必须依附于明确的 Block 或 Element，不能单独存在（例如 .loading 违反了 BEM 原则） - 避免使用 .list__item--loading：列表项本身不“加载”，是容器在加载新数据 - 如果加载提示是独立组件（例如旋转图标），它应该是自己的 Block：.spinner，而不是强行塞入 list 的命名空间

list--loading 和 list__loader--loading 该选哪个

选择取决于你控制的是“整体行为”还是“局部 UI”。.list--loading 适合禁用交互、加遮罩、暂停滚动监听；.list__loader--loading 仅控制底部加载提示的显示与动画。 常见错误是混用：例如同时设置 .list--loading 和 .list__loader--hidden，导致样式冲突或逻辑割裂。 - 使用 list--loading 时，CSS 中可统一设置 pointer-events: none、opacity: 0.7 等全局状态 - 使用 list__loader--loading 时，只影响 display、visibility 或动画属性，不改变列表主体 - 在 React/Vue 中，建议通过单一状态变量驱动，例如 isLoading 控制 list--loading，showLoader 控制 list__loader--loading，二者可不同步（例如加载完成但暂不收起 loader）

为什么不能用 is-loading 这类 State 类

is-loading 属于通用状态类，BEM 本身不禁止，但问题在于它破坏了 Block 的封装性——一旦多个 Block 都使用 is-loading，就无法区分“哪个列表正在加载”，也无法写出精准的 CSS 隔离规则。 例如：.is-loading .list__item 会意外影响所有列表项，而 .list--loading .list__item 是受控的、可预测的。 - is- 类适合跨 Block 复用的状态（如 is-disabled），但加载态通常是 Block 的局部行为 - 构建工具（如 PostCSS）或 CSS-in-JS 方案中，is-loading 难以进行作用域提取，容易打包进全局样式表 - 调试时，DOM 上看到 is-loading 完全看不出上下文；而 list--loading 能一眼定位问题模块

SCSS 中怎么安全生成 --loading 修饰符

避免手写重复代码，使用 SCSS 的 &--loading 语法最为稳妥。但必须严格限制嵌套层级，禁止在修饰符内部再嵌套后代选择器。 错误示范：

.list {
  &--loading {
    .list__item { opacity: 0.5; } //  后代选择器，破坏 BEM 隔离
  }
}

正确写法：

.list {
  &--loading {
    opacity: 0.7;
    pointer-events: none;
  }
  &__loader {
    &--loading {
      display: block;
      animation: spin 1s infinite;
    }
  }
}

- 每个 Block 的修饰符必须在自身作用域内定义，不污染其他 Block - 如果需要“加载中时隐藏分页器”，应该定义 .list__paginator--hidden-when-loading，而不是在 &--loading 里写 .list__paginator { display: none } - 修饰符名要可预测：--loading 表示“正在发起请求”，--loaded 表示“数据已就绪但尚未渲染”，两者语义不能模糊 说到底，BEM 的关键不是字符组合，而是约束思维——你写的每一个 --loading，都得能回答“谁在加载、为什么加载、加载失败时怎么降级”。否则，它只是多打了两个短横线。