CSS的管理一直是個讓人有點頭疼的問題，沒有絕對的對錯，無非就是為了方便管理、修改和多人合作罷了；

網(wǎng)上流行的CSS管理方式講來講去無非也就以下幾種：

1、對于單個頁面那種非常簡單的，其實也可以直接把所有的樣式寫在一個外部文件里就行，或者直接寫在頁面的頭部里，沒有必要去糾結(jié)繁瑣的CSS文件管理

2、讀過《精通CSS：高級Web標準解決方案》那本書的人都應(yīng)該對作者如何去組織、規(guī)劃和維護樣式表有深刻印象：

多個CSS文件可以利用@import導(dǎo)入的頁面中，好處是減少HTTP請求數(shù)，壞處是導(dǎo)入樣式要比鏈接樣式的速度慢，而且導(dǎo)入的文件有順序的規(guī)定，順序不當(dāng)常常會出現(xiàn)樣式?jīng)]辦法應(yīng)用等錯誤，也是讓人無比糾結(jié)。

而對于全部寫在單個文件的，其內(nèi)部最好有合理的設(shè)計結(jié)構(gòu)和注釋：

（1）一般性樣式：

主體樣式；reset樣式；鏈接；標題

（2）輔助樣式

表單；通用和錯誤；一致的條目

（3）頁面結(jié)構(gòu)

標題、頁腳和導(dǎo)航；布局；其他頁面結(jié)構(gòu)元素

（4）頁面組件

各個頁面

（5）覆蓋

然后使用大注釋塊來分割每個部分

/* @group general styles  
---------------------------------------------------------------*/ 

而小區(qū)域可以用小塊注釋：/*nav*/

這種分割方法雖然明確，但是需要開發(fā)人員進行判斷，項目很大時，這種判斷是需要耗費很多時間去很分析的，好的組織和規(guī)劃是需要耗時間的...

自我提示：

適當(dāng)?shù)淖⑨尶梢詾楹笃诘拈_發(fā)有很大的幫助，例如：

/*字體顏色定義說明  
@colordef #F00; 紅色  
*/ 

也可以使用@tudo來表示某些東西需要后期修改、修復(fù)或復(fù)查，用@bugfix表示代碼或特定瀏覽器遇到的問題，用@workaround表示并不完善的權(quán)宜之技（這些都跟JS的的相似，統(tǒng)稱為gotcha）

/*@tudo 網(wǎng)站上線之前記得刪除此規(guī)則*/ 
/*@bugfix 解決IE6的雙邊距問題*/ 
/*@workaround 我試圖去解決這個在IE6下的XXX問題，但它似乎表現(xiàn)的還不夠好*/ 

3、另外網(wǎng)上也流行一種模塊化css的文件分類方法：

reset.css // 對閱讀 器的默認樣式執(zhí)行 重設(shè)  
layout.css // 管理頁面的布局  
typeset.css // 圖文的編排與  
color.css // 統(tǒng)一管理顏色的搭配  
print.css // 打印效果樣式  
ie.css // 把對ie的hack單獨分開 

或：

reset.css  
header.css // 頭部的所有樣式  
container.css // 除頭部/底部外的中間區(qū)域樣式  
footer.css // 底部樣式  
print.css  
ie.css 

以上的分類看似合理且僅僅有條，但管理起來很麻煩，也不是每個人都可以百分百了解每個CSS文件里面的內(nèi)容，所以疑問就來了：

（1）效率疑問 與最終目的

在站點 內(nèi)容上面，如果改某一個區(qū)域的內(nèi)容，可能要多個 CSS都改。這樣一來，本來基本 的一個修改，開始變得復(fù)雜起來。并且，如果多個都改，可能會使我們忽略了某些東西，又須要 進一步調(diào)試，這樣不僅肯使最終目的實現(xiàn)延后，還是一個效率的疑問 。

（2）調(diào)用盡可能少的CSS文件

大多樓情況下，一個站點 都是分成頭部，中部和底部，并且，一般，要做新的頻道/頁面之類的東西，都不會變動頭部和底部，而只是變動中間部分。這樣一 來，所有CSS文件都要調(diào)用，因為，HTML和CSS的模塊化并不一致。這樣，就會導(dǎo)致服務(wù)器承受更多的壓力。這是一個方面。另一個方面是，如果新頁面中 某些元素與其他頁面有沖突，我們可能要搞一大堆關(guān)于優(yōu)先性選擇的代碼，添加 代碼量。這些都不是我們想要的。這就為什么要把header.css和 footer.css分開來的原由 。

