我的回答是高水平的，针对你刚才提到的高水平的关切。也许你可以通过一些低级的组织技巧和调整来使它更漂亮，但这些都不能解决方法上的缺陷。有几个因素会影响CSS的爆炸。显然是网站的整体复杂性，但还有像命名语义、CSS性能、CSS文件组织和可测试性/可接受性等问题。

在命名语义方面，您似乎走在了正确的道路上，但还可以更进一步。重复出现在站点上而没有进行结构修改的HTML部分(称为“模块”)可以被视为选择器根，从那里您可以相对于根确定内部布局的范围。这是面向对象的CSS的基本原则，您可以在Yahoo工程师的演讲中阅读/观看更多关于它的内容。

需要注意的是，这种干净的方法可能与性能问题相反，它倾向于基于id或标记名的短选择器。找到平衡取决于你，但除非你有一个庞大的网站，这应该只是一个指南在你的脑后提醒你保持你的选择器简短。这里有更多关于性能的信息。

最后，您将为整个网站使用一个CSS文件，还是多个文件(单个基本文件用于每个页面或-section文件)?单个文件对于性能来说更好，但是对于多个团队成员来说可能更难理解/维护，并且可能更难测试。对于测试，我建议您使用一个CSS测试页面，其中包含所有受支持的CSS模块，以测试冲突和意外级联。

或者，您也可以采用多文件方法，将CSS规则作用于一个页面或一个部分。这需要浏览器下载多个文件，这是一个性能问题。您可以使用服务器端编程动态地指定和聚合(并缩小)CSS文件到单个文件中。但是，由于这些文件是分开的，对它们的测试也是分开的，因此可能会在页面/部分之间引入不一致的外观。因此测试变得更加困难。

由你来分析客户的具体需求，并相应地平衡这些问题。

合理CSS的核心原则，摘自CSS重构:从仅追加到模块化CSS

Write in SASS. You'd be insane to forego the advantages of variables, mixins, and so on. Never use an HTML ID for styling; always use classes. HTML IDs, when used correctly, appear only once in the whole page, which is the complete opposite of re-usability — one of the most basic goods in sensible engineering. Moreover, it's really hard to override selectors containing IDs and often the only way to overpower one HTML ID is to create another ID, causing IDs to propagate in the codebase like the pests they are. Better to leave the HTML IDs for unchanging Javascript or integration test hooks. Name your CSS classes by their visual function rather than by their application-specific function. For example, say ".highlight-box" instead of ".bundle-product-discount-box". Coding in this way means that you can re-use your existing style-sheets when you role out side-businesses. For example, we started out selling law notes but recently moved into law tutors. Our old CSS classes had names like ".download_document_box", a class name that makes sense when talking about digital documents but would only confuse when applied to the new domain of private tutors. A better name that fits both existing services — and any future ones — would be ".pretty_callout_box". Avoid naming CSS classes after specific grid information. There was (and still is) a dreadful anti-pattern in CSS communities whereby designers and creators of CSS frameworks (cough Twitter Bootstrap) believe that "span-2" or "cols-8" are reasonable names for CSS classes. The point of CSS is to give you the possibility to modify your design without affecting the markup (much). Hardcoding grids sizes into the HTML thwarts this goal, so it is advised against in any project expected to last longer than a weekend. More on how we avoided grid classes later. Split your CSS across files. Ideally you would split everything into "components"/"widgets" and then compose pages from these atoms of design. Realistically though, you'll notice that some of your website pages have idiosyncrasies (e.g. a special layout, or a weird photo gallery that appears in just one article). In these cases you might create a file related to that specific page, only refactoring into a full-blown widget when it becomes clear that the element will be re-used elsewhere. This is a tradeoff, one that is motivated by practical budgetary concerns. Minimise nesting. Introduce new classes instead of nesting selectors. The fact that SASS removes the pain of repeating selectors when nesting doesn't mean that you have to nest five levels deep. Never over-qualify a selector (e.g. don't use "ul.nav" where ".nav" could do the same job.) And don't specify HTML elements alongside the custom class name (e.g."h2.highlight"). Instead just use the class name alone and drop the base selector (e.g. the previous example should be ".highlight"). Over-qualifying selectors doesn't add any value. Create styles for HTML elements (e.g. "h1") only when styling base components which should be consistent in the whole application. Avoid broad selectors like "header ul" because it's likely that you have to override them in some places anyway. As we keep saying, most of the time you want to use a specific, well-named class whenever you want a particular style. Embrace the basics of Block-Element-Modifier. You can read about it for example on here. We used it quite lightly, but still it helped us a lot in organising CSS styles.

不要用CSS写标题

只是将部分分割成文件。任何CSS注释，都应该是注释。

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

使用脚本将它们合并为一个;如果有必要的话)。您甚至还可以拥有一个漂亮的目录结构，只需让脚本递归地扫描.css文件。

