移動優先的設計方法很棒——它專注于對用戶真正重要的東西，它被很好地實踐，并且多年來一直是一種常見的設計模式。所以開發你的 CSS 移動優先也應該很棒……對吧？

嗯，不一定。經典的移動優先 CSS 開發基于覆蓋樣式聲明的原則：您從默認樣式聲明開始您的 CSS，并在min-width為更大的視口添加斷點時覆蓋和/或添加新樣式（有關詳細概述，請參閱“什么是移動優先 CSS 以及它為何如此受歡迎？ ”）。但是所有這些異常都會造成復雜性和低效率，這反過來又會導致測試工作量增加和代碼庫更難維護。承認吧——我們當中有多少人愿意這樣做？

在您自己的項目中，移動優先的 CSS 可能仍然是這項工作的最佳工具，但首先您需要根據您正在處理的視覺設計和用戶交互來評估它的適用性。為了幫助您入門，以下是我解決您需要注意的因素的方法，如果移動優先似乎不適合您的項目，我將討論一些替代解決方案。

移動優先的優勢

移動優先 CSS 開發的一些優點——以及為什么它長期以來一直是事實上的開發方法——很有意義：

發展層次。毫無疑問，您從移動優先中獲得的一件事是一個很好的開發層次結構——您只需專注于移動視圖并開始開發。

嘗試和測試。這是一種久經考驗的方法，多年來一直有效：它很好地解決了問題。

優先考慮移動視圖。移動視圖是 最簡單 的，也可以說是最重要的，因為它包含所有關鍵的用戶旅程，并且通常占用戶訪問的更高比例（取決于項目）。

防止以桌面為中心的開發。由于開發是使用臺式計算機完成的，因此最初專注于桌面視圖可能很誘人。但是從一開始就考慮移動設備可以防止我們以后陷入困境；沒有人愿意花時間改造以桌面為中心的網站以在移動設備上工作！

移動優先的缺點

設置樣式聲明然后在更高的斷點處覆蓋它們可能會導致不良后果：

更復雜。你去的斷點層次越遠，你從較低的斷點繼承的不必要的代碼就越多。

更高的 CSS 特異性。在類名聲明中已恢復為其瀏覽器默認值的樣式現在具有更高的特異性。當您想讓 CSS 選擇器盡可能簡單時，這對于大型項目來說可能是一件令人頭疼的事情。

需要更多的回歸測試。在較低視圖中對 CSS 的更改（例如添加新樣式）需要對所有較高的斷點進行回歸測試。

瀏覽器無法優先考慮 CSS 下載。在更廣泛的斷點處，經典的移動優先min-width媒體查詢不會利用瀏覽器按優先級順序下載 CSS 文件的能力。

屬性值覆蓋問題

覆蓋值本身并沒有錯。CSS 就是為此而設計的。盡管如此，繼承不正確的值是沒有幫助的，并且可能是繁重且效率低下的。當您必須覆蓋樣式以將其重置為默認值時，它還可能導致樣式特異性增加，這可能會在以后引起問題，尤其是在您使用定制 CSS 和實用程序類的組合時。我們將無法將實用程序類用于已以更高特異性重置的樣式。

考慮到這一點，我現在開發的 CSS 更多地關注默認值。由于沒有特定的順序，也沒有要跟蹤的特定值鏈，這讓我可以同時開發斷點。我專注于在封閉的媒體查詢范圍（即具有max-width集合的任何范圍）中尋找常見樣式并隔離特定異常。

這種方法開辟了一些機會，因為您可以將每個斷點視為一張白紙。如果一個組件的布局看起來應該在所有斷點處都基于 Flexbox，那很好，可以在默認樣式表中編碼。但是，如果 Grid 看起來更適合大屏幕，而 Flexbox 更適合移動設備，那么當 CSS 放入封閉的媒體查詢范圍時，這些都可以完全獨立完成。此外，同時開發要求您預先對所有斷點中的任何給定組件都有很好的理解。這有助于在開發過程的早期發現設計中的問題。我們不想陷入為移動設備構建復雜組件的兔子洞，然后在獲得桌面設計時發現它們同樣復雜且與我們為移動視圖創建的 HTML 不兼容！

盡管這種方法并不適合所有人，但我鼓勵您嘗試一下。有很多工具可以幫助并發開發，例如Responsively App、Blisk等等。

話雖如此，我覺得訂單本身并不是特別相關。如果你習慣于專注于移動端視圖，對其他斷點的需求有很好的理解，并且更喜歡一次在一臺設備上工作，那么一定要堅持經典的開發順序。重要的是識別常見的樣式和異常，以便您可以將它們放入相關的樣式表中——一種手動搖樹的過程！就個人而言，我發現在跨斷點處理組件時這會更容易一些，但這絕不是必需的。

實踐中的封閉媒體查詢范圍

在經典的移動優先 CSS 中，我們會覆蓋樣式，但我們可以通過使用媒體查詢范圍來避免這種情況。為了說明區別（為了簡潔起見，我使用 SCSS），讓我們假設有三種視覺設計：

• 小于 768
• 從 768 到 1024 以下
• 1024及更大的

舉個簡單的例子，塊級元素的默認padding值為“20px”，在平板電腦上被覆蓋為“40px”，在桌面上設置回“20px”。

經典min-width移動優先：

.my-block {
  padding: 20px;
  @media (min-width: 768px) {
    padding: 40px;
  }
  @media (min-width: 1024px) {
    padding: 20px;
  }
}

