CSS container query 的组件断点设计

CSS container query 的关键不是把 @media 换成另一个写法，而是把“谁决定组件断点”从 viewport 改成组件的宿主容器。这样，同一个卡片放进主栏、侧栏或网格时，可以按自身可用宽度改变布局，不必为每个页面位置维护一套全局断点。

最小可靠方案是：给组件宿主设置 container-type: inline-size，保留一套默认窄布局，再用 @container 在组件确实变宽时切换布局；只有存在多个候选祖先容器时才增加 container-name。

先把断点从视口移到组件宿主

@media 测量的是视口，适合页面级导航或整体栅格；可复用组件更关心自己的宿主宽度。尺寸容器查询需要先建立 containment context，常用的最小配置如下：

.card-shell {
  /* 只按宿主的行内尺寸查询，适合横向组件断点 */
  container-type: inline-size;
}

.card {
  /* 默认样式覆盖窄容器，也作为未命中查询时的安全基线 */
  display: grid;
  gap: 0.75rem;
}

@container (width >= 28rem) {
  .card {
    /* 宿主达到阈值后才切换为并排内容 */
    grid-template-columns: 8rem 1fr;
    align-items: center;
  }
}

这里的 28rem 是组件设计阈值，不是设备型号。阈值应该由标题、摘要、按钮等内容是否能舒展来决定；如果卡片在窄栏里仍然拥挤，就不要因为“桌面端”三个字强行套用 viewport 断点。

从全局断点迁移到命名容器

迁移旧代码时，先把原来依赖 viewport 的选择器拆成“默认样式 + 组件宿主查询”。如果页面中有嵌套容器，或者一个组件可能被多个祖先容器包住，给真正负责组件宽度的宿主命名，能减少查询命中错误祖先的风险。

.content-column {
  /* 命名后可以在 @container 中明确选择这个宿主 */
  container: card / inline-size;
}

.card {
  /* 默认规则不依赖视口，侧栏中也能正常工作 */
  grid-template-columns: 1fr;
}

@container card (width >= 28rem) {
  .card {
    /* 只有名为 card 的容器达到阈值时才展开布局 */
    grid-template-columns: 8rem 1fr;
  }
}

上面的简写等价于 container-name: card 和 container-type: inline-size。不需要命名时，优先使用无名的最近匹配容器，减少命名维护成本；需要命名时，名称应表达职责而不是页面位置，例如 card 比 desktop-sidebar-1 更适合复用。

断点设计中最容易漏掉的三个边界

1. 默认样式必须独立成立

@container 只负责命中条件后的增强，不应该承载组件唯一的可用布局。把窄布局写在普通规则中，既能覆盖小容器，也能让不支持该特性的环境保留基本可读性。需要更明确的能力分层时，可用 @supports (container-type: inline-size) 规划增强范围，但不要把所有基础样式都塞进查询块。

2. 容器要有可计算的尺寸来源

尺寸容器会采用尺寸 containment，容器不能再依赖子内容反向决定被查询的尺寸。宿主应当由块级布局拉伸，或由父级 grid/flex 轨道、明确宽度提供尺寸；如果宿主没有可用的上下文尺寸，布局可能出现塌缩，断点也没有稳定依据。

3. 查询的是合适的祖先，而不是任意父级

无名查询会寻找最近的匹配查询容器。嵌套卡片、广告位或面板组件同时存在时，先检查哪个祖先真正代表组件可用宽度；再决定是否用命名容器。一个 @container 条件不能直接同时指定多个容器，多个容器条件应通过嵌套查询表达。

迁移后的回归清单

1. 把同一组件放入主栏、窄侧栏和双列网格，观察布局是否按宿主宽度变化，而不是按窗口宽度变化。
2. 检查宿主是否设置了 inline-size 查询类型，是否存在依赖子内容反推尺寸的循环。
3. 把组件名称和容器名称分开维护，确认嵌套场景不会命中错误祖先。
4. 缩小到阈值两侧，分别检查标题换行、图片比例、按钮可点击区域和溢出处理。
5. 确认默认 CSS 在查询未命中或特性不可用时仍然可读，再逐项打开增强规则。

相关问题

container query 能完全替代 media query 吗？

不能。页面级导航、打印、主题和设备能力仍然属于 viewport 或环境条件；组件内部的布局断点才更适合交给 container query。两者可以并存，但应让每类条件负责自己的边界。

为什么设置了 @container 却没有生效？

优先检查祖先是否真的设置了匹配的 container-type，容器是否有可计算的宽度，以及选择器是否位于组件后续层叠范围内。若使用了命名查询，还要核对名称与宿主是否一致。

本文依据 MDN 的 CSS container queries、container-type 与 @container 说明整理，重点是把断点决策绑定到组件宿主，而不是把 viewport 断点机械改名。