容器查询不是媒体查询的替代品

一个被严重低估的 CSS 特性

CSS 容器查询（Container Queries）的浏览器支持率已经接近 94%，按理说它早该成为前端日常工具。但现实是：State of CSS 调查显示，86% 的开发者知道容器查询的存在，却只有 41.4% 真正在用。在 SmashingConf Amsterdam 2026 上，CSS 专家 Kevin Powell 也直言：容器查询的采用率"糟糕透顶"。

这不是一个技术门槛问题，而是一个认知误区问题。大多数人第一次接触容器查询时，脑子里冒出的第一个念头是："这不就是媒体查询吗？"

而正是这个"看起来很像"的印象，让开发者们把它用错了。

媒体查询到底在问什么？

写 @media (min-width: 1024px) 时，你实际上是在问浏览器："屏幕现在有多宽？"

这就是媒体查询的全部逻辑——它只关心视口（viewport），不关心任何组件自身所处的空间。这在大多数情况下够用，但会制造一个经典问题：

一个卡片组件被放进一个 300px 宽的网格单元里，而桌面屏幕宽度是 1920px。媒体查询看到 1920px，触发 min-width: 1024px，于是给卡片应用了为"宽屏"设计的样式——但卡片实际只有 300px 的空间。结果就是内容溢出、挤压、变形。

Kevin Powell 对此有一句精辟总结："媒体查询并不笨，只是它知道的东西太少。"

容器查询真正解决的问题

容器查询回答的是另一个问题："我所在的容器有多宽？"

/* 定义容器 */
.card-wrapper {
  container-type: inline-size;
}

/* 基于容器宽度做响应 */
@container (min-width: 400px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

这意味着，无论这个卡片组件被放在页面顶部、侧边栏、弹窗、还是任何宽度不同的布局区域，它都能根据自己实际拥有的空间来决定展示方式。

这对谁最有价值？

• 组件库开发者：组件可以真正做到"放进任何地方都能自适应"，不需要调用方为每个使用场景写不同的样式覆盖。
• 设计系统维护者：减少"这个组件在某个页面布局下会溢出"这类反复出现的 bug。
• 全栈开发者：前后端分离时，前端组件不再依赖页面级别的断点协调，降低了耦合度。

不要把容器查询当媒体查询用

最常见的错误用法是：把原来用 @media 写的断点逻辑，直接换成 @container，但没有定义容器。这样做的结果是容器查询完全不生效，或者行为不符合预期。

正确的思路是：

1. 先确定哪些组件需要独立响应——通常是那些会被复用到不同宽度布局中的组件。
2. 在组件的父元素上声明 container-type，告诉浏览器"这是一个容器"。
3. 用 @container 替代 @media 来写组件内部的响应逻辑，断点值应该基于组件的实际可用空间，而不是屏幕宽度。

什么时候该用媒体查询，什么时候该用容器查询？

场景	推荐方案
页面整体布局切换（导航栏、页脚）	媒体查询
全局排版（字体大小、间距基准）	媒体查询
可复用组件的内部布局（卡片、弹窗、表格）	容器查询
组件在不同容器宽度下需要不同展示	容器查询

两者不是替代关系，而是互补关系。媒体查询管"页面级"响应，容器查询管"组件级"响应。

一句话总结

容器查询不是"更好的媒体查询"，它是解决一个媒体查询根本解决不了的问题的工具：让组件知道自己在哪、有多大，然后自己决定怎么展示。如果你还在用媒体查询给卡片、弹窗、表格写断点，是时候重新审视一下了。