（3）多人合作上的疑問

如果我們多個人在工作，大家的分工可能是，有人完成頭部的導(dǎo)航，有人完成底部的搜索條，有人完成中部新頁面的構(gòu)建。這樣一來，大家都同時在改多個 文 件，并且，改的東西不同。如果要更新到服務(wù)器，就要先比較 ，再更新。（當(dāng)然，現(xiàn)在有版本管理這樣的軟件。但是，同時工作的話，版本也是一個疑問 ，要相信， 或許更新永遠都改不上改動 。）

4、第四種就是采用CSS框架了，比如我最喜歡的960 GRID和YUI CSS Framework，大體原理一樣：一個css reset一個font定義和一個核心的Grids網(wǎng)格布局文件，然后就是各種布局位置計算,然后自己就可以寫頁面的其他樣式了

5、使用CSS預(yù)處理器（Sass、LESS 和 Stylus）幫助簡化CSS內(nèi)容和組織管理，這個可以常見詳細

我自己的管理組織管理方法：

之前看過的《編寫高質(zhì)量代碼 Web前端開發(fā)修煉之道》，作者給出了一個非常通用的css組織方式:base+common+page,但其實也有很多人喜歡把base直接寫在common里面，反正也是站點的幾乎所有頁面都調(diào)用，我用的最多的是commom（全站調(diào)用）+page（獨立頁面樣式，名字自定義也可）兩個文件的方式（也是因為后來項目的原因才慢慢喜歡上的），當(dāng)然前提是全站風(fēng)格統(tǒng)一， 可以做得很模塊化，需求變動不大；common的的樣式權(quán)限一定要在應(yīng)用效果的情況下保持盡可能低，以方便后期需求突變時可以強行覆蓋；

其實組織樣式考慮因素還是有的，只是一般我比較通用以上那種：

（1）首先當(dāng)然要看項目的規(guī)模和訪問量

項目的規(guī)模大小是組織樣式一個非常重要的參考基準，小網(wǎng)站多幾個HTTP請求有何妨,多幾個樣式也不會有很大的性能變化，而像淘寶、新浪微博、騰訊QQ空間這些大項目就不同了，太多的CSS文件引入頁面會有較明顯的載入延遲，所以如何去盡量減少css文件的情況下做到盡可能的便于后期維護是重要的，如果有可能可以使用CDN；

參考之前的方法，可以為按功能或頁面區(qū)塊分成多個css文件,然后根據(jù)需要利用@import導(dǎo)入到一個文件中，然后再引入頁面中

（2）頁面實現(xiàn)的復(fù)雜度及需求變換程度

頁面的復(fù)雜程度基本上是如何組織CSS我覺得最重要的考慮因素了，風(fēng)格統(tǒng)一的網(wǎng)站header和footer不會變，我們可以做成一個模塊化方便調(diào)用、你可以把它寫在common.css里面全站都應(yīng)用，大家常用的reset也應(yīng)該寫在這里面，完全沒必要單獨寫一個reset.css文件，因為所有的全站都會用到；然后最重要的就是分析頁面的其他部分是不是有設(shè)計相同的部分，有的話抽離出來放到common里面，全站都可以調(diào)用，這個就是所謂的CSS組件化了

還有一個非常糾結(jié)的問題，我想做前端時最理想的是：設(shè)計師設(shè)計好所有的稿然后交給前端“一次性”全部轉(zhuǎn)換為Web頁面、多好啊！樣式等文件一開始就可以參照設(shè)計稿進行全方位的規(guī)劃組織，想怎么弄怎么弄，清晰明了；可現(xiàn)實就是那么骨干、尼瑪有時設(shè)計稿變化大到你想吐血，還是半路穿插進來的，你會發(fā)現(xiàn)什么頭部header和尾部footer又得重寫個新的了，之前的模塊話也都完全用不上了，而有時又只是一個頁面而已（比如專題頁），很不情愿為其模塊化， 糾結(jié)啊！，所以我常常在不破壞整站的整體風(fēng)格的情況下，會專門定義一個文件夾來存放這些蛋疼頁面的CSS樣式，我不想讓他們共用全站的CSS文件，這個文件里同樣有個common.css文件存放諸如css reset、base原子類供所有單獨頁面調(diào)用，然后每個頁面會有一個page.css或style.css專門定義頁面樣式的，而代碼冗余不冗余已經(jīng)不是重點了，管它去死，盡量寫得簡潔規(guī)范高效即可

原文鏈接：http://www.cnblogs.com/guosh/archive/2012/07/19/2599551.html