网上流行的CSS管理方式讲来讲去无非也就以下几种：

1. 对于单个页面那种非常简单的，其实也可以直接把所有的样式写在一个外部文件里就行，或者直接写在页面的头部里，没有必要去纠结繁琐的CSS文件管理。

2. 读过《精通CSS：高级Web标准解决方案》那本书的人都应该对作者如何去组织、规划和维护样式表有深刻印象：多个CSS文件可以利用@import导入的页面中，好处是减少HTTP请求数，坏处是导入样式要比链接样式的速度慢，而且导入的文件有顺序的规定，顺序不当常常会出现样式没办法应用等错误，也是让人无比纠结。

而对于全部写在单个文件的，其内部最好有合理的设计结构和注释：

一般性样式：

• 主体样式
• reset样式
• 链接
• 标题

辅助样式：

• 表单
• 通用和错误
• 一致的条目

页面结构：

• 标题、页脚和导航
• 布局
• 其他页面结构元素

页面组件：

• 各个页面

覆盖：

然后使用大注释块来分割每个部分

/* @group general styles
---------------------------------------------------------------*/
// 而小区域可以用小块注释
/*nav*/

这种分割方法虽然明确，但是需要开发人员进行判断，项目很大时，这种判断是需要耗费很多时间去很分析的，好的组织和规划是需要耗时间的...

自我提示：

适当的注释可以为后期的开发有很大的帮助，例如：

/*字体颜色定义说明
@colordef #F00; 红色
*/

也可以使用@tudo来表示某些东西需要后期修改、修复或复查，用@bugfix表示代码或特定浏览器遇到的问题，用@workaround表示并不完善的权宜之技（这些都跟JS的的相似，统称为gotcha）

/*@tudo 网站上线之前记得删除此规则*/
/*@bugfix 解决IE6的双边距问题*/
/*@workaround 我试图去解决这个在IE6下的XXX问题，但它似乎表现的还不够好*/

3. 另外网上也流行一种模块化css的文件分类方法：

• reset.css // 对阅读 器的默认样式执行 重设
• layout.css // 管理页面的布局
• typeset.css // 图文的编排与
• color.css // 统一管理颜色的搭配
• print.css // 打印效果样式
• ie.css // 把对ie的hack单独分开

或：

• reset.css
• header.css // 头部的所有样式
• container.css // 除头部/底部外的中间区域样式
• footer.css // 底部样式
• print.css
• ie.css

以上的分类看似合理且仅仅有条，但管理起来很麻烦，也不是每个人都可以百分百了解每个CSS文件里面的内容，所以疑问就来了：

• 效率疑问 与最终目的。在站点 内容上面，如果改某一个区域的内容，可能要多个 CSS都改。这样一来，本来基本 的一个修改，开始变得复杂起来。并且，如果多个都改，可能会使我们忽略了某些东西，又须要 进一步调试，这样不仅肯使最终目的实现延后，还是一个效率的疑问 。
• 调用尽可能少的CSS文件。大多楼情况下，一个站点 都是分成头部，中部和底部，并且，一般，要做新的频道/页面之类的东西，都不会变动头部和底部，而只是变动中间部分。这样一 来，所有CSS文件都要调用，因为，HTML和CSS的模块化并不一致。这样，就会导致服务器承受更多的压力。这是一个方面。另一个方面是，如果新页面中 某些元素与其他页面有冲突，我们可能要搞一大堆关于优先性选择的代码，添加 代码量。这些都不是我们想要的。这就为什么要把header.css和 footer.css分开来的原由 。
• 多人合作上的疑问。如果我们多个人在工作，大家的分工可能是，有人完成头部的导航，有人完成底部的搜索条，有人完成中部新页面的构建。这样一来，大家都同时在改多个 文 件，并且，改的东西不同。如果要更新到服务器，就要先比较 ，再更新。（当然，现在有版本管理这样的软件。但是，同时工作的话，版本也是一个疑问 ，要相信， 或许更新永远都改不上改动 。）

4. 第四种就是采用CSS框架了，比如我最喜欢的960 GRID和YUI CSS Framework，大体原理一样：一个css reset一个font定义和一个核心的Grids网格布局文件，然后就是各种布局位置计算,然后自己就可以写页面的其他样式了

5. 使用CSS预处理器（Sass、LESS 和 Stylus）帮助简化CSS内容和组织管理。

我自己的管理组织管理方法：

之前看过的《编写高质量代码 Web前端开发修炼之道》，作者给出了一个非常通用