如果你必须写标题，在文件的开头有一个TOC

TOC中的标题应该与您稍后编写的标题完全相同。搜索标题是件痛苦的事。更麻烦的是，人们怎么知道在第一个头文件之后还有另一个头文件呢?注:写toc时不要在每行开头加上类似doc的*(星号)，这只会让选择文本变得更烦人。

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

使用规则或在规则内编写注释，而不是在块之外

首先，当您编辑脚本时，有50%的几率您会注意到规则块之外的内容(特别是如果它是一大块文本;))。其次，(几乎)不需要在外部添加“注释”。如果是在室外，那么99%的情况下都是游戏，所以保持这种状态。

将页面拆分为多个组件

组件应该有位置:相对的，没有填充和空白，大多数时候。这大大简化了%规则，并且允许更简单的元素的绝对:位置，因为如果有一个绝对定位的容器，绝对定位的元素将在计算上、右、下、左属性时使用容器。

HTML5文档中的大多数div通常都是一个组件。

组件也可以被认为是页面上的一个独立单元。用门外汉的话说，如果把一个东西当作一个黑盒是有意义的，那么就把它当作一个组件。

还是以QA页面为例:

#navigation
#question
#answers
#answers .answer
etc.

通过将页面划分为组件，您可以将工作划分为可管理的单元。

将具有累积效果的规则放在同一行上。

例如，边框、边距和填充(但不包括轮廓)都会增加你要样式化的元素的尺寸和大小。

position: absolute; top: 10px; right: 10px;

如果它们在一行中没有那么好读，至少把它们放在很近的地方:

padding: 10px; margin: 20px;
border: 1px solid black;

尽可能使用速记:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

不要重复选择器

如果您有同一个选择器的多个实例，那么很有可能最终会不可避免地得到相同规则的多个实例。例如:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

当可以使用id/classes时，避免使用TAGs作为选择符

首先，DIV和SPAN标签是个例外:永远不要使用它们!,)只使用它们来附加类/id。

这个…

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

应该这样写:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

因为额外悬挂的div没有给选择器添加任何东西。它们还强制使用不必要的标签规则。例如，如果您要将.answer从一个div更改为一篇文章，那么您的风格就会中断。

或者如果你喜欢更清晰的表述:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

原因是border-collapse属性是一个特殊的属性，只有应用于表时才有意义。如果.statistics不是一个表，它就不应该应用。

通用规则是邪恶的!

如果可以的话，避免编写通用的/神奇的规则 除非是css重置/取消重置，否则你所有的通用魔法应该至少适用于一个根组件

他们不会节省你的时间，他们会让你的头爆炸;同时也使维护成为噩梦。当你在编写规则时，你可能知道它们应用在哪里，但这并不能保证你的规则以后不会给你带来麻烦。

除此之外，通用规则令人困惑且难以阅读，即使您对正在设置样式的文档有所了解。这并不是说你不应该写泛型规则，只是不要使用它们，除非你真的想让它们是泛型的，即使它们在选择器中添加了尽可能多的作用域信息。

像这样的事情……

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

