互联网上有许多通用的方案，这里我着重提三点：

1.模块化CSS，提高代码重用 我们知道，一个成熟的网站需要有统一的风格，一致的用户体验，比如：网站的配色，字体的大小，交互行为一致等应该在设计之初就得到确定，而不是由个体开发者来自由的定义。网站同时应存在可以提取出来公用的样式部分（如人人网中个人主页右侧的”最近来访“，”推荐“等处的容器和标题都是相同的展示效果）。那么我们就可以把网站的字体大小，公共控制，共用模块的样式都抽离出来，作为单独的模块来处理。这样，团队中的每个人如果需要这样的样式，都可以用这种公共样式，以此提高代码的重用率。 我认为一个项目的CSS可以拆分成2部分：公共CSS和业务CSS。我们在项目中抽出的这部分可以模块化的CSS就可以归类为公共CSS。这部分的代码命名不应涉及到具体的业务，只应对其在模块中负责的具体逻辑负责。

对于业务CSS，我们需要有统一的命名。如一个网站中有如下几个栏目：文件，社区，社交关系等，在项目规划时，就需要把这块模块的名称定好，比如 文件-files,社区-cmty(community简写)，这样开发人员在写样式时，就可以使用公用的前缀，.cmty-cmtydetail，而不会根据各自的想法，写成.community或是.commu，这一点对于统一风格是尽为重要的，也方便备用人员接手工作。

关于这方面，可以看看网上关于 面向对象的CSS / OOCSS

2.CSS合并、压缩 顾名思义，在团队开发中，开发者会分别处理各自单元的样式，网站上线了，为了减少http连接数，我们需要把这些CSS合并起来做为一个文件来加载，同时，我们在开发时可能会加入一些注释和行缩进，这些都会浪费我们的带宽，我们需要把合并后的CSS文件再进行压缩，事实上，这样的优化效果也是十分明显的，文件大小会节约至少20%。 目前互联网上对CSS合并的处理有两种：静态合并和动态合并。静态合并是指在网站部署上线前，已经完成了CSS的合并，并生成一个静态文件，动态合并是配合后端文件而实现的合并，既请求CSS时，把需要合并的所有CSS名称做为参数，传给一个后端文件（asp,php,aspx等），由该后端文件动态的生成合并后的样式并输出。两种方案各有利弊。

我在这里想表达的是，我们在项目中应根据项目的类型，应用不同的合并方案，门户型网站对首次加载速度要求较高，我们并不需要合并所有的CSS进来，而社区型的网站，用户需要登录才可以访问，那么就可以利用用户输入的时间加载所有的CSS进来，在以后的访问中都可以省去CSS请求的时间。

3.统一CSS书写规范 好处是不言而喻的，无论是后台前台，统一的代码规范是必须的。1.一律使用小字字母2.尽量使用ShortHand形式,在font,margin,padding,background中3.处理父子关系的节点时，使用 .parent-child-grandson（大多时候parent名称与具体业务的模块名称相关） 写法 ，而不使用 .parent .child .grandson，事实证明后者在在团队开发中更容易造成模块间的样式覆盖，同时也更不易于阅读。一个简单的例子：在模块一中有一列表，用第二种写法大致如下：.informationlist{}.informationlist .listitem{}而同时，在模块二中也存在一列表，开发者正好也用到了.listitem，而且认为这个命名不常见，前面没有加上限定，直接使用了.listitem ，这样就极容易造成了样式冲突。或许您提出不同意见：我们强制让所有的样式前面都加一个关于其模块名的限定，把模块二中的.listitem改成 .module2 .listitem，不就ok了？但这样并不好，因为在实际应用中，不能要求所有的样式写法一定要加上模块限定，比如在body节点下的某个浮动节点，我们就不能这样处理。同时，针对第一种写法，我们还可以很轻松开发出一个CSS的检测软件，用来检测语法，判断覆盖。（我们知道判断出.a .b, .a>b,.b的覆盖关系远比.a-b复杂的多）

更多信息请查看IT技术专栏