封閉媒體查詢范圍：

.my-block {
  padding: 20px;
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

細微的區別在于，移動優先的示例將默認設置padding為“20px”，然后在每個斷點處覆蓋它，總共設置了 3
次。相比之下，第二個示例將默認值設置padding為“20px”，并且僅在它不是默認值的相關斷點處覆蓋它(在這種情況下，tablet 是例外)。

目標是：

• 僅在需要時設置樣式。
• 不要讓他們期望以后一次又一次地覆蓋它們。

為此，封閉的媒體查詢范圍是我們最好的朋友。如果我們需要對任何給定視圖進行更改，我們會在適用于特定斷點的 CSS 媒體查詢范圍內進行更改。我們將不太可能引入不需要的更改，并且我們的回歸測試只需要關注我們實際編輯的斷點。

以上面的例子為例，如果我們發現.my-block桌面上的間距已經被該斷點處的邊距考慮了，并且由于我們想要完全刪除填充，我們可以通過將移動設備設置padding在封閉的媒體查詢范圍內來做到這一點。

.my-block {
  @media (max-width: 767.98px) {
    padding: 20px;
  }
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

我們塊的瀏覽器默認值為“0”，因此我們可以將移動設備包裝在封閉的媒體查詢中padding，而不是添加桌面媒體查詢并使用unset或“0”作為值（移動優先）因為它現在也是一個例外）所以它不會在更寬的斷點處被拾取。在桌面斷點處，我們不需要設置任何樣式，因為我們需要瀏覽器默認值。paddingpaddingpadding

捆綁與分離 CSS

過去，由于瀏覽器的并發請求數限制（通常約為 6 個），將請求數保持在最低限度非常重要。因此，圖像精靈和 CSS 捆綁的使用成為常態，所有 CSS 一次性下載，作為具有最高優先級的一個樣式表。

隨著 HTTP/2 和 HTTP/3 的出現，請求的數量不再是過去的大問題。這允許我們通過媒體查詢將 CSS 分成多個文件。這樣做的明顯好處是瀏覽器現在可以請求它當前需要的 CSS，其優先級高于它不需要的 CSS。這更高效并且可以減少頁面呈現被阻塞的整體時間。

您使用的是哪個 HTTP 版本？

要確定您使用的 HTTP 版本，請訪問您的網站并打開瀏覽器的開發工具。接下來，選擇網絡選項卡并確保協議列可見。如果“h2”列在Protocol下，則表示正在使用 HTTP/2。

注意：要在瀏覽器的開發工具中查看協議，請轉到網絡選項卡，重新加載頁面，右鍵單擊任何列標題（例如，名稱），然后檢查協議列。

此外，如果您的網站仍在使用 HTTP/1...為什么？！！你在等什么？對 HTTP/2有很好的用戶支持。

拆分 CSS

將 CSS 分成單獨的文件是一項有價值的任務。使用相關屬性鏈接單獨的 CSS 文件media允許瀏覽器立即識別哪些文件是需要的（因為它們是渲染阻塞的），哪些可以延遲。基于此，它為每個文件分配適當的優先級。

在以下在移動斷點上訪問的網站示例中，我們可以看到移動和默認 CSS 以“最高”優先級加載，因為當前需要它們來呈現頁面。其余的 CSS 文件（打印、平板電腦和桌面）仍會下載以備日后需要，但優先級為“最低”。

使用捆綁的 CSS，瀏覽器必須先下載 CSS 文件并對其進行解析，然后才能開始渲染。

雖然，如前所述，將CSS 分成不同的文件，鏈接并用相關media屬性標記，瀏覽器可以優先考慮它當前需要的文件。使用封閉的媒體查詢范圍允許瀏覽器在所有寬度上執行此操作，而不是經典的移動優先min-width查詢，其中桌面瀏覽器必須以最高優先級下載所有 CSS。我們不能假設桌面用戶總是有一個快速的連接。例如，在許多農村地區，互聯網連接速度仍然很慢。

媒體查詢和單獨的 CSS 文件的數量將根據項目要求因項目而異，但可能類似于下面的示例。

根據項目的部署策略，對一個文件（mobile.css例如 ）的更改只需要 QA 團隊在該特定媒體查詢范圍內的設備上進行回歸測試。將其與部署單個捆綁site.css文件的前景進行比較，這種方法通常會觸發完整的回歸測試。

繼續

移動優先 CSS 的采用是 Web 開發中一個非常重要的里程碑。它幫助前端開發人員專注于移動 Web 應用程序，而不是在桌面上開發網站，然后嘗試對其進行改造以在其他設備上工作。

我認為沒有人想再次回到那種開發模式，但重要的是我們不要忽視它所強調的問題：如果我們優先考慮一種特定設備（任何設備），事情很容易變得復雜且效率低下。其他。出于這個原因，專注于 CSS 本身，始終注意什么是默認設置和什么是異常，似乎是很自然的下一步。我已經開始注意到我自己的 CSS 以及其他開發人員的 CSS 進行了一些小的簡化，并且測試和維護工作也更加簡化和高效。

一般來說，盡可能地簡化 CSS 規則的創建最終是一種比繞著覆蓋循環更干凈的方法。但無論您選擇哪種方法，它都需要適合項目。移動優先可能會（也可能不會）成為所涉及內容的最佳選擇，但首先您需要充分了解您要進行的權衡取舍。