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

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

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

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

多個CSS文件可以利用@import導入的頁面中，好處是減少HTTP請求數，壞處是導入樣式要比鏈接樣式的速度慢，而且導入的文件有順序的規定，順序不當常常會出現樣式沒辦法應用等錯誤，也是讓人無比糾結。

而對于全部寫在單個文件的，其內部最好有合理的設計結構和注釋：

（1）一般性樣式：

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

（2）輔助樣式

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

（3）頁面結構

標題、頁腳和導航；布局；其他頁面結構元素

（4）頁面組件

各個頁面

（5）覆蓋

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

/* @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文件里面的內容，所以疑問就來了：

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

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

（2）調用盡可能少的CSS文件

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

（3）多人合作上的疑問

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

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

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

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

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

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

（1）首先當然要看項目的規模和訪問量

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

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

（2）頁面實現的復雜度及需求變換程度

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

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

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