移动优先的设计方法很棒——它专注于对用户真正重要的东西，它被很好地实践，并且多年来一直是一种常见的设计模式。所以开发你的 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”。

.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 规则的创建最终是一种比绕着覆盖循环更干净的方法。但无论您选择哪种方法，它都需要适合项目。移动优先可能会（也可能不会）成为所涉及内容的最佳选择，但首先您需要充分了解您要进行的权衡取舍。