CSS預處理語言的模塊化實踐實例

編寫css是前端工作中，一項普通而又頻繁的勞動，由於css並不是一門語言，所以在程序設計上顯得有些簡陋。對於小型項目來説，css的量還不至於龐大，問題沒有凸顯，而如果要開發和持續維護一個較為大型的項目，那就需要對css進行管理和規範了，否則會發生不可挽回的後果。

通過規範的約束，將css的編寫方式進行了優化和改進，形成一種可持續發展的路線。但還是遺留了一些問題：宂餘。雖然我們通過定義公共模塊和私有模塊，來委婉地分擔common的體積，但common的體積還是太大了，而且從設計上考慮，我們應該儘量多地提煉公共模塊，以便更好地實現複用。最理想的情況是，所有的模塊都寄存在一個公共的庫裏，哪裏需要用到就從庫中直接調過來。這個美好的願望不是不可實現的，藉助預處理語言，我們可以很輕易地完成這事情。

預處理語言是一種類css的語言，我們知道css本身不是語言，而預處理語言的誕生，就是為填補這一部分語言功能。它實現了變量、函數、混合的定義，以及文件的引用、合併、壓縮功能，使得css也能面向對象，應付複雜龐大的業務。

目前流行的預處理語言主要有兩種：less和sass。作為學習，兩者都可以入門一下，而作為工作，儘量熟悉一種。我比較常用sass，所以以下內容都是以sass為基本語言做介紹，兩者在特性上有很多相似的地方，所以大家不必擔心實現上有什麼千差萬別。

　　sass

基本語法可以到官方網（英語）或者w3cplus sass guide（中文）查看學習，我們這裏只簡單地過一遍，講一些我們需要用到的內容，不會面面俱到。

sass有兩種後綴名文件：一種後綴名為sass，不使用大括號和分號；另一種就是我們這裏使用的scss文件，這種和我們平時寫的css文件格式差不多，使用大括號和分號。而本教程中所説的所有sass文件都指後綴名為scss的文件。在此也建議使用後綴名為scss的文件，以避免sass後綴名的嚴格格式要求報錯。 ——摘自w3cplus sass guide

1、嵌套（非常重要的特性）

sass的嵌套包括兩種：一種是選擇器的嵌套；另一種是屬性的嵌套。我們一般説起或用到的都是選擇器的嵌套。 ——摘自w3cplus sass guide

選擇器嵌套 所謂選擇器嵌套指的是在一個選擇器中嵌套另一個選擇器來實現繼承，從而增強了sass文件的結構性和可讀性。在選擇器嵌套中，可以使用&表示父元素選擇器。 ——摘自w3cplus sass guide

//

.g-index {

...

.g-hd {

...

.m-nav { ... }

}

.g-bd {

...

.m-news { ... }

}

.g-ft {

...

.m-copy_right { ... }

}

.m-dialog {

display: none;

&.z-active { // 留意此處&的用法

display: block;

}

}

}

編譯後：

/* */

.g-index { ... }

.g-index .g-hd { ... }

.g-index .g-hd .m-nav { ... }

.g-index .g-bd { ... }

.g-index .g-bd .m-news { ... }

.g-index .g-ft { ... }

.g-index .g-ft .m-copy_right { ... }

.g-index .m-dialog {

display: none;

}

.g-index .m-dialog.z-active { // 留意此處&的編譯結果

display: block;

}

是不是爽歪歪？再也不用一遍一遍地去複製和修改一大堆的選擇器，也不需要去整理它們之間的關係，只需要嵌套一下，所有的關係就如同直接看dom一樣簡單明瞭了！解放雙手，解放雙眼，同時還提高效率。值得留意的是，我們書寫sass的時候，應該儘量保持sass的嵌套順序與dom一致，注意，是嵌套順序一致，而不是層次一致，因為並不是dom裏的所有元素都需要寫樣式。

我們再來提一個場景，説明sass的嵌套寫法利於維護，假設g-bd下原本有個模塊m-article_box，現在我們要把m-article_box從g-bd遷移到g-hd中（當然這個需求有些不合理～），我們來看原始代碼：

titleindex/title

最新文章

文章標題

文章簡介

1

2

3

4

