获课：789it.top/395/

架构分层理论：Base、Components与Acss的职责边界解析

在前端工程化日益成熟的今天，CSS架构的复杂度早已不亚于后端系统。当我们谈论“架构分层”时，往往容易陷入ITCSS或BEM等具体规范的教条中，却忽略了分层背后的核心逻辑——关注点分离。在我看来，一个优雅且可维护的样式架构，必须清晰地界定Base（基础层）、Components（组件层）与Acss（原子层）的职责边界。这三者并非简单的目录划分，而是构建用户界面的三种不同维度的抽象：Base是契约，Acss是词汇，而Components则是语义。

首先，Base层是整个样式系统的“宪法”，它应当保持极度的克制与纯粹。很多开发者容易犯的错误是将Normalize.css或各种Reset样式一股脑地扔进Base层，甚至在这里定义具体的按钮或卡片样式。这是对Base层的误读。Base层的职责应当仅限于定义全局的“设计变量”与“排版契约”。它只负责定义根字号、色彩系统的抽象变量（如--color-primary而非--red-button）以及HTML原生标签（如h1-h6、p、a）的默认排版规则。Base层不应包含任何具体的业务语义，也不应包含媒体查询。它存在的唯一目的，是为上层建筑提供一个统一、中性且不可动摇的基石。一旦Base层被污染了具体组件的样式，整个系统的耦合度将呈指数级上升。

其次，Acss层（原子层）是连接设计与实现的“词汇表”。它与Base层截然不同，Acss不负责定义“是什么”，而是提供“怎么做”的工具。这一层通常由大量的工具类（Utility Classes）组成，如Flex布局的开关、Margin/Padding的间距控制、字体颜色的快速应用等。Acss的核心价值在于“复用”与“组合”。它就像乐高积木中的基础颗粒，虽然单个类（如.f-1或.m-10）没有明确的业务含义，但通过组合它们，我们可以快速搭建出复杂的布局。在架构设计中，Acss层应当是独立于业务存在的，它不应依赖Base层的变量，而是直接输出纯粹的样式规则。它是开发者手中的瑞士军刀，用于处理那些无法被组件化的细枝末节。

最后，Components层是业务逻辑与视觉表现的“语义容器”。这是架构中最复杂的一层，因为它直接映射业务需求。Components层应当严格遵循BEM等命名规范，确保样式的隔离性。与Acss不同，Components层拥有明确的业务语义，例如.login-form-submit或.product-card-price。在这里，我们不再使用.btn这种泛泛的命名，而是赋予元素具体的角色。Components层通过组合Base层提供的变量（如颜色、字体）和Acss层提供的布局能力，构建出具有独立功能的UI单元。它是架构的“血肉”，承载着用户交互的核心。

综上所述，Base、Acss与Components的职责边界应当是泾渭分明的：Base层制定规则，Acss层提供工具，Components层实现语义。Base层是静态的、全局的；Acss层是动态的、组合的；Components层是具体的、隔离的。只有当这三者各司其职，互不越界，我们才能构建出一个既具备高度可扩展性，又易于维护的CSS架构。这不仅是对代码的组织，更是对复杂度的有序治理。