.．.与在编程语言中使用全局变量有相同的问题。你需要给他们空间!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

这句话的大意是:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

当我知道一个组件是页面上的单例时，我喜欢使用id;你的需求可能不同。

注意:理想情况下，你应该写足够的内容。然而，在选择器中提到更多的组件相比于提到更少的组件是一个更宽容的错误。

让我们假设您有一个分页组件。您可以在站点的许多地方使用它。这将是编写通用规则的一个很好的例子。让我们假设你显示:阻止单个页码链接，并给它们一个深灰色的背景。为了让它们可见，你必须有这样的规则:

.pagination .pagelist a {
    color: #fff;
}

现在让我们假设你使用你的页码来做一个答案列表，你可能会遇到这样的事情

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

这将使你的白色链接变黑，这是你不想要的。

不正确的解决方法是:

.pagination .pagelist a {
    color: #fff !important;
}

正确的解决方法是:

#answers .header .pagination .pagelist a {
    color: #fff;
}

复杂的“逻辑”评论不起作用:)

如果你这样写:“this value is dependent on blah-blah and height of blah-blah”，这是不可避免的，你会犯错误，它会像纸牌屋一样倒塌。

保持你的评论简单;如果你需要“逻辑操作”，考虑一种CSS模板语言，比如SASS或LESS。

我怎么写一个颜色托盘?

把这个留到最后。为你的整个色盘准备一个文件。如果没有这个文件，你的样式在规则中仍然有一些可用的颜色托盘。您的颜色托盘应该覆盖。你使用一个非常高级的父组件(例如。#page)，然后把你的风格写成一个自给自足的规则块。它可以只是颜色或更多的东西。

eg.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

这个想法很简单，你的颜色托盘是一个独立于基本样式的样式表，你可以级联到它。

更少的名称，需要更少的内存，使代码更容易阅读

名字越少越好。理想情况下，使用非常简单(并且简短!)的单词:文本，正文，标题。

我还发现简单单词的组合比一堆“合适”的长单词(postbody, posthead, userinfo等)更容易理解。

保持词汇量小，这样即使有陌生人进来阅读你的风格汤(比如几周后的你;))，只需要知道单词在哪里使用，而不是每个选择器在哪里使用。例如，每当一个元素被认为是“所选项目”或“当前项目”时，我就使用。this。

自己清理干净

写CSS就像吃东西，有时你会留下一团乱。确保您清理了这些混乱，否则垃圾代码就会堆积起来。删除你不使用的类/id。删除你不使用的CSS规则。确保一切都很好，你没有冲突或重复的规则。

如果您像我建议的那样，在您的风格中将一些容器视为黑盒(组件)，在选择器中使用这些组件，并将所有内容保存在一个专用文件中(或使用TOC和头文件正确地分割为一个文件)，那么您的工作基本上会更容易……

您可以使用工具，如firefox扩展Dust-Me Selectors(提示:指向您的sitemap.xml)来帮助您找到一些隐藏在css nukes和carnies中的垃圾。

保持一个未排序的。css文件

假设您正在设计一个QA站点，并且已经有了“答案页面”的样式表，我们将其称为answers.css。如果你现在需要添加很多新的css，将其添加到unsorted.css样式表中，然后重构到answers.css样式表中。

原因如下:

在完成之后进行重构更快，然后搜索规则(可能不存在)并注入代码 你会写一些你要删除的东西，注入代码只会让你更难删除这些代码 附加到原始文件很容易导致重复规则/选择器

你应该看看边界元法。

理论

BEM试图提供一组用于组织和命名css选择器的指令，以使选择器更具可重用性和模块化，并避免选择器之间的冲突，这种冲突通常会导致意大利面条式的代码和特定的问题。

如果正确使用，它实际上有一些非常积极的影响。

当样式被添加到元素中时，它们的作用是您所期望的 样式不会泄露，并且只影响它们所添加的内容 样式与文档结构完全解耦 不同的风格不需要被强迫凌驾于彼此之上

