先记住这个答案
窗口缩放时，浏览器会重新判断媒体查询并重算受影响元素的样式，但查询表达式本身通常很轻。看到掉帧，要在性能面板确认时间花在样式计算、布局、绘制还是 JavaScript；如果只是切换了大图或复杂网格，删掉媒体查询并不能解决成本。优化目标是命中后的工作量，而不是查询条数本身。
- 查询条数不是性能结论
- 环境变化会重新判断匹配
- 布局改动可能比颜色改动更贵
- 用 Performance 找真正耗时
拖动窗口卡顿时先看耗时
窗口拖拽时，一个复杂看板会卡顿。看到样式表有很多 @media，不能直接删除一半。用浏览器 Performance 录制拖拽过程，看耗时集中在 Recalculate Style、Layout、Paint 还是 JavaScript。若每个断点都让数百个卡片改变网格列数，布局成本可能很高；若脚本在 resize 里频繁读写尺寸，也可能造成同步布局。优化对象应是触发的工作量。
@media (min-width: 60rem) {
.dashboard {
grid-template-columns: repeat(3, minmax(0, 1fr));
}
}
/* 少量清晰断点通常比在 resize 中逐帧改内联样式更稳 */媒体条件变化时，浏览器需要确定哪些规则开始或停止匹配，然后更新相关元素的计算样式。
样式重新计算与真正的画面更新也不是一回事。一个断点改变 color 可能主要涉及绘制；改变网格列数可能让大量元素重新布局。若只是断点附近反复跨过阈值，先检查滚动条出现和消失是否改变可用宽度，让规则来回切换。用性能录制找出触发条件、受影响元素和耗时阶段，才能决定是改布局、资源还是脚本。
匹配变化之后才是主要成本
若变化涉及 display、宽高或网格轨道，可能需要布局和绘制；颜色变化通常不需要同样的布局工作。页面性能还取决于元素数量、DOM 复杂度和脚本行为，无法仅凭媒体查询条数判断。实践中应让断点表达组件真实需求，避免相互覆盖的大量近似阈值，必要时把巨大区域拆成更独立的组件。
如果性能录制里看到大量 Layout，不要先删断点。可以检查命中规则是否让几百张卡片同时改变列数、是否在窗口缩放处理器里反复读取 getBoundingClientRect() 后又写样式。把布局限定在真正需要的组件、减少强制同步测量，再比较同一设备上的录制结果，才能知道瓶颈有没有移动。
容易答错的地方
- 把每条媒体查询视为每帧执行的脚本
- 浏览器按环境变化判断匹配，具体成本要看被改变的样式和页面规模。
- 只减少断点数量就声称性能提升
- 如果单条规则仍令大范围布局重算，数量减少不代表用户感知更快。
面试官还会怎么问？
改颜色和改列数的成本相同吗？
通常不同。列数变化可能重新布局很多项目，颜色变化主要影响绘制；具体还要看渲染路径。
matchMedia 监听会比 CSS 更快吗？
它适合脚本确实要知道环境状态的场景；纯布局交给 CSS，增加脚本监听未必降低成本。
如何验证优化有效？
在相同设备和操作下对比 Performance 记录，观察布局、样式计算和长任务时间。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。