CSS Blocks并非标准技术或主流方案，实为对BEM中Block的误称；真正可落地的是BEM命名规范+文件组织+作用域意识。
直接说结论：CSS Blocks 不是标准 CSS 技术，也不是主流框架或工具链中的概念——它常被误用为对 BEM 中 Block 的口语化简称，但本身不构成一套可落地的架构方案。真正能支撑高可维护性 CSS 架构的，是 BEM 命名规范 + 文件组织 + 作用域意识，而不是某个叫 “CSS Blocks” 的东西。
为什么搜不到 CSS Blocks 官方文档或 npm 包
因为 CSS Blocks 并非 W3C 标准、浏览器原生支持的机制，也不是 PostCSS/Sass/Webpack 生态中广泛采用的构建工具（比如没有 css-blocks 这个主流包）。你看到的“CSS Blocks”，大概率是开发者把 BEM 里的 Block 单独拎出来讲时的口误或缩写，比如把 card 叫成一个 “CSS Block”。这种说法容易让人误以为存在某种语法糖或编译器。
- 真实存在的类似名字项目曾有
@css-blocks/core（2018–2021 年间活跃），但它是一个实验性、已归档的 CSS-in-JS 编译方案，和传统 CSS 工程无关，且早已停止维护 - 所有现代 CSS 可维护性实践，包括 Shopify、Salesforce、Ant Design 等团队公开资料，均基于 BEM / ITCSS / Atomic CSS 等命名+组织方法，而非 “CSS Blocks”
- 如果你在某篇中文教程里看到 “用 CSS Blocks 拆分样式”，基本可以判定它实际想说的是 “以 Block 为单位组织 CSS 文件”
Block 在 BEM 中到底指什么，怎么才算用对了
BEM 的 Block 是语义化、独立、可复用的功能单元，不是 HTML 标签，也不是文件夹名，更不是加个 data-block 属性就能算数的。
- 合格的
Block名必须描述「功能」而非「样式」或「位置」：✅search-form、product-card；❌blue-button、top-banner - 一个
Block应该能脱离当前页面、上下文被单独复用：把user-avatar拿到新项目里，只要结构一致，样式就该照常工作 -
Block内部禁止用嵌套选择器定位子元素：.user-avatar .name是反模式；正确写法是user-avatar__name，并确保它只在user-avatar的 HTML 结构内出现 - 多个同名
Block共存不会冲突：header__logo和footer__logo是两个完全隔离的作用域，哪怕都叫logo
如何让 Block 真正支撑起可维护架构
光写对类名远远不够。BEM 的威力只有配合三件事才释放出来：文件拆分、构建约束、协作共识。
立即学习“前端免费学习笔记（深入）”；
- 每个
Block对应一个独立 CSS 文件（如components/card.css），文件内只写.card、.card__title、.card--featured相关规则，不引入其他 Block 的样式 - 用 Sass 或 PostCSS 实现自动前缀/变量注入，但禁止跨 Block 引用变量（例如
card文件里不能@use 'button'）——否则就退化成耦合式开发 - CI 流程中加入类名 lint：拦截
.btn-primary、.header .nav li这类非 BEM 写法；推荐使用stylelint-selector-bem-pattern - 设计师交付组件时，同步提供 BEM 类名映射表（如 Figma 插件导出的 class list），避免前端自行脑补命名
最容易被忽略的一点：BEM 不是给机器看的，是给人读的。当你写 checkout-step__summary--expanded，同事不用打开 JS 就知道这个样式只在结算流程的摘要区域展开状态下生效；而 .open 或 .active 这种通用名，在大型项目里查一次 DOM 就得 grep 十分钟。可维护性的本质，是降低每次修改时的上下文加载成本。
