别再像用媒体查询那样用容器查询

容器查询被误解了

CSS 容器查询（Container Queries）的浏览器支持已经相当广泛，但实际项目里用得并不多，而且经常被当成媒体查询的替代品来写。这种理解会让人错过它真正的价值。

媒体查询问的是「视口有多宽」，容器查询问的是「我所在的这个容器有多宽」。问题不同，答案自然也不同。

两者的本质区别

媒体查询：面向全局环境

媒体查询基于视口、设备方向、分辨率等全局条件。它适合处理页面级别的布局切换，比如：

• 移动端隐藏侧边栏
• 大屏时把导航从汉堡菜单换成横向菜单
• 根据深色模式切换配色

这些决策和整个页面相关，和某个具体组件无关。

容器查询：面向组件自身

容器查询基于最近的已声明容器的尺寸。组件不再关心窗口多宽，只关心「我现在被放进了一个多宽的格子里」。

这意味着同一个组件，放在侧边栏里可以变成紧凑的纵向卡片，放在主内容区里可以自动展开成横向布局，而不需要为每种场景写额外的类名或 props。

为什么这对可复用组件很重要

传统做法里，组件要适配不同上下文，通常得靠外部传参：

<Card layout="compact" />
<Card layout="wide" />

或者由父级用媒体查询断点来强行约束。问题是，组件本身并不知道自己被放在哪里，只能被动接受外部的判断。

容器查询把判断权交还给组件自己：

.card-wrapper {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 120px 1fr;
  }
}

组件在窄容器里堆叠，在宽容器里并排，逻辑内聚在组件自己的样式里，复用时不用再操心布局参数。

什么时候该用哪个

可以按这个思路判断：

• 页面整体结构变化 → 媒体查询。比如整站导航、页脚、主栅格。
• 单个组件的内部布局变化 → 容器查询。比如卡片、列表项、表单控件组。
• 两者都需要 → 用媒体查询控制页面骨架，用容器查询控制组件内部。它们不是竞争关系，而是分工不同。

一个常见的误区是：既然有了容器查询，是不是可以完全不用媒体查询了？答案是否定的。容器查询解决不了「整个页面在手机上应该怎么排」这类问题，因为它根本看不到视口。

实用建议

1. 给容器起个名字，用 container-name 避免嵌套容器时匹配到错误的祖先。
2. 只在需要响应的地方声明容器，container-type: inline-size 会带来一定的布局约束，不要无脑全局加。
3. 断点按组件内容定，而不是照搬设备断点。组件的临界宽度由它自己的内容决定。
4. 配合 @container 的尺寸查询单位（如 cqw、cqi），可以让字号、间距也随容器缩放。

对谁最有价值

• 组件库作者：一次编写，处处自适应，减少 API 表面。
• 设计系统维护者：组件在不同布局槽位中表现一致，减少特例。
• 普通前端开发者：少写一堆断点和条件类名，样式更贴近组件本身。

容器查询不是媒体查询的升级版，而是解决另一类问题的工具。把它用在组件层面，才能发挥它真正的能力。