媒体查询本身性能开销极低，问题多源于JS频繁读取宽高、回调未防抖、CSS选择器冗余或断点值不统一；应共用CSS自定义属性管理断点，采用移动优先的min-width写法，并确保viewport标签正确。
不会拖慢，但写法不当会让断点响应变卡、样式错乱，甚至触发重排重绘。
媒体查询本身不耗性能，但频繁重算会拖累渲染
浏览器解析 @media 规则是静态的，只要没触发视口变化或 DOM 重排，它几乎零开销。真正出问题的是：你在 JS 里反复读取 window.innerWidth 判断断点，或用 matchMedia().addListener() 绑定太多回调，又没做防抖；或者 CSS 里写了嵌套过深、选择器爆炸的媒体查询块（比如每个断点都重复写一整套组件样式）。
- 避免在
scroll或resize事件里直接调用getComputedStyle()或操作 class - 用
matchMedia()替代手动比对宽度，它底层由浏览器优化，响应更快 - 把断点值抽成 CSS 自定义属性（如
--breakpoint-md: 768px），配合min-width使用，减少 JS 干预
断点设置和媒体查询必须共用同一套数值
前端常犯的错误是：Sass 变量里定义了 $md: 768px，JS 里却写 if (width >= 767)，CSS 媒体查询又用了 @media (min-width: 769px)——三处数值不一致，断点就会“错位”，比如导航栏在 768px 时该收起却还展开，用户拉拽窗口时来回闪动。
- 所有断点值统一管理，推荐放在一个 JSON 文件或 CSS
:root中，例如：:root { --breakpoint-sm: 576px; --breakpoint-md: 768px; } - CSS 中直接引用：
@media (min-width: var(--breakpoint-md)) { ... } - JS 中用
getComputedStyle(document.documentElement).getPropertyValue('--breakpoint-md')读取，转成数字后比较
移动端优先下，max-width 断点容易漏掉边界情况
比如写 @media (max-width: 767px)，当设备宽度恰好是 767.5px（很多平板横屏、高 DPR 屏幕常见），这个媒体查询可能不匹配，导致样式没生效。而 min-width + 移动端优先写法更稳定。
立即学习“前端免费学习笔记（深入）”；
- 优先用移动优先：默认写小屏样式，再用
@media (min-width: 768px)覆盖中屏 - 如果必须用
max-width，记得补上and (orientation: portrait)等条件，或改用em单位（如48em≈ 768px），规避像素截断问题 - 测试时别只看整数宽度，用 Chrome DevTools 的 device toolbar 拖动滑块，观察 767–769px 区间是否平滑过渡
最常被忽略的是：媒体查询生效依赖视口元标签是否正确。如果漏了 <meta name="viewport" content="width=device-width, initial-scale=1">，iOS Safari 会强制以 980px 渲染，所有 max-width: 768px 查询都失效——这跟代码写得再漂亮也没关系。
