CSS container query 和 media query 应该按什么条件选择

CSS 响应式规则的选择，先看“谁在变化”：如果页面要随着浏览器视口、打印介质或用户偏好变化，用 @media；如果一个组件要随着最近的父级容器宽度变化，用 @container。两者不是互相替代的关系，真实项目通常由 @media 管页面外壳，再由 @container 管可复用组件。

先按变化来源判断是视口还是组件容器

判断点只有一个：这条规则需要读取哪块空间？页面顶部导航是否折叠，往往取决于浏览器视口宽度；一张卡片在主栏里横排、放进侧栏后改为上下排，则取决于它的父容器宽度。后者如果继续使用 @media，就会出现“窗口很宽但侧栏很窄”的错配。

@media 的媒体特性可以描述视口尺寸、方向、打印介质以及减少动效等环境偏好。@container 则把条件附着到容器名称、容器尺寸或容器样式上。换句话说，前者回答“当前页面处在什么环境”，后者回答“这个组件拿到了多少空间”。

用 media query 控制页面级布局

页面外壳通常拥有稳定的责任：控制主栏和侧栏是否并列、导航是否收起、页面留白是否减少。这些变化与组件被放在哪里无关，使用媒体查询更直观。可以先写窄屏默认值，再在视口变宽时增加列布局：

.page-shell {
  /* 先让页面在窄视口中保持单列 */
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
}

@media (width >= 48rem) {
  .page-shell {
    /* 视口足够宽时，页面外壳才分出侧栏 */
    grid-template-columns: minmax(12rem, 16rem) 1fr;
    gap: 2rem;
  }
}

这个断点描述的是页面可用宽度，不应该顺手决定卡片标题字号、按钮排列等组件细节。若还要适配打印或减少动效，也可以继续在 @media 中写对应的媒体条件；它的优势就是能集中表达页面与设备环境的规则。

用 container query 让可复用组件响应自身宽度

要让尺寸型容器查询生效，先在组件外层建立查询容器。组件只需要关心自己的内容区域，不必知道它被页面主栏、侧栏还是弹窗使用：

.card-list {
  /* inline-size 让查询依据容器的行内尺寸 */
  container: card-list / inline-size;
}

.card {
  /* 默认状态适合窄容器，作为兼容降级 */
  display: grid;
  grid-template-columns: 1fr;
  gap: .75rem;
}

@container card-list (inline-size >= 36rem) {
  .card {
    /* 容器足够宽时，组件内部切换为横向结构 */
    grid-template-columns: 8rem 1fr;
  }
}

container 是设置容器名称与类型的简写；也可以分别写 container-name 和 container-type: inline-size。命名不是必需的，但在页面存在嵌套容器时更容易读懂规则指向。这里的默认样式很重要：即使目标环境暂时不采用容器查询，卡片也有一个可用的窄版布局。

从作用域、复用性和降级成本比较两种查询

两种查询都使用条件规则，但设计责任不同。把下面几项放在一起比较，通常就能避免把断点放错层：

容器查询还要留意查询对象的选择。无名 @container 会寻找符合条件的最近容器；多个嵌套容器存在时，命名可以减少误读。尺寸容器的尺寸需要由布局上下文或明确尺寸提供，否则容器本身没有稳定的可查询空间，规则就很难得到预期结果。

用三问法决定单用或组合使用

落地时可以先问三句：

• 变化是否由浏览器视口、打印介质或用户偏好触发？是，就优先放在 @media。
• 组件是否会在不同宽度的父布局中重复使用？是，就为组件建立查询容器并考虑 @container。
• 页面外壳和组件内部是否同时变化？是，组合使用：@media 负责页面骨架，@container 负责模块内部。

不建议为了“现代”而把所有媒体查询改成容器查询，也不建议用一个全局 viewport 断点控制所有卡片。先保持默认布局可用，再让查询只承担它真正观察到的变化，CSS 会更容易维护。

相关问题

@container 可以完全替代 @media 吗？

不能。设备偏好、打印介质和页面整体视口仍属于媒体查询的职责；容器查询解决的是组件局部空间问题。

为什么写了 @container 却没有效果？

先检查祖先是否设置了 container-type 或 container，再检查查询条件的轴是否与布局一致，以及目标元素是否确实位于该查询容器的后代范围内。

组件很少复用时是否必须使用容器查询？

不必。若页面结构单一、默认布局配合流式尺寸已经足够，媒体查询或普通响应式 CSS 更简单；只有组件需要脱离页面断点独立适配时，容器查询的收益才明显。

参考资料：MDN CSS container queries、MDN CSS media queries、W3C CSS Containment Module Level 3。