.g-bd { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box r { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box e { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

.g-bd .m-article_box { ... }

按照css的方式，我們就要把所有跟m-article_box有關的部分，從g-bd全部複製到g-hd裏去。這還是在模塊的書寫符合規範的情況下，如果這個模塊書寫不符合規範，沒有把全部結構都掛在m-article_box類下，那真的就是災難了～而現在使用sass的話，我們只需要把m-article_box的區塊整個從g-bd剪切到g-hd就完事了（這裏為了突出修改的工作量大，我特地把整個模塊結構都寫全了——才不是為了湊字數。。。）：

// 修改前

.g-hd { ... }

.g-bd {

.m-article_box {

{ ... }

{

{

{

r {

...

}

{

e {

...

}

{

...

}

}

}

}

}

{

{

{ ... }

}

}

}

}

// 修改後

.g-hd {

.m-article_box {

{ ... }

{

{

{

r {

...

}

{

e {

...

}

{

...

}

}

}

}

}

{

{

{ ... }

}

}

}

}

.g-bd { ... }

非常方便，而且不容易出錯。

2、變量（variable）

咱們直接上代碼：

//

$fontSize: 16px;

$grey: #ccc;

.m-nav {

font-size: $fontSize;

color: $grey;

}

編譯結果：

/* */

.m-nav {

font-size: 16px;

color: #ccc;

}

寫過代碼的人都熟悉 參數 的用法吧，太簡單太直白了不想説太多，自己意會吧。

3、函數（function）

// pixels to rems

@function rem($px) {

@return $px / 640 * 16rem;

}

太簡單了直白了不想説太多，自己意會吧。

4、混合（mixin）

混合，顧名思義，就是混合的意思。。。也就是我們可以事先定義一段代碼塊，在需要使用到的地方，直接引用（include），而在引用之前，這段代碼都不會出現在編譯文件中，也就是不會生成任何內容。

這也是非常重要的一個特性！我們知道common的體積非常大，而體積大的根本原因是它存放了許許多多的模塊。我們設想一下，如果將每一個模塊都打包成mixin，那common不就減肥成功了？！多年的頑疾終於看到希望，沒有比這更讓人驚喜的了！我們這就上車：

/* */

.m-nav { ... }

.m-news { ... }

.m-copy_right { ... }

改造後

//

@mixin m-nav {

.m-nav { ... }

}

@mixin m-news {

.m-news { ... }

}

@mixin m-copy_right {

.m-copy_right { ... }

}

//

.g-index {

@include m-nav;

@include m-news;

@include m-copy_right;

}

5、import

這個屬性很眼熟？沒錯，事實上，css本身就有這個屬性實現，我們可以在css文件中直接使用import來引入其他文件。那麼css的import和sass的import有什麼區別？從含義和用法上來説，沒有區別，區別在於工作原理。css的import是阻塞的，而sass的import在編譯後，其實是合併文件，最後只產出一個css文件，而css則沒有合併，該多少個文件就還是多少個文件。

注意：

只有import一個文件的時候，才可以省去後綴名，如果是直接import一個文件，要補全文件名；

import之後的分號;不要漏寫，會報錯；

sass如果import的是一個文件的話，那它的作用就跟css原生的import作用一樣，只有import一個sass文件的時候，才是合併文件。

如下：

//

@import 'common';

@import '';

編譯結果：

/* */

.m-nav { ... }

.m-news { ... }

.m-copy_right { ... }

@import url('');

css的import之所以沒有被普遍使用是有原因的。我們可以大概猜到它的工作原理： import 以後，當瀏覽器加載到頁面中的的時候，已經準備按照的內容來渲染頁面了，剛解析到第一行，發現居然還import了一個，於是它不得不先放下（既阻塞），去加載，直到加載完，並且優先解析它，然後才開始回來解析——鬼知道會不會又import了……這直接導致了渲染工作滯後，引發性能問題。

説實話我還不如直接用兩個link標籤去同步加載和，效率會高一些。

所以css的import基本是被拋棄了的屬性。

sass的import主要的好處就是把文件合併了，減少了請求。原本需要link好幾個css文件的頁面，現在只需要一個。

　　模塊化

終於要開始乾點正事了，首先我們來回顧一下，上一節我們以規範為基礎構建的`模塊化項目，遺留了一些什麼問題。

宂餘 體積龐大的common；

使用cm-模塊區別m-模塊，使得後期開發過程中，m-模塊向cm-模塊轉變過程比較繁瑣；

……

好像，問題也不是特別多，我們一個一個解決。

為了方便，在這裏我們把每個頁面所對應的scss文件叫做 頁面scss；把變量、函數、混合等（沒有被引用或者執行的情況下）編譯後不產生實際內容的代碼叫做 定義類代碼 ，那麼相對應的其他內容就是 實際內容代碼。

1、

我們知道，一方面，在common中過多地添加模塊最終會導致common的體積過大，使得資源宂餘，另一方面，為了方便維護，我們又希望儘量多地把模塊公有化。

這是一對矛盾，僅靠css本身是無法解決的，但sass可以！如果我們使用mixin來代替直接書寫模塊，由於mixin並不直接生成代碼，而是通過主動引用，才能生成對應內容，那麼理論上，common就可以無限多地存放模塊而不必佔用一點空間！

（注意，這裏説的是理論上，實際應用中，文件太過龐大的話，免不了還是要受到命名衝突的限制的，不過這問題不大。）

説幹就幹，我們把common中的模塊全部打包成mixin：

/* */

.m-nav { ... }

.m-news { ... }

.m-copy_right { ... }

改造後

//

@mixin m-nav {

.m-nav { ... }

}

@mixin m-news {

.m-news { ... }

}

@mixin m-copy_right {

.m-copy_right { ... }

}

調用方式如下：

//

@import 'common'; // 記得先引入common

.g-index {

@include m-nav;

@include m-news;

@include m-copy_right;

}

原本我們會在每個需要用到公共模塊的頁面中，先引用common，然後再引用頁面css，而現在，我們只需要在頁面scss中直接@import common;就可以了。

使用common：

titleindex/title

link rel="stylesheet" type="text/css" href="./style/"/

link rel="stylesheet" type="text/css" href="./style/"/

...

改造後：

//

@import 'common';

titleindex/title

link rel="stylesheet" type="text/css" href="./style/"/

...

很完美，

——至少目前為止是這樣。

我們思考一個問題，common除了存放模塊之外，還有沒有其他內容？答案是肯定的，大家一定知道有個東西叫做css reset（或者），這肯定是全局的；另外，如果是做後台管理系統的話，可能還會有bootstrap。當然，還有一些自定義的全局的樣式，比如常見的rfix，等等。

這些東西目前我們也堆積在common當中，而且合情合理，因為它們都是全局的樣式。但是對比起mixin來説，這些實際內容代碼顯得很少量，有種被淹沒的感覺，使得整個common看上去就像只有mixin。但是這些實際內容代碼的作用卻又非常重要。為了使common的構成更加直觀，我們把mixin全部都抽離出來，單獨存放一個叫做的文件中，然後在common引用它，這樣，mixin的管理更加的規範，而且common的結構也更加清晰了。

抽離mixin還有另外一個重要原因，後面會講到的，我們希望mixin作為一個純粹定義類代碼文件，隨處可以引用而不會生成多餘的代碼。

原本我們會在每個需要用到公共模塊的頁面中，先引用common，然後再引用頁面css，而現在，我們只需要在頁面scss中直接@import mixin;就可以了。

使用mixin：

//

@import 'common'; // 引入common，如果有需要，common裏一樣可以引入mixin

@import 'mixin'; // 引入mixin

.g-index {

...

}

titleindex/title

link rel="stylesheet" type="text/css" href="./style/"/

...

2、

好，抽離了mixin之後，我們現在來重新看回common，common裏應該是些什麼樣的內容。上面的內容我們稍稍提到了一點，我們來展開一下。

2.1、css reset(normalize)

我們知道瀏覽器千差萬別，各瀏覽器的默認樣式也是不盡相同，最常見的比如body的默認內邊距，p標籤的默認內邊距，以及ul/ol等等。這些不統一的默認樣式經常讓我們感到頭疼，所以就有人提出一開始寫樣式就先把它們消除的想法，於是就催生了後來非常流行的。

起初的很簡單，大概是這樣的：

html, body, h1, h2, h3, h4, h5, h6, p, dl, dt, dd, ul, ol, li, p {

margin: 0;

padding: 0;

}

沒錯，就是把幾乎所有會用到的標籤都給去了內邊距和外邊距，簡單粗暴，這樣所有的標籤就都統一了，而且在不同的瀏覽器下也是統一的。

其他的部分每個人有各自的補充，比如有人會把h1～h6的所有字號給定義一遍，以保證在不同瀏覽器下他們有統一的大小；有人會給a標籤設置統一的字體顏色和hover效果，諸如此類等等。

很好，沒毛病。我們把這些統稱為css reset，然後再統一封裝到一個叫做的文件中，然後每個頁面都引用。

這種方式一直以來都挺實用，而且大家也都這麼用，沒出過什麼問題。只是後來有人提出，這種方式太過粗暴（居然還心疼瀏覽器了）。。。而且會降低頁面渲染的性能，最重要的是，這使得我們原本設計出來的表達各種含義的標籤兒們，變得毫無特點了。。。

説的好有道理，如果你家裏所有人名字不一樣但是都長一個樣，還有啥意思。

於是，就出現了，normalize的目的同樣是為了統一各個瀏覽器下各不相同的默認樣式，不過它並不是簡單粗暴地全部抹平，而是根據規範，來人為地把那些不符合規範的默認樣式“扶正”，從而達到統一各個瀏覽器默認樣式，同時保留各個標籤原有特點的目的。

我們不能説reset與normalize這兩種思想孰好孰壞，只能説各有各的特點和作用，它們的存在都是為了解決同樣的問題。

2.2、插件

一般來説，一個ui插件都會至少包括一個css文件，像bootstrap、datepicker等等。假設我們項目中需要以bootstrap為基礎框架，實現快速開發，那麼這時候我們就需要在項目中全局引入，當然，還有。説到全局暴露，我們第一時間想到的是common，沒錯，我們可以在common中引入。

有人問，插件的文件怎麼import？額，改一下擴展名為就可以了，scss是兼容原生css語法的～

所以最終，我們的common大概是這樣子的：

//

@import './reset';

@import './';

@import './mixin';

事實上，如果我們不需要使用到 中的變量和mixin的話，我們可以不引用它。

那麼我們的頁面scss應該是這樣的：

//

@import './common';

@import './mixin';

.g-index {

...

}

乾淨，整潔。

3、mixin編寫規範

每添加一個新角色，我們就要及時給它設置規範，好讓它按照我們的期望工作別添亂。我們接下來來歸納一下mixin的書寫規範。

場景一：項目裏有、（假設這是某個功能文件）、三個文件，mixin中定義了一個變量$fontSize: 16px;，a中定義了一個變量$color: #ccc;，我們在index中同時引用這兩個文件，那麼我們在index中是可以直接使用$fontSize和$color這兩個變量的——我的意思是，儘管在index中我們並沒有看到這兩個變量的聲明和定義，但它們就這麼存在了。

這是好事還是壞事呢？直覺告訴我，這可能有問題。沒錯，這是不是跟我們之前討論過的 污染 很像？只不過我們之前是引用了common之後，index什麼都還沒寫就已經被佔用了很多模塊名，而現在是因為引用了其他文件，而佔用了index的很多變量名。另外，就維護的角度來看，這也是有問題的，如果我不事先告訴你，或者你不事先看過一遍mixin和a，你知道index中的$color是哪裏來的嗎？假設我們需要字體大小，你知道去哪個文件修改嗎？另外，你怎麼保證同時引用mixin與a的時候，他們之間有沒有可能存在同名的變量？那誰覆蓋誰呢？這些問題看起來很小，但是當你項目規模大的時候，這可能是無法挽回的災難（嚇唬誰呢？？？）。

場景二：假設我們的項目有一個主題色，邊框、tab背景、導航欄背景，以及字體顏色等等，都是這個主題色，為了方便使用，不想總是用取色器去取值，於是我們在mixin中定義了一個全局變量$color: #ff9900，然後就可以愉快地到處使用了！

整個網站開發完了，一個月後，設計師突然過來跟你説：“老闆説，這個主題色要改改，有點土，咱們換個大紅。”，於是你一臉不情願然而內心卻竊喜地打開mixin，把$color的值改成了大紅，然後得瑟地對設計師説：“幸好我早有準備，搞定了，你看看吧。”，保存，打開頁面一看，設計師和你的臉都綠了，頁面怎麼這麼醜，有些字原本是主題色，但背景是紅色，而現在一改，整塊都變成紅的，內容都看不清了，有些邊框原本就是紅色的，但是字體是原本的主題色，然而現在一改，邊框跟字體都變成紅的了。

設計師：“不不不，我只是想把背景顏色改一下。”

你：“你不是説改主題色嗎？那就是所有的地方啊。”

設計師：“不用，改背景就好了。”

你：“不行啊。。。”

設計師：“為什麼不行，不就是改個背景顏色嗎？怎麼設置的就怎麼改回來呀。”

你：“不是你想的那麼簡單。。。”

……

好吧我就是嚇唬你的，你要是特能折騰那麼這些都不叫事兒。

所以我們需要對（全局）變量進行管理，就像我們當初管理mixin那樣，不能想在哪裏定義就在哪裏定義，也不能動不動就修改一個全局變量：

全局變量只在mixin中定義，其他scss文件定義的變量（無論是暴露到全局還是局部）都只看作局部變量，不在當前文件以外的地方使用（即便是在能引用到的情況下，也避免使用）；

需要使用全局變量的地方直接import mixin；

一般來説，定義全局變量應該慎重，全局變量的數量應該儘量少；

儘可能不改動，如果需求變動，除非是對用途十分確定的情況，否則請新增一個全局變量來逐步替換需要修改的地方；

不要使用太過籠統的名詞來作為全局變量，比如color，建議直接是用色值的描述，比如$orange: #ff9900，這使得我們在維護上更方便擴展，如果色值需要修改，但是又不是所有的地方都需要修改，那麼我們可以新定義一個變量來擴展它，比如$red： red。

這些點説起來都有點飄忽，事實上也確實很難説明白為什麼要這麼做，畢竟都是經驗總結，所以大家不妨先熟悉使用sass一段時間之後，再來細細思考這些問題。

注意，以上講的這些都不是死規定，在某些時候，這個規範是需要根據實際項目而做調整的，就比如我們之後要講到的SPA。十全十美的項目是不存在的，也不存在能適用所有項目的開發模式，因地制宜才能更好地解決問題。而且我們目前提到的問題都不是致命的，致命的問題在上一節我們制定規範的時候已經避開了。

調用模塊

問題，在哪裏調用模塊？

答，頁面scss。

在頁面scss中調用模塊是一個好習慣，它使得我們在每個頁面所用到的模塊既是一致的又是互相隔離的，不像在common中直接引用模塊那樣，使得一個頁面scss還沒有內容的時候就已經被很多模塊名污染了。

再提個問題，在頁面scss的哪裏調用模塊？

例一，根類外：

//

@import './common';

@import './mixin';

@include m-nav;

@include m-news;

@include m-copy_right;

.g-index {

...

}

例二，根類內：

//

@import './common';

@import './mixin';

.g-index {

@include m-nav;

@include m-news;

@include m-copy_right;

...

}

目前為止，這兩種方式都是可以的，至於我為什麼用“目前為止”這個詞，那是因為我們後面將要講到的SPA，如果用例一的方式是有問題的。所以我比較鼓勵使用例二的方式。當然，我説了，目前為止例一也是沒問題的。

性能優化

目前為止，我們的模塊化工作已經算是完成了，其實已經可以收工了。不過我們還是可以稍微做一下優化。

1、緩存

我們需要考慮一個問題：緩存。

緩存是我們web開發中最常見的情況之一，很多時候我們都需要跟緩存打交道，特別是在做性能優化的時候。

一般來説，靜態資源在被加載到瀏覽器之後，瀏覽器會把它本地緩存下來，以便下次請求同個資源的時候可以快速響應，不需要再去遠程服務器加載。

我們就css來説，假設我們按照原來的方式，使用多個link去加載reset、bootstrap、common、index這幾個文件的話，這幾個文件都會被緩存下來，以使得下次再訪問這個頁面，這個頁面的加載速度會快很多。

如果是從index頁面跳轉到about頁面呢？你會發現也很快，因為about頁面的全局css（reset、bootstrap、common）和index頁面是一樣的，而它們在你訪問index的時候，已經加載過了，得益於緩存的作用，之後的頁面打開都快。

我們現在的方式是，一個頁面所用到的所有css文件都被合併成一個，也就不存在相同的文件可以利用緩存這樣的優勢了。

那我們有辦法改進嗎？有的！我們只需要把common獨立出來，那麼common就可以做為被緩存的公共文件了。最終我們從一個頁面只引用一個文件變成了一個頁面引用兩個文件，即common和頁面css：

//

@import './reset';

@import './';

@import './mixin';

//

@import './mixin';

.g-index {

...

}

注意，不同於之前，我們這裏的不再引入，所以我們最終是得到了兩個css文件，而是在所有頁面中通過link標籤引入的。

如此一來，我們就實現了既能夠合併文件，減少請求數，又可以利用緩存，提高加載速度。

2、壓縮

代碼壓縮是優化工作中最基本的一步，css的壓縮空間是很大的，尤其是我們這種 垂直的書寫方式 ，壓縮起來是相當高效的。

在sass中這很簡單，sass在編譯的時候提供了幾種模式，其中的compressed模式是最高效的壓縮模式，記得在編譯打包的時候選擇compressed模式就行了。

總結

總的來説，預處理語言在使我們編程更加美好的同時，也使得規範更加的完善。在css本身無法實現的情況下，我們通過工具來完成了模塊化開發。