在构建像Bootstrap这样的CSS系统时，保持系统的简单性、稳定性和灵活性是非常重要的。这并不容易，尤其是对于组件数量可能变得相当大的大型团队和项目而言。为了改善这种情况，您不妨考虑用带前缀的类名替换链式类名。使用链式类名方案时，您可能会像这样编写一系列特定于组件的CSS选择器：.success{...}.btn.success{..}.alert.success{...}baseclass.success设置在这里，这可能涵盖了成功按钮和成功工具提示之间的所有共性。然后，在单个组件级别，我们需要扩展或覆盖它。然而，这种完全开放式的类名和链式风格，让开发者面临一些困惑和潜在的痛点：这个基类代表什么？哪些元素会在根级别受到影响（译注：什么意思？）哪些元素可以把.success类链自身是否可以进一步扩展到更多组件如果.success的一个实例使用白底绿字怎么办，另一个使用绿色背景上的白色文本？而这些问题只是冰山一角。这不一定是一个糟糕的解决方案，但如果可伸缩性、简单性和灵活性是您的绝对需求，那么它可能不是最佳解决方案。在这一点上，带前缀的类名方案可能更适合你。带前缀的类名引导开发人员朝着更简单、更易于维护的方向构建可扩展的CSS系统。当我们放弃常规的基类方法，用前缀限制每个组件的样式时，我们的代码就会变成这样：.btn-success{...}.alert-success{...}像这样一方面，基类设置在组件级别，而不是整个系统级别。换句话说，我们的基类变成了.btn和.alert而不是.success。所有组件之间不会有干扰的样式和行为，因为我们将组件的“成功状态”视为贯穿整个系统的一个概念。也就是说，“成功”状态下的各个组件的样式只是在概念层面进行了连接；如何实现这种风格被限制在每个独立的组件中。不用担心普通样式会用到什么地方，也不用担心意想不到的副作用。这种方式使每个组件更加稳定和灵活。构建组件是一项非常具有战略性和注重细节的工作。在像Bootstrap这样的系统中，组件需要在本质上是独立的，以提高模块分离和可定制性。这就是我们编写更好的代码和令人愉快的项目的方式。我的经历作者视角在最新版本的CMUI中，我基本上使用了文章开头提到的“链式类名”风格。例如，大按钮的结构可能如下所示：
