任何一个参与过中大型 Web 项目的人，都或多或少经历过样式失控的时刻：改一个按钮的颜色，却发现页脚也跟着变了；删掉一行看似无用的 CSS，结果某个隐藏多年的弹窗彻底变形；想给新功能写样式，却不知道该用哪个已有的类名，索性复制粘贴了一段旧代码，于是项目里又多了一份冗余；新同事入职，问他"这个页面的样式在哪里定义"，他花了半个小时才找到分散在五个文件里的相关规则......这些混乱，并非 CSS 本身的问题，而是我们对"样式也是一种需要被认真对待的软件资产"这个事实认识不足。
CSS 架构的核心命题，从来不是选择最流行的命名规范或者最热门的工具库，而是回答三个最基本的问题：样式如何被有效地组织？如何被安全地复用？如何被放心地修改？这三个问题指向的，其实是软件工程中那些经典的底层原则------单一职责、开闭原则、依赖倒置。你会发现，当我们在讨论 CSS 架构时，本质上我们在讨论的，是如何将通用的工程智慧应用到样式这个特殊的领域里。特殊之处在于，CSS 是一门声明式语言，它没有变量作用域（至少在原生 CSS 变量普及之前如此），没有模块系统，没有编译时检查，所有规则都活在同一个全局命名空间里。这种"先天不足"让 CSS 架构的挑战，比常规的代码架构要复杂得多。
先说组织。传统的"一个页面一个样式表"的做法，在组件化时代已经难以为继。更好的方式是按功能或按组件来拆分，让每段样式只服务于一个明确的职责。但"按组件拆分"说起来容易，做起来却充满陷阱。一个按钮组件，它的样式可能包括自身的尺寸、颜色、字体，还可能需要处理 hover 状态、active 状态、disabled 状态，甚至还要考虑它在不同父容器下的表现差异。这些样式应该全部放在按钮组件的文件里吗？还是说，状态相关的样式应该抽离出来？不同父容器下的差异，是应该由按钮自己来处理，还是由父容器来覆盖？这些问题没有一个放之四海皆准的答案，它们取决于你的项目规模、团队习惯、以及对"组件边界"的定义。但有一条原则是通用的：样式文件的拆分颗粒度，应该和你的思维模型保持一致。当你想到"导航栏"的时候，你应该能清楚地知道它的样式在哪个文件里；当你想到"全局间距系统"的时候，你也应该知道去哪里调整。这种"思维到文件"的映射越直接，团队的认知负担就越低。
再深入一层，组织的本质其实是"分层"。一个健康的 CSS 架构，往往呈现出清晰的层次感。最底层是"设计令牌层"------颜色、字体、间距、圆角、阴影等基础变量的定义，这一层是全局共享的，几乎不会频繁变动。往上一层是"基础元素层"------对 HTML 原生标签（如标题、段落、列表、表单元素）的默认样式重置和统一，这一层确保所有内容在没有额外类名的情况下，依然拥有可读且一致的默认外观。再往上是"组件层"------按钮、卡片、弹窗、标签页等可复用的 UI 单元，这一层是开发中最常打交道的地方。最顶层是"布局层"或"页面层"------负责将组件组合成完整的页面结构，处理网格、间距、响应式断点等宏观布局问题。这种分层不是死板的教条，而是一种思维框架。当你面对一个样式问题时，你首先问自己：这个问题属于哪一层？是设计令牌需要调整，还是某个组件的内部样式出了 bug？这种追问本身，就能帮你避免许多低级错误。
再说复用。CSS 的复用性一直是个充满争议的话题。一方面，类名天然就是可复用的------你可以在任何 HTML 元素上添加同一个类名来获得相同的样式，这听起来很美好；另一方面，过度复用又会导致"牵一发而动全身"的连锁反应，你修改了一个公用类名，结果整个网站几百个地方都跟着变了，其中一半是你期望的，另一半是你没想到的。这种"复用焦虑"，让许多团队走向了另一个极端：每个元素都使用独立的、不重复的类名，彻底放弃复用，换来修改的安全性。但这样做又带来了新的问题：样式文件体积急剧膨胀，HTML 中类名冗长重复，而且当你真的需要统一调整设计语言时，你会发现根本没有"统一"的入口------你需要手动修改几百个地方。
好的架构会在复用和独立之间找到平衡点。一个经过实践检验的策略是"原子化设计令牌 + 组件级组合"。具体来说，就是把最细粒度的样式决策（颜色值、尺寸值、间距值等）提取为语义化的变量，比如 --color-primary、--spacing-medium、--font-size-base。组件在定义自己的样式时，只引用这些变量，而不直接使用具体的数值。这样，当你需要调整品牌色时，你只需要修改 --color-primary 这一个地方，所有使用它的组件都会自动更新。而当你需要调整某个特定组件的样式时，你只需要修改该组件的定义，其他组件不受影响。这种"共享不变、局部可变"的模型，既保证了设计语言的一致性，又给予了组件足够的独立性，正是现代设计系统的基本逻辑。
最后是修改的安全性。为什么我们常常害怕修改 CSS？因为全局作用域让任何改动都可能产生不可预见的副作用。你在文件 A 里改了一个类名，文件 B 里的某个元素恰好也用了这个类名，它的样式也跟着变了，但你根本不知道文件 B 的存在。这种"隐性依赖"是 CSS 维护中最隐蔽的杀手。为了增加修改时的安全感，架构师们发明了各种隔离手段：BEM 命名规范通过严格的命名约定来减少样式冲突的可能性；CSS Modules 通过编译时生成唯一的类名来实现真正的局部作用域；CSS-in-JS 则将样式完全封装在组件的 JavaScript 模块内，彻底切断了跨组件的样式泄漏。这些方案虽然实现路径各不相同，但目标高度一致：让每一段样式的影响范围变得透明、可预测、可控。
选择哪种方案，取决于你的团队规模、技术栈、以及对构建工具链的接受程度。但比方案本身更重要的，是团队内部对"样式边界"有统一的理解和共识。每个人都需要清楚地知道：一段样式属于哪个组件？它的影响范围有多大？它是否会被其他模块依赖？如何安全地扩展它？这些问题的答案，不能只存在于某个资深工程师的脑子里，而应该通过架构约定、代码审查、以及良好的文档来显式地传达给每一位成员。
说到底，CSS 架构不是一套冷冰冰的规则清单，而是一种持续演进中的集体共识。它承认我们都会犯错，但它提供了一套机制，让我们能更快地发现问题、定位问题、并安全地修复问题。它不追求绝对的完美和终极的方案------因为 Web 标准在演进，项目需求在变化，团队的认知也在迭代------它只追求在一个动态变化的环境中，每个人都能自信地写下下一行样式，而不必担心引爆一颗埋藏已久的地雷。这种自信，就是一个好的 CSS 架构，能给予团队最宝贵的礼物。