互聯網上有許多通用的方案，這里我著重提三點：

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 ，這樣就極容易造成了樣式沖突?；蛟S您提出不同意見：我們強制讓所有的樣式前面都加一個關于其模塊名的限定，把模塊二中的.listitem改成 .module2 .listitem，不就ok了？但這樣并不好，因為在實際應用中，不能要求所有的樣式寫法一定要加上模塊限定，比如在body節點下的某個浮動節點，我們就不能這樣處理。同時，針對第一種寫法，我們還可以很輕松開發出一個CSS的檢測軟件，用來檢測語法，判斷覆蓋。（我們知道判斷出.a .b, .a>b,.b的覆蓋關系遠比.a-b復雜的多）

更多信息請查看IT技術專欄