掌握媒体查询的实用技巧与响应式设计精髓

令狐令敏发布于 2026-03-17 03:20:55 移动阅读 535

原创

本文链接：https://www.jztheme.com/blog/app/35974.html

令狐令敏

赞 27 收藏反馈

优化前：卡得不行

项目上线前做了一轮性能压测，结果把我吓一跳。页面在中低端安卓机上滑动直接掉帧，首页首屏加载完之后还卡顿了差不多两秒，用户反馈“点不动”“页面发烫”。我自己拿台红米K30试了下，手指一滑，页面像拖着铁球跑步——一顿一顿的。

一开始以为是图片太大或者JS执行太久，但看了 Lighthouse 报告发现，主线程里有一堆样式重计算（Recalculate Style），而且频率高得离谱。最离谱的是，滚动过程中居然每16ms都在触发，这不就是传说中的“样式抖动”？

我当时就意识到，问题大概率出在响应式逻辑上，而媒体查询可能是罪魁祸首之一。

找到病灶了！

我打开 Chrome DevTools 的 Performance 面板，录了一段滚动过程，放大 Timeline 一看，果然一堆黄色的“Recalculate Style”块堆在一起，每个都耗时5~8ms，加起来超过30ms，直接破帧。

点进去看具体调用栈，发现源头是 matchMedia 监听器和 CSS 媒体查询的组合触发。我们项目用了大量动态响应式组件，比如根据屏幕宽度切换布局的卡片、隐藏某些模块的侧边栏、移动端弹窗逻辑等等。这些都依赖 JavaScript 检测媒体查询状态：

const mql = window.matchMedia('(max-width: 768px)')
mql.addEventListener('change', (e) => {
  if (e.matches) {
    // 移动端逻辑
    initMobileMenu()
    adjustCardLayout()
  } else {
    // PC端逻辑
    destroyMobileMenu()
    resetCardLayout()
  }
})

问题就出在这儿：这个监听器绑得太粗暴，每次窗口尺寸变化都会触发一次回调，而回调里又去操作DOM、重新初始化组件。更坑的是，有些组件自己也监听同样的媒体查询，导致重复执行、互相干扰。

我还发现一个问题：CSS 里的 @media 查询写得特别碎，一个按钮的字体大小、内边距、图标显示，全拆成十几个 media query 块，分散在不同 SCSS 文件里。Webpack 打包后虽然合并了，但浏览器解析时还是要反复比对 viewport 变化，增加样式重计算压力。

优化方案1：节流 + 状态缓存

第一轮优化我先从 JS 入手。既然 matchMedia 的 change 事件无法避免触发，那就不能让它频繁执行回调。我加了个简单的节流：

function throttle(fn, delay) {
  let timer = null
  return function (...args) {
    if (timer) return
    timer = setTimeout(() => {
      fn.apply(this, args)
      timer = null
    }, delay)
  }
}

const handleResize = throttle(() => {
  updateLayoutForBreakpoint()
}, 100)

但这还不够，因为 updateLayoutForBreakpoint 里面还是会查 window.innerWidth，而这个值在 resize 过程中会频繁读取，可能引发强制同步布局。所以我干脆把当前断点状态缓存下来，只在真正需要时才更新：

let currentBreakpoint = getBreakpoint() // 'mobile' | 'tablet' | 'desktop'

function getBreakpoint() {
  if (window.innerWidth <= 768) return 'mobile'
  if (window.innerWidth <= 1024) return 'tablet'
  return 'desktop'
}

const mql = window.matchMedia('(max-width: 1024px)')
mql.addEventListener('change', () => {
  const newPoint = getBreakpoint()
  if (newPoint !== currentBreakpoint) {
    currentBreakpoint = newPoint
    updateLayoutDebounced() // 使用防抖，避免短时间内多次更新
  }
})

这里注意我踩过好几次坑：一开始用 resize 事件监听，结果 iOS Safari 上键盘弹出也会触发 resize，导致误判断点。后来改用 matchMedia，才是真正的媒体状态变更，不会被软键盘干扰。

优化方案2：合并媒体查询，减少CSS复杂度

CSS 层面的问题更隐蔽。原本我们的响应式样式是“功能驱动”的，每个组件自己写自己的 media query，结果同一个属性被反复覆盖：

/* card.component.css */
@media (max-width: 768px) {
  .card { padding: 12px; }
}
@media (max-width: 576px) {
  .card { padding: 8px; }
}

/* button.component.css */
@media (max-width: 768px) {
  .btn { font-size: 14px; }
}
@media (max-width: 576px) {
  .btn { font-size: 12px; }
}

这种写法会导致浏览器在每次视口变化时，都要重新评估所有 media block，哪怕它们属于不同组件。我做了个实验：把所有 media query 合并到一个全局文件中，按断点集中管理：

/* responsive.css */
/* Mobile First */
.card { padding: 16px; }
.btn { font-size: 16px; }

/* Tablet */
@media (min-width: 769px) and (max-width: 1024px) {
  .card { padding: 16px; }
  .btn { font-size: 16px; }
}

/* Desktop */
@media (min-width: 1025px) {
  .card { padding: 20px; }
  .btn { font-size: 18px; }
}

看起来代码变长了，但实际上减少了 CSSOM 的匹配次数。浏览器只需要判断当前属于哪个断点区间，就能确定整套样式，而不是逐条扫描十几个 media 规则。

顺便把 SCSS 的嵌套层级从5层干到2层以内，避免生成过于复杂的 CSS 选择器。之前有个 .sidebar .menu ul li a:hover 这种五层嵌套，光解析就要多花2~3ms。

优化方案3：关键样式内联，延迟非关键响应式资源

还有一个大头是首屏渲染。我们首页有个轮播图，它的响应式图片切换逻辑是通过 JS 加载完后再判断的：

fetch('https://jztheme.com/api/banners')
  .then(res => res.json())
  .then(data => {
    const img = document.getElementById('hero-banner')
    if (window.innerWidth < 768) {
      img.src = data.mobileImage
    } else {
      img.src = data.desktopImage
    }
  })

问题是这个请求要等 JS 执行完才能决定加载哪张图，网络面板里经常看到先加载 desktop 版本，再替换 mobile 版本，白白浪费流量。

我改成用 <picture> 标签原生支持响应式图片，直接由浏览器决定加载哪个资源：

<picture>
  <source media="(max-width: 768px)" srcset="https://jztheme.com/images/banner-mobile.jpg">
  <img src="https://jztheme.com/images/banner-desktop.jpg" alt="Banner">
</picture>

同时把非首屏的响应式组件（比如页脚导航、评论区）的 JS 逻辑延迟到用户滚动到可视区域时再加载，用 Intersection Observer 控制：

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      loadResponsiveComponent(entry.target)
      observer.unobserve(entry.target)
    }
  })
})