BEM works well with SASS to bring an almost object oriented style to CSS. You can build modular files, that handle the display of a single UI element and contain variables, such as colours and 'methods' such as how internal elements are handled. While a hardcore OO programmer might balk at this idea, in fact, the applied concepts bring in a lot of the nicer parts of OO structures, such as modularity, loose coupling and tight cohesion and context free re-usability. You can even build in a way that looks like an encapsulated object by using Sass and the & operator.

更多来自Smashing杂志的深入文章可以在这里找到;还有一个来自CCS Wizardry的Harry Roberts(任何参与css的人都应该读一下他的书)。

在实践中

我已经用过它几次了，还用过SMACSS和OOCSS，这意味着我也可以对它们进行比较。我也在一些大混乱中工作过，通常是我自己没有经验的创作。

当我在现实世界中使用BEM时，我用一些额外的原则来增强这种技术。我利用实用工具类-一个很好的例子是包装类:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

我也有些依赖于级联和特异性。在这里，BEM模块将是.primary-box，而.header将是特定重写的上下文

.header {
  .primary-box {
    color: #000;
  }
}

(我尽我最大的努力使所有的东西都是通用的和上下文无关的，这意味着一个好的项目几乎所有的东西都在可重用的模块中)

我想说的最后一点是，无论你的项目看起来多么小，多么简单，你都应该从一开始就这么做，原因有二:

项目越来越复杂，所以打下良好的基础是很重要的，包括CSS 即使是一个看起来很简单的项目，因为它是建立在WordPress上的，JavaScript很少，但在CSS中仍然非常复杂——好吧，你不需要做任何服务器端编码，所以这部分很简单，但是宣传册前端有20个模块和每个模块的3个变体:你有一些非常复杂的CSS !

Web组件

在2015年，我们开始关注Web组件。我对这些还不太了解，但它们希望将所有前端功能放在自包含的模块中，有效地尝试将各种原则从BEM应用到前端作为一个整体，并将分散但完全耦合的元素(如DOM片段、Js (MVC)和CSS)组合在一起，这些元素都构建相同的UI小部件。

通过这样做，他们b将解决css中存在的一些原始问题，我们试图用BEM等东西来解决这些问题，同时使其他一些前端架构更加合理。

这里有一些进一步的阅读材料，还有一个框架聚合物，非常值得一看

最后

我也认为这是一个优秀的、现代的css最佳实践指南——专门为防止大型css项目变得混乱而设计。我尽量遵循其中的大部分。

您还应该了解级联、权重以及它们是如何工作的。

我注意到您只使用了类标识符(div.title)。您知道您也可以使用ID，而且ID比类更重要吗?

例如,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

将使所有这些元素共享一个字体大小，或者颜色，或者任何你的规则。您甚至可以使所有的div都是#page1的后代获得某些规则。

至于重量，请记住CSS轴从最一般/最轻到最特定/最重。也就是说，在CSS选择器中，一个元素说明符被一个类说明符取代，一个ID说明符取代。数字计数，因此具有两个元素说明符(ul li)的选择器将比只有一个说明符(li)的选择器具有更大的权重。

把它想象成数字。个位上的9仍然小于十位上的1。一个有ID说明符、一个类说明符和两个元素说明符的选择器，将比没有ID、500个类说明符和1000个元素说明符的选择器具有更大的权重。当然，这是一个荒谬的例子，但你可以理解。关键是，应用这个概念可以帮助您清理大量CSS。

顺便说一句，在类中添加元素说明符(div.title)是没有必要的，除非你遇到了与其他具有class="title"的元素冲突。不要增加不必要的重量，因为你以后可能会用到这些重量。

这里有一些很棒的材料，有些人已经花了很多时间来回答这个问题，但是当涉及到单独或单独的样式表时，我会使用单独的文件进行开发，然后在部署时将所有在站点上使用的通用css合并到一个文件中。

这样你可以两全其美，提高性能(从浏览器请求的HTTP请求更少)，并在开发时分离代码关注点。