媒体查询未被淘汰，仍是视口级响应的唯一方案；容器查询仅解决组件级响应，依赖父容器显式声明。典型场景包括整页布局切换、打印样式、横竖屏判断等，且需配合 viewport 元标签使用。
媒体查询在现代 CSS 中是否已被淘汰
没有被淘汰，反而比过去更关键。容器查询（@container）虽已进入主流浏览器，但它解决的是组件级响应问题，而媒体查询（@media）仍唯一负责视口级响应——比如导航栏在手机上折叠、整页栅格从 4 列变为 1 列、字体随屏幕宽度阶梯调整。只要页面需要根据设备宽度/高度/横竖屏/分辨率做整体布局切换，@media 就不可替代。
什么时候该用媒体查询而不是容器查询
选媒体查询的典型场景包括：
- 整个
<header>在max-width: 768px下隐藏右侧菜单项 - 使用
rem或vw基准动态缩放根字号，依赖screen.width级别判断 - 适配打印样式（
@media print），或高对比度模式（@media (prefers-contrast: high)） - 需要读取
orientation、hover、any-hover等全局输入能力特征时
容器查询无法感知这些，它只看父容器尺寸和 container-type 设置，且要求父元素显式声明容器上下文（container: layout / inline-size）。
写媒体查询时最常踩的三个坑
实际项目中高频出错点：
立即学习“前端免费学习笔记（深入）”；
-
min-width和max-width混用导致断点重叠或遗漏：建议统一用min-width递增写法（如@media (min-width: 480px),@media (min-width: 768px)），避免用max-width做“上限”逻辑 - 断点值硬编码像素数：应优先用设计系统定义的语义化断点变量（如
--breakpoint-sm: 480px），配合 CSS 自定义属性或预处理器变量管理 - 忽略视口元标签：HTML 中漏掉
<meta name="viewport" content="width=device-width, initial-scale=1">，会导致移动端@media完全不触发
性能与兼容性现状（2024 年实测）
@media 的解析开销极低，浏览器在 CSSOM 构建阶段就完成匹配，无运行时成本。兼容性方面：
- 所有现代浏览器（Chrome 21+、Firefox 6+、Safari 6.1+、Edge 12+）完整支持
@media及常用特性（width,height,orientation,prefers-reduced-motion） -
dynamic-range、color-gamut等新特性仅在 Safari / Chrome 最新版可用，生产环境慎用 - 不要试图用 JavaScript 动态插入大量
@media规则——CSSOM 重排代价远高于单条规则维护
真正容易被忽略的是：媒体查询本身不触发重绘，但其中的属性变更（如 display: none、transform）可能引发布局抖动。检查工具里看到的“强制同步布局”，往往不是 @media 的锅，而是里面写的样式副作用太大。
