整体样式表确实提供了很多好处(在其他答案中有描述)，但是根据样式表文档的总体大小，您在IE中可能会遇到问题。IE对从单个文件中读取的选择器数量有限制。限制为4096个选择器。如果你是单片样式表，你会想要拆分它。这种限制只会在IE中暴露出来。

这适用于所有版本的IE。

参见Ross Bruniges博客和MSDN AddRule页面。

我更喜欢在开发过程中使用多个CSS文件。这样管理和调试就容易得多。但是，我建议你在部署时使用像YUI Compressor这样的CSS缩小工具，它可以将你的CSS文件合并成一个整体文件。

从历史上看，使用单个CSS文件的主要优势之一是使用HTTP1.1时的速度优势。

然而，截至2018年3月，超过80%的浏览器现在支持HTTP2，它允许浏览器同时下载多个资源，以及能够预先推送资源。为所有页面使用一个CSS文件意味着文件大小大于所需大小。有了适当的设计，我不认为这样做有任何好处，除了更容易编码。

HTTP2的最佳性能的理想设计是:

有一个核心CSS文件，其中包含所有页面使用的常用样式。 有页面特定的CSS在一个单独的文件 使用HTTP2推送CSS来最小化等待时间(可以使用cookie来防止重复推送) 可选地在折叠CSS上面分开，先推这个，然后再加载剩下的CSS(适用于低带宽移动设备) 如果您想加快未来的页面加载速度，还可以在页面加载后加载站点或特定页面的剩余CSS。

存在一个临界点，在这个临界点上使用多个css文件是有益的。

一个拥有100万以上页面的网站，平均用户可能只看到其中的5个，可能有一个巨大的样式表，所以试图通过大量的初始下载来节省每次页面加载的单个额外请求的开销是虚假的经济。

把这个论点延伸到极致——这就像是建议整个网络应该维护一个大的样式表。显然是荒谬的。

每个网站的临界点都不一样，所以没有硬性规定。这将取决于每个页面的唯一css数量、页面数量以及普通用户在使用网站时可能经常遇到的页面数量。

我使用Jammit来处理我的css文件，并使用许多不同的文件来提高可读性。 在部署到生产环境之前，Jammit完成了所有合并和压缩文件的繁琐工作。 这样，我有许多文件在开发中，但只有一个文件在生产中。

SASS和LESS使这一切都成为一个有争议的问题。开发人员可以建立有效的组件文件，并在编译时将它们全部组合起来。在SASS中，您可以在开发过程中关闭压缩模式以方便阅读，并在生产过程中切换回来。

http://sass-lang.com http://lesscss.org

最后，不管你使用什么技术，一个简化的CSS文件就是你想要的。更少的CSS，更少的HTTP请求，更少的服务器需求。