移动端优先开发中那些年我们踩过的坑和最佳实践

移动优先 vs 桌面优先，聊聊我的实战对比

最近重构一个响应式项目，又要重新思考移动端和桌面端的设计策略。说实话，做了这么多年前端，这个话题还是很有争议的。有些同学可能觉得这是老生常谈，但实际项目中遇到的问题远比理论复杂。

我比较倾向于移动优先，主要是现在移动端流量占比太大了，而且移动优先的设计思路能强制你思考核心功能，避免在桌面端堆砌一堆用不到的功能。不过这里主要还是想对比一下几种常见的实现方案，毕竟理论归理论，实际用起来差别还是挺大的。

媒体查询方案：传统但可靠

这个就不用多说了，大部分人的第一选择。核心思路就是从小屏开始设计，然后逐步放大到大屏幕。

/* 移动端优先 */
.container {
  width: 100%;
  padding: 10px;
}

/* 平板尺寸 */
@media (min-width: 768px) {
  .container {
    width: 750px;
    margin: 0 auto;
  }
}

/* 桌面尺寸 */
@media (min-width: 1024px) {
  .container {
    width: 1000px;
  }
}

/* 大屏尺寸 */
@media (min-width: 1200px) {
  .container {
    width: 1170px;
  }
}

这个方案最大的优点就是兼容性好，几乎所有浏览器都支持，而且逻辑清晰。但我踩过几次坑，就是有时候在某些设备上媒体查询会失效，特别是那些奇葩分辨率的平板。还有就是维护起来比较麻烦，样式分散在各个断点里，改起来容易遗漏。

Flexbox + rem/vw单位：现代但有坑

这个方案我比较喜欢用，特别是vw单位真的很好用。不过需要注意的是，vw单位在iOS Safari上有兼容性问题，需要加前缀。

.container {
  display: flex;
  flex-direction: column;
  width: 100%;
  max-width: 90vw; /* 这里用vw，宽度会自动适应 */
  margin: 0 auto;
  padding: 1rem; /* rem的好处是可以根据根字体大小调整 */
}

.item {
  flex: 1;
  min-height: 50px;
  margin-bottom: 1rem;
}

/* 大屏适配 */
@media (min-width: 768px) {
  .container {
    flex-direction: row;
    max-width: 80vw;
    padding: 2rem;
  }
  
  .item {
    flex: 1;
    min-width: 200px;
    margin-right: 1rem;
    margin-bottom: 0;
  }
}

这里要注意一个坑，rem单位在不同设备上的表现可能会有差异，特别是Android原生浏览器。而且如果你的设计师要求像素级精确，那rem可能不太适合，因为计算出来的值可能不是整数。

CSS Grid + Container Queries：新玩意儿

Container Queries是最近才普及的新特性，确实解决了不少问题。不过浏览器支持情况还需要考虑，特别是IE用户比较多的项目就得谨慎了。

.card-container {
  container-type: inline-size;
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
  gap: 1rem;
  padding: 1rem;
}

@container (min-width: 600px) {
  .card {
    font-size: 1.1rem;
    padding: 1.5rem;
  }
}

@container (min-width: 800px) {
  .card-container {
    grid-template-columns: repeat(3, 1fr);
  }
}

这个方案的优点很明显，组件级别的响应式，不用关心外部容器。但缺点也很明显，兼容性是个大问题，现在还是得配合JavaScript做降级处理。

// 降级处理
if (!window.CSS.supports('container-type', 'inline-size')) {
  // fallback to traditional media queries
  document.body.classList.add('no-container-queries');
}

谁更灵活？谁更省事？

从灵活性来说，当然是CSS Grid + Container Queries最灵活，但实际项目中用得最多的还是传统媒体查询。主要原因就是兼容性和团队协作的考虑。

对于小项目，我会选择Flexbox + rem方案，因为开发速度快，调试也方便。对于大项目，特别是需要支持老版本浏览器的，还是媒体查询最稳妥。

我之前在一个电商项目中试过Container Queries，结果发现部分Android机型显示异常，最后还是换回了传统的媒体查询。所以新技术虽然好，但还是要考虑实际的用户群体。

我的选型逻辑

现在的项目，我基本都是混合使用的：

• 对于核心业务模块，用媒体查询保证兼容性
• 对于展示类组件，能用Grid就用Grid
• 字体大小统一用rem，方便后期整体调整
• 间距用em或rem，保持相对比例

特别要说一下的是，现在手机屏幕尺寸越来越多样化，单纯的几个断点已经不够用了。我现在一般会设置更多的中间断点，比如375px、414px、768px、1024px这些常见尺寸。

还有就是性能问题，大量的媒体查询其实会影响渲染性能，特别是在低端Android机上。所以建议把常用的样式放在基础样式里，只把差异化很大的部分用媒体查询来处理。

踩坑提醒：这三点一定注意

第一个坑是视口单位的计算，在iPhone的刘海屏下会有问题。解决方法是在viewport meta标签里加个特性：

<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">

第二个坑是字体模糊问题，特别是在高DPR屏幕上。CSS中需要添加：

body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

第三个坑是滚动穿透，移动端经常会遇到模态框后面的页面还能滚动的问题。这个问题现在有成熟的库可以解决，但原理其实就是动态修改overflow属性。

性能对比：差距比我想象的小

为了测试不同方案的性能差异，我在几个不同配置的设备上做了测试。结果显示，除了在非常老旧的Android机上，各种方案的性能差异并不明显。主要瓶颈还是在JavaScript执行和DOM操作上，CSS本身的影响相对较小。

不过有一点需要注意，如果使用了大量的calc()函数和复杂的Grid布局，确实会在低端机上造成一定的性能问题。所以我现在会把一些复杂的计算逻辑移到JavaScript里预计算，然后通过CSS变量传入。

.grid-container {
  --col-count: 2;
  display: grid;
  grid-template-columns: repeat(var(--col-count), 1fr);
  gap: var(--gap, 1rem);
}

以上是我个人对这个移动优先方案的完整讲解，有更优的实现方式欢迎评论区交流。这个技巧的拓展用法还有很多，后续会继续分享这类博客。这个是我踩坑后的总结，希望对你有帮助。