前几天我收到一个问题，有人问我如何使用 CSS 处理一个网站上多个不同的页面样式和布局。我认为这是一个非常常见的场景。例如，您有一个主页，它与您的博客文章页面不同，与您的关于页面不同，与您的联系页面也不同。
以下是一些注意事项
应该始终存在一个主样式表
很可能，网站页面之间存在很多相似之处。甚至可能包括常见的元素，如页眉、页脚和导航。排版可能在所有页面上都相当一致（如果不是，那么您应该对此有一个充分的理由）。可能存在一个在所有页面上最常见的布局。这些内容都属于主样式表，可以在所有页面上加载。
不同的页面差异多大？有多少个页面？
假设联系页面上有一个联系表单。此表单具有特殊的样式，并且在网站的任何其他地方都没有使用。在我看来，将所有这些样式都包含在主 CSS 文件中是浪费的。这将是一大堆 CSS，会在 99% 不需要它的页面上加载。是否有大量这样的页面？
独特的页面，独特的 CSS 文件
在这些情况下，我的个人风格是在每个页面上加载主样式表，然后根据需要加载一个特定于该页面（或该“类型”页面）的附加样式表。
反对意见
并非所有人都同意这种方法。许多人说每个网页都应该只有一个 CSS 和 JavaScript 文件。这意味着更少的 HTTP 请求和更快的页面，对吧？我认为在很多情况下都是如此，但是当它以牺牲更大的必要文件为代价时，结果又如何呢？当您还考虑到这对组织来说是打击时，我认为多个 CSS 文件是值得的。
为什么我认为这有效
在绝大多数情况下，您不会有 100 种不同的布局。如果有，您可能应该退一步，重新思考这个网站上发生了什么。如果您真的需要 100 种布局，您应该考虑使用基于网格的框架。我绝不会建议为这 100 个页面中的每一个创建 100 个不同的独特样式表。这超出了合理可持续性的范围，违背了 CSS 的精神。但对于许多具有少数不同页面样式和几个怪胎的网站来说，这无疑是我最喜欢的方法。
我同意。我最近开始使用单独的样式表来处理单独的元素，比如字体、布局、其他元素。我还没有考虑过为每个页面创建单独的样式表。我一直想知道它究竟有多大区别，尤其是在宽带现在如此普遍的情况下。在页面上加载一些未引用的额外类真的会产生巨大的影响吗？如果是，除了加载时间之外，在哪些方面会有影响？
我通常使用单个主样式来处理整个网站，然后将单个元素（比如表单）拆分到页面特定的样式表中。这通常意味着只有在少数页面上才会出现额外的 HTTP 请求；这通常比在不使用这些样式的页面上加载页面特定样式更有效地使用带宽，尤其是在有多个具有独特格式的页面时。
这正是我在阅读这篇文章时想到的。styles.css，以及 forms.css 等等。
好的文章，我一直都在这样做，一直在想将所有内容都包含在一个文件中是否更好 - 我不喜欢为不需要自定义表单信息的页面加载自定义表单信息。
太巧了！我刚在一个正在开发的项目中应用了这个技巧。
我可以告诉你...它确实很有帮助！
如果您有一个特定于特定页面的 CSS，这不是嵌入样式的用途吗？在我看来这更有条理，因为如果您移动具有自身样式表的那个文件，您必须记住它必须与之一起移动。
我同意使用全局样式表来处理常见的导航和排版，就像您所说的那样。然后，如果您有一个格式类似的小部分页面（比如您示例中的博客），您可以在该组中添加一个额外的样式表。但我认为如果它只适用于一个页面，使用嵌入样式表更合理，就像您对一个元素使用内联样式一样。
有人使用嵌入样式表吗？或者您始终要么创建一个唯一的样式表，要么将其添加到您的主样式表中？
我认为创建单独的样式表更好。即使您非常确定这个页面是“一次性”的，您永远不会真正知道。如果以后您需要一个非常相似的页面，您也可以将此样式表重新用于该页面，并保持最佳实践。
我同意您的观点...在大型应用程序的情况下，没有人会希望在所有页面上加载一个 5000 行的 CSS，只是为了减少 HTTP 请求的数量...在这种情况下，您会耗尽服务器带宽；)
如果您有 10 多种页面类型，这行不通。我更喜欢将 CSS 分成 layout.css、typography.css、reset.css、print.css，在某些情况下将表单/按钮/其他元素分离到 forms.css 中。然后在每个部分内将它们分成与页面特定样式相关的部分。
人，这太对了。我经常看到布局看起来不同，但没有一个单一的样式表。真是令人作呕。
我的答案是使用唯一的 ID 标签在每个页面的主体中，然后在站点范围的样式表中添加特定于该页面的声明。
例如，要仅在“联系我们”页面上使文本输入更大
<body id="contactus">...
<style>
input { font-size: 1.0em }
#contactus input { font-size: 1.2em }
</style>
我从几年前的一个很棒的博客中读到了这个技巧
https://css-tricks.org.cn/id-your-body-for-greater-css-control-and-specificity/
;)
— SEAN O
您也可以使用一些技巧，使用 php 根据您所在的页面来更改主体的 ID，然后相应地设置 CSS；)
我同意。除非其他页面的设计/布局完全不同，否则我更喜欢这种 body 类消息。
这也是我使用的方法。我可以理解使用多个样式表，但我很少看到有人使用这种方法……但对于超级有条理的人来说，它可能有效。
我已经使用这种方法很长时间了。它的优点是，你不需要使用脚本就能实现它，它可以在纯 html 中工作。当然，样式表中的组织是保持一切井井有条并正常工作的关键。
我喜欢将所有内容都保存在一个表中。它更容易编辑，加载速度也更快。
页面样式之间的差异通常只是布局，因此在表中只需要几个额外的 div 来设置样式。
我喜欢在开发过程中使用多个样式表来实现模块化，但同时，我更喜欢在生产环境中使用单个样式表来提高性能。
Sprockets 解决的是 JavaScript 的问题，但我不知道它将来是否会支持 CSS。一个 Sprockets 的样式表版本将为我们提供模块化和性能两全其美的解决方案，就像它为 javascript 所做的那样。
这不是 CSS 中存在 @import 功能的**确切**原因吗？它允许你从第一个 CSS 文件中导入另一个 CSS 文件 - 这允许你做你想要做的（一个主 CSS 文件和大量根据页面加载的其他文件）。
@import 确实允许你从一个 CSS 文件中加载其他 CSS 文件，但据我所知，它不能以条件方式加载。CSS 文件如何知道它是在关于页面还是联系页面？
在 ExpressionEngine 中，你可以使用 url 段条件来让它知道它在哪个页面上。这对每个人来说都不实用，但我相信其他 CMS 也有类似的功能。
0) { // 如果页面是 contact.php
@import “contact.css”;
}
?>
嗯，不允许使用 php 代码……
我的意思是反过来。
你有一个博客页面，它有 blog.css，它加载“main.css”和“forms.css”。联系页面 (contact.css) 也加载“main.css”和“forms.css”。
关于页面 (about.css) 只加载“main.css”，不加载“forms.css”。
当然，这样做唯一的缺点是，你需要将这些特定的 CSS 文件添加到指定的 HTML 文件中。
@import 规则确实允许你将样式表的调用集中在一个 CSS 文件中。确保所有 HTML 页面都链接到一个单一的样式表，该样式表将只管理对其他 CSS 的调用。因此，无需更改 HTML 页面，你可以禁用、删除或添加任意数量的样式表。
我认为这都是关于选择。
我通常会尝试保持简单，只使用一个包含所有通用元素的主样式表。但如果感觉合适，我会向项目中添加另一个样式表 - 我不知道为什么不能这样做。
继续挥舞吧！
我一直使用这种方法，为什么在页面上不需要的时候加载 CSS 呢？我通常会做特定部分的 CSS，因为我创建的是电子商务网站，所以它更像是一个产品页面、账户和结账的 CSS 文件，然后是包含所有通用 CSS 的主样式表。当你在谈论大型应用程序时，可以为页面或部分特定 CSS 分离的 CSS 量可能与额外的服务器请求一样糟糕，我敢打赌。
在我看来，我完全不同意这种方法，但嘿，如果它适合你，那就继续吧。我同意设计师的观点。你只需要将其分离成高层次的桶，比如 layout.css、color.css（你漏掉了这个）、typography.css、reset.css 和 print.css。
无论如何，你都不应该将样式嵌入文档中，即使它是特定页面的样式。
这真的取决于项目的大小，以及是否需要使用这种方法。大多数情况下，我会使用单个 CSS 文件，并在 body 上简单地使用 ID 或类，并根据该 ID 或类对页面进行样式设置。
如果我处理的是一个非常复杂的布局，我可能需要为产品页面模板编写 500 行代码，为类别页面编写 500 行代码等等，那么我更有可能将它们拆分成单独的文件，以便它们可以独立于彼此进行处理。
在这种情况下，我可能还会发现使用一个 reset.css 文件来处理我的重置，一个 global.css 文件来控制 header、导航、footer，然后一个 product.css 和 category.css 来处理这些复杂的页面。
关于这个话题的任何争论都不会结束，因为没有正确答案。如果它对你和你的团队有效，那么它就是工具箱中的另一个工具：）
因此，@import 规则允许保持一些内容相同，而其他内容则不同。
对于 CMS 场景，由于内容的动态性，最好将所有内容都保存在一个样式表中。
我今天也在考虑这个问题，我们正在修改我们的旧网站。一些细微的改变，比如根据你的目标页面改变背景。当你完成你的项目时，它似乎会动态地流动，并使它独一无二。
Chris，我用独特的样式表和作为主样式表的一部分来对那个页面进行样式设置。我认为，关于什么时候一种选择比另一种选择更好，存在平衡。例如，如果你的联系表单只需要一行 css 代码，那么将其包含在主样式表中更有意义。
这主要是关于理解利弊。你必须权衡每个页面的 css 的权重与一个页面上的额外 http 请求。
目前，我使用的是一个样式表。这种方法还可以。但如果有人在一段时间后进行编辑……他可能会对此感到困惑。他可能会尝试编辑 main style.css 而不是特定页面的 css？那么这种方法可能会失效。
浪费时间去做它！
节省一些字节，浪费 HTTP。
你说
许多人说每个网页都应该只有一个 CSS 和 JavaScript 文件。这意味着更少的 HTTP 请求，页面速度更快，对吧？我认为这种情况在很多时候都是如此，但当它以牺牲必要大小的文件为代价时，就会出现问题。
你能解释一下“但当它以牺牲必要大小的文件为代价时”吗？
我认为他的意思是，当使用 1 个 CSS 文件时，联系页面、关于页面等的内容也会被加载，而用户只浏览博客页面。
联系页面和关于页面的 CSS 是无用的，并且会使文件“大于必要”。
我喜欢尽可能只使用一个样式表，但我过去不得不使用多个样式表。使用一个样式表肯定更容易，因为所有内容都集中在一个地方，我倾向于将我的 CSS 分开，以便标题标签都放在一起 - 这在你必须回去编辑它时会更容易，特别是如果其他人正在进行编辑！
这完全取决于项目以及需要放到单独的样式表中的 CSS 量。我只在需要大量在其他地方不需要的 CSS 时才这样做。对于几行 CSS 来说，这样做没有意义。
关于 @import 的一个快速问题。哪个样式表优先级更高。例如，我有 structure.css、print.css、reset.css、ie.css。
你总是可以在服务器上使用 php 处理 css，然后发送一个只包含所需样式的表。
@Thomas 我也倾向于这样做。如果我正在开发一个应用程序，我会为网站的每个“部分”创建一个样式表，然后只在部署时使用我正在使用的任何语言创建一个大型样式表。
如果我无法访问该样式表，我会将 global.css 文件拆分成多个部分。这会让管理变得稍微困难一些，因为文件变得非常长，但仍然可以忍受。
您可以创建脚本将所有 CSS 文件合并并缩小，这样可以兼顾两者优点。
同意。您可以随意组织，最终会将一个合并并缩小的 CSS 文件发送到浏览器。
还可以检查任何合并后的文件是否发生变化，然后在生成的缩小 CSS 文件中追加一个 get 参数（例如时间戳），以便立即反映更改。当您需要紧急修复时，并且真的不想依赖浏览器/代理的善意来获取新版本时，这非常方便。
是的，但是如何在特定页面上加载额外的样式表呢？
我知道 PHP 必须参与在头部加载额外的样式表，但是您使用什么来定义何时加载它们或不加载它们呢？
页面 ID 吗？
加载 main.css / 开始 PHP / 如果页面 ID 为 355，则该页面必须是联系我们 / 回显指向 contactus.css 的链接 / 否则，如果页面 ID 为 356，则该页面必须是关于 / 回显指向 about.css 的链接 / 否则不执行任何操作 / 结束 PHP
…还是页面标题？
加载 main.css / 开始 PHP / 如果页面标题包含“联系我们”，则该页面必须是联系我们 / 回显指向 contactus.css 的链接 / 否则，如果页面标题包含“关于”，则该页面必须是关于 / 回显指向 about.css 的链接 / 否则不执行任何操作 / 结束 PHP
今天我正在使用特定的 CSS 文件，但它们都加载在 wp 头部，无论访问的是哪个页面。
可能类似于
<link rel=”stylesheet” href=”/css/cssgen.php?sheet1=main&sheet2=contact” type=”text/css” >
我会使用页面 ID，因为页面的标题可能相同，而页面 ID 则保证是唯一的。我假设您指的是 WordPress。
在纯 PHP 中：最快的（但不是最好的）方法是获取页面的 URL，然后打印与该页面关联的样式表。
我使用多个样式表来简化多个“设计师”协作时的工作。但是，我会尽量限制文件数量。我们有一个用于布局的文件（我负责）和一个用于内容的文件（他们负责）。这使得他们可以快速轻松地更改“内容样式”，而不会影响网站的整体布局。
有时我会根据会拉取该文件的页面数量再添加另一个文件……例如，如果有多个画廊页面，则会添加“画廊”文件。
我一直遵循这种方法，我认为它是速度和组织之间最好的平衡。
我喜欢这种方法。在我们的网站中，我们通常有一些主要的样式表来处理所有页面上所有共同的细节（例如布局、排版、主题、页眉、页脚等），然后我们使用单独的 CSS 文件来处理具有各种功能的特定页面。
例如，我们网站上只有一个页面使用 dojo JavaScript 框架的 tabContainer 和该页面“内容”部分中的特定布局。我创建了一个特定的 CSS 文件来适应这种情况。
实际上，网站上没有完全不同的页面。但也没有页面完全相同。这是使用 Expression Web 之类的 HTML 编辑器进行工作的乐趣之一。虽然 CSS 在构建网站页面方面非常有用，但它们必须与页面之间 CSS 的分离和组织相一致地精心完成。
毫无疑问，为不同的页面创建不同的样式表会让生活更简单，我也是这样做的。但我真的很喜欢@Lars 的方法——为不同的元素创建不同的样式表。必须尝试一下！
好主意
我经常使用相同的模式。有时很难分离 CSS 代码，但这种方法确实很有用。
PD：请原谅我的英语！
我不得不同意 Dave Woods 的观点，这场争论真的无法得出结论，因为没有对错之分。
话虽如此，我发现有趣的是，没有人费心去解决 CSS 中图像是否要拆分成页面特定 CSS 文档这一决定因素的问题。
请考虑
如果您使用一个文档来管理网站的所有 CSS，并且您已经通过 body ID 将文档分解成多个部分，以便每个页面在您的 1 个 CSS 文档中都有自己的“部分”——**是的**，您将只对该文档进行一个 HTTP 请求，并且**是的**，您可以使用压缩工具来最小化文档的大小。
但是，您无法阻止在 CSS 中声明的所有图像加载到页面上，即使只有一小部分图像实际上是渲染您正在查看的页面所必需的。在 CSS 中定义的每个背景图像都会生成另一个 HTTP 请求。即使图像本身相对较小，您仍然会将它们的权重（以字节为单位）和额外 HTTP 请求的延迟考虑在内，从而影响页面的下载时间（在某些 CMS 或企业级 Web 应用程序情况下，可能会将页面大小增加 60k 到 80k，压缩不会改变这一点）。这种开销将添加到您网站的**每个**页面，无论它与当前页面是否相关，并且**这**将是为每个页面创建单独 CSS 文档的主要论据。
通常，我们会创建一个 global.css 文档，它将 design.css / typography.css / print.css 合并成一个文档，并包含一些网站范围内使用的一些非常常见的通用类分配。这使我们能够压缩和缓存这个文档，该文档基本上在网站（或在我们的例子中，应用程序）转移到生产环境后就不会再改变。然后，创建页面级 CSS 文档，并以它们所在的页面的名称命名，这些文档中加载了任何额外的页面特定 CSS（包括图像）。然后可以单独压缩和缓存该文档，以免影响主 CSS 文档的缓存。通过这种方式，我们只加载渲染当前页面所需的图像（并生成 HTTP 请求）。
如前所述，这种方法更适合大型 CMS 开发、企业应用程序开发或模块级开发（例如小部件、dnn 模块等），但我确实鼓励设计师考虑这一点，即使是在处理较小的网站时也是如此。在您的 CSS 中声明的图像（它们的大小和频率）对页面性能的影响远远大于 CSS 文档的总字符大小（以字节为单位），或者页面特定 CSS 文档会产生的额外 HTTP 请求。
David，我真心希望人们有耐心一直读到你的评论，因为你是第一个提出个人偏好以外的东西的人。我完全忘记了这种鲜为人知的行为，非常感谢你提出来！
我想知道，这是**所有**浏览器都这样吗？还是至少有一些浏览器足够智能，可以知道哪些图像需要加载？
John，
我相信这是所有浏览器的默认行为（至少据我所知）。我能想到的浏览器唯一可以确定哪些图像要显示在页面上的方法是，让渲染引擎解析页面的所有 HTML 和 CSS，然后只对在页面上找到父 CSS 类的图像执行 gets 操作。然而，在这一点上，浏览器已经将整个 CSS 文档读取到页面中了……所以我不确定浏览器内核在那一刻将如何处理图像的条件加载，因为页面通常是从上到下加载的。
看到这种性质的东西会很有趣，尽管我们可以通过更加谨慎和周到地进行 CSS 开发来有效地做到这一点。:)
我同意 EVula 的观点，但是我认为，这也取决于整个网站的大小。如果我的网站有数千个页面，或者只有 5 个页面，则会有所不同。对于后一种情况，我认为您不需要 5 个样式表——我认为 1 个样式表可以很好地处理它。
Chris，好文章。
我必须承认，有一段时间我一直使用一个主样式表来控制整个页面，但文件不断膨胀（我指的是 CSS 代码行的数量，而不是文档的大小），维护网站变得越来越困难。所以我开始使用你提到的系统——每个页面一个样式表。大多数样式表几乎完全相同，所以工作起来更容易。而且你知道，当你对一个页面使用一个主样式表时，有时你做的更改恰好是某个页面需要的，但它会破坏另一个页面的某些内容。而使用多个样式表时，你就不必担心这个问题了。
我不确定你是否理解我的意思，我的英语还在学习中，但我希望你能够理解。总之，我建议每个人都使用这种多样式表系统。它很有帮助。
你说“大多数样式表几乎完全相同”... 我只想确认所有在不同页面上“几乎完全相同”的样式应该放在一个单独的主样式表中，只有那些在备用样式表中非常不同的样式才应该放在它们自己的样式表中。如果每个页面都有一个基本相同的样式表，只是有细微的改动，那就糟糕了。
在我看来，单独的样式表是内容展现的额外灵活层。我们可以把它看作是对 csszengarden 方法的一种变体：你开发一个包含所有通用元素的主样式表，然后添加一些变体。HTML 代码可以保持一致，但 CSS 可以让它看起来略有不同，更有趣，有点像印刷出版物的感觉。
如果/何时使用，它还能让你以不同的方式设置某些元素的样式，同时还能让你重新设置整个网站的样式，而不会丢失那些在“备用”设计中仍然有效的元素。CSS 的季节性变化就是一个很好的例子。
这还打开了更多关于内容的可能性，你可能想为文章作者提供多种海报样式（带有预览），这样他们就可以选择哪种布局更适合他们的内容（或者不选择，并将这个权力交给内容编辑器/版主）。
我一直都在尝试使用它（自从 Zikula 失去了“多站点”功能后，人们就不得不想办法应对这种情况），到目前为止看起来还不错（管理界面通常使用从主站点获得的单一设计，现在不再是这样了。网站上多个地方可以拥有不同的主题，等等，等等）。
这种实现方式就是为什么我会使用多个样式表：CSS Zen Gargen 风格。但问题是：我们现在讨论的是单个网站。如果你要做的网站像 Jason Santa Maria 的个人网站 上那样使用 模块化布局系统，那么我就能理解使用单独的样式表。
但在当前的应用中，这种情况不太可能发生。一个独特的页面可能只需要做一些微小的更改，例如不同的背景，三栏布局而不是两栏布局，等等：这些改变不需要很多 CSS 代码来实现。
不过，在几种情况下这样做会很有用。一个乐队的网站可以使用相同的 HTML 来创建分支页面来展示他们的专辑。这反过来让他们可以使用 CMS 来管理这些专辑的内容（www.nin.com 就是一个很好的例子）。
一个足球队的网站也是一个很好的例子。把它看作一个网站，它为少年联盟、青年联盟和成年联盟分别提供了不同的设计。它们都使用不同的 CSS，但可以共用相同的 HTML。这也帮助设计师针对目标受众的每个细分群体。
让我们看看它是如何实现的：CSS 文件将是一个名为 general.css 的文件，它包含一些基本的尺寸规则、颜色和字体；我们还将有一个用于定位的 CSS 框架，从那时起我们将为网站上每个需要使用不同样式的页面组创建单独的 CSS 文件。
在我看来，使用这种方法，可以对网站上任何页面组使用相同的 HTML 基础（这通常是 CMS 的情况）。
我使用这种方法的经验来自使用 Zikula 和 Pagesetter 模块。使用这个模块，你可以生成带有自定义字段的自定义出版物。每个出版物可能需要作为同一网站的一个独立部分进行处理。当你客户表达需要超过 5 种出版物时，你就会明白使用这种方法的必要性。你的模板将受益于 general.css 文件和定位框架，但其他展示内容也将受益于可分离性。
使用这种方法进行修订将避免类之间的冲突，也意味着你可以更快地应用客户对每个特定部分所需的任何更改。
general.css 文件（甚至 branding.css）意味着你还可以根据季节调整 CSS（时尚设计网站就会想到这种情况）。
现在，我不认为对简单的网站，或者使用简单的脚本时，使用这种技术有任何意义。但对于非常非常复杂的网站，我认为这将有利于保持理智（一个 Web 门户也会从中受益）。
但这只是我个人的看法。
我喜欢这种在开发和最终结果中都具有灵活性的方法。当然，随着时间的推移，我更多地转向使用多个样式表的方法，而不是试图依赖一个大型的 CSS 文件来控制整个网站。它以很少的性能成本，提供了对页面布局和外观的显著控制能力。
用某些 CMS 来有条件地加载样式表可能会更加困难。我已经为 Joomla 找到了一种相当优雅的方法，而且我从上面的评论中注意到 Expression Engine 也有这种能力。在动态环境中，尤其是当页面被技术水平较低的人员更改和更新时，预先设置这种样式灵活性会是一个巨大的好处。
正如其他人所提到的，我更倾向于在生产环境中使用单个样式表。我当然不会要求为首页使用多个样式表。
多个 CSS 图片的问题可以通过使用雪碧图轻松解决。我更担心每个 HTTP 请求可能造成的 500 毫秒延迟，而不是在单次交付中添加一些不必要的 KB。在低带宽速度下，你需要大约 2000 行未压缩的 CSS 才能将下载时间增加 500 毫秒。
如果不需要在每个页面上至少访问服务器两次，那么它将使后续的网站导航更加流畅。
CSS 雪碧图只是一种可以有效使用的解决方案。根据设计的不同，使用雪碧图可能根本不切实际。一个例子是在使用带有 alpha 透明度和阴影的 .png 图片时。例如，一个具有圆角和阴影的四向扩展框，内部有一个四向渐变图。CSS 雪碧图在这里行不通。
此外，根据作为雪碧图使用的图片的复杂程度，你可能只是在原始图片中添加了一些“额外”的字节，但你也会将所有这些字节添加到甚至没有使用该图片的页面中。对于一个简单的 5 页面网站来说，这可能不是问题...(除非雪碧图本身是 30K)...但对于较大的网站（或基于模块的设计，例如门户网站或复杂的企业网站），你通常会尝试节省每一 KB。这包括代码大小、HTTP 请求数量、图片大小、脚本文件大小、.swf 文件大小等。
通过使用特定于页面的 CSS（即使不使用雪碧图），根据该页面上设计/内容展示的复杂程度，单独的文档可以让你为该页面节省 12KB 到 60KB 的大小。这对宽带用户来说可能影响不大，但如果这个页面每月被访问 100,000 次，那么这 12KB 到 60KB 的增加将反映在带宽利用率、磁盘传输等方面，而这些都是网站托管成本的一部分。
另外，请记住，影响页面性能的因素有很多，例如网络延迟、页面交付时服务器承受的压力、是否启用了压缩、缓存等。
作为设计师（和开发人员），我们的重点是提供尽可能好的最终用户体验，同时满足客户设定的目标和愿景。为此，我们必须考虑所有可以最大化交付并最小化开销的方法。对我来说，这比关于一个样式表与特定于页面的样式表的哲学争论要重要得多。
并非每个人都有宽带，并非每部手机都能使用 3G...随着移动互联网的兴起，UI 设计师开发更智能、更高效的网站设计将变得越来越重要，而特定于页面（或模块化）CSS 就是实现这一目标的一种方法。
我总是使用一个主 CSS 来设置通用布局设置和许多页面使用的通用选择器。对于单页面或页面集，我总是创建包含特定页面选择器的唯一 CSS。
通常，我讨厌谈论“用户带宽负载”... 那又怎样？如今，每个人都从互联网上下载 GB 级别的數據，所以我认为 4KB 或 10KB 的 CSS 不是问题...
您好,
我喜欢你的方法，但当你为 Moodle 这样的平台创建皮肤时，很难遵循它。在需要时可以创建不同的 CSS 文件，这对维护很有用；但如果你在皮肤的配置文件中注册了所有 CSS 文件，所有 CSS 文件都将被混合在一个大型文件中。因此，所有 CSS 文件都将在所有页面中加载。
尽管它仍然有利于维护，因为你知道特定样式的位置，但即使没有使用，每个 CSS 文件也会被加载。
你可以绕过它，在需要时添加特定的样式表，但这并不常见。
个人观点：我试图将 CSS 文件分开，以获得逻辑结构。这有助于我了解所有内容的位置。我将它置于性能问题之上。
只是想知道
单独的文件真的会严重影响性能吗？
顺便说一句，感谢 Chris 的优秀帖子，它们对我帮助很大。它们让像我这样的初学者更容易学习。