从视口响应到组件响应：如何利用 CSS Container Queries 打造高复用 UI 组件

同一张文章卡片放进 WordPress 首页的主内容区与侧边栏，往往会暴露传统响应式设计的局限：浏览器视口明明足够宽，侧边栏里的卡片却已经挤得放不下横向图片、标题和摘要。此时，基于视口宽度的 @media 并不知道组件实际可用的空间，只能靠额外类名、页面专用覆盖规则或重复组件变体补救。CSS Container Queries 的价值正在于此：让组件根据自己的容器决定形态，而不是跟随整个页面宽度。

在主题开发中，这类问题并不少见。比如一个“推荐文章”卡片，放在归档页的文章列表中时，希望图片位于左侧、正文位于右侧；放进侧边栏小工具、区块侧栏或编辑器预览区域后，则应改为图片在上、文字在下。它们的数据结构相同，视觉规则也相近，真正不同的只是父容器宽度。

视口查询为什么难以描述组件

传统写法通常会先给卡片一个横向布局，再在较窄视口下切换为纵向布局：

.article-card {
  display: grid;
  grid-template-columns: 10rem 1fr;
  gap: 1rem;
}

.article-card__image {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

@media (max-width: 48rem) {
  .article-card {
    grid-template-columns: 1fr;
  }

  .article-card__image {
    aspect-ratio: 16 / 9;
  }
}

这段代码在单栏页面里没有问题。但在桌面视口下，侧边栏可能只有几百像素宽，@media 仍然不会触发，卡片继续维持两列布局。开发者随后往往会写出类似 .sidebar .article-card 的覆盖规则，或者再提供一个专门的紧凑卡片类。

问题不在于这些方案不能用，而在于组件的展示规则被页面结构绑住了。卡片必须知道自己被谁包裹、出现在哪个模板里，才能正确响应。对于可插入区块、侧栏组件、查询循环或可配置模板而言，这会持续增加维护成本。

容器查询把判断条件换成了更贴近组件本身的问题：卡片所在的可用空间是否足以容纳横向排版？

先为卡片建立查询上下文

容器查询不会自动把所有父元素当作查询对象。需要先在合适的祖先元素上声明容器类型。对于大多数只关心宽度变化的文章卡片，inline-size 是最常见的选择。

下面以一个 WordPress 主题中的内容区域为例。主内容区和侧边栏都可以成为卡片的查询容器：

<main class="content-area">
  <article class="article-card">
    <img class="article-card__image" src="post-cover.jpg" alt="文章封面">
    <div class="article-card__body">
      <p class="article-card__meta">前端开发</p>
      <h2 class="article-card__title">让文章卡片适应不同的展示位置</h2>
      <p class="article-card__excerpt">同一份文章数据，可以在宽阔列表和紧凑侧边栏中呈现不同布局。</p>
    </div>
  </article>
</main>

<aside class="sidebar-area">
  <article class="article-card">
    <img class="article-card__image" src="post-cover.jpg" alt="文章封面">
    <div class="article-card__body">
      <p class="article-card__meta">前端开发</p>
      <h2 class="article-card__title">让文章卡片适应不同的展示位置</h2>
      <p class="article-card__excerpt">同一份文章数据，可以在宽阔列表和紧凑侧边栏中呈现不同布局。</p>
    </div>
  </article>
</aside>

.content-area,
.sidebar-area {
  container-type: inline-size;
}

container-type: inline-size 的意思是：该元素建立一个可供后代查询行内方向尺寸的容器。在常见的横向书写模式中，行内方向通常就是宽度。卡片不需要知道自己位于 .content-area 还是 .sidebar-area，它只会读取最近查询容器提供的可用宽度。

也可以使用简写属性：

.sidebar-area {
  container: sidebar / inline-size;
}

这相当于同时声明容器名称与类型。命名并非每次都必须，但当组件嵌套较深、页面中存在多个容器层级，或者你想明确指定查询哪个祖先容器时，名称会让规则更可读。

用 @container 重构固定布局卡片

更适合复用的思路，是先把卡片定义为紧凑的单列基础形态，然后只在容器足够宽时升级为横向布局。这样即使容器查询不可用，基础布局仍然保持可读。

.content-area,
.sidebar-area {
  container-type: inline-size;
}

.article-card {
  display: grid;
  gap: 0.875rem;
  padding: 1rem;
  border: 1px solid #d9d9d9;
  background: #fff;
}

.article-card__image {
  display: block;
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

.article-card__body {
  min-width: 0;
}

.article-card__meta {
  margin: 0 0 0.375rem;
}

.article-card__title {
  margin: 0;
}

.article-card__excerpt {
  margin: 0.625rem 0 0;
}

@container (min-width: 42rem) {
  .article-card {
    grid-template-columns: minmax(10rem, 2fr) minmax(0, 3fr);
    align-items: start;
  }

  .article-card__image {
    height: 100%;
    aspect-ratio: auto;
  }
}

这里的 @container (min-width: 42rem) 与媒体查询的写法相似，但判断对象不同。它不是检查浏览器窗口是否达到某个宽度，而是检查最近的查询容器是否达到该宽度。

当卡片放入侧边栏时，容器通常不足以满足条件，组件保留单列布局；当它进入主内容区且容器宽度足够时，规则生效，卡片自动切换为图文横排。模板不必为两个位置分别维护卡片样式，区块渲染逻辑也不必增加“侧边栏模式”之类的展示参数。

minmax(0, 3fr) 在这里有一个实际用途：它允许文字列在空间受限时收缩，避免长标题或长链接内容把网格列撑开。min-width: 0 同样用于让正文区域能够正常缩小。这些细节不是容器查询专属，但当组件被放进未知宽度的容器时，往往决定了布局是否真的稳定。

container-type 与 @container 如何配合

可以把 container-type 理解为“允许被测量的边界”，把 @container 理解为“针对这个边界写出的条件样式”。

container-type: inline-size 适合绝大多数以宽度为判断依据的组件，包括文章卡片、导航项、信息面板、评论摘要和区块编辑器中的内容模块。它的重点不是让元素本身响应，而是让它的后代能够根据这个元素的尺寸改变样式。

默认情况下，@container 会寻找最近的符合条件祖先容器：

@container (min-width: 42rem) {
  .article-card__excerpt {
    display: block;
  }
}

如果页面结构复杂，最近的容器未必是你想查询的那个对象，可以给容器命名：

.content-area {
  container-name: article-list;
  container-type: inline-size;
}

@container article-list (min-width: 42rem) {
  .article-card {
    grid-template-columns: minmax(10rem, 2fr) minmax(0, 3fr);
  }
}

也可以继续使用前面提到的简写形式：

.content-area {
  container: article-list / inline-size;
}

命名容器更适合具有明确布局职责的外层区域，例如文章列表、查询循环或侧栏区域。不要为了“统一规范”给每个普通包装元素都加名字，否则组件的样式关系会重新变得难以追踪。

断点应来自组件，而不是设备名称

容器查询最容易被误用的地方，是把原来的“手机、平板、桌面”断点原封不动搬过来。组件级响应不该先问设备是什么，而应该观察布局何时开始失真。

以文章卡片为例，可以先在主内容区和侧边栏分别测试：横向布局从哪个宽度开始让缩略图过小、标题换行过多，或者摘要显得拥挤。这个临界点才是该组件值得切换布局的位置。它不需要和全站导航的断点一致，也不需要对应某一种设备。

全站性的页面骨架仍然适合使用 @media。例如页面是否从双栏改为单栏、站点导航是否折叠、整体留白是否调整，本质上仍是视口级决策。容器查询解决的是组件在既定页面结构中的局部适应，两者不是替代关系。

一个实用的判断标准是：如果你修改的是页面整体布局，就优先考虑媒体查询；如果你修改的是某个可被放入不同区域的组件内部排版，就优先考虑容器查询。

在 WordPress 主题与区块中控制边界

主题开发时，建议把容器声明放在真正决定可用宽度的布局元素上，而不是随手放在卡片外层。对于查询循环、相关文章区域或侧边栏小工具，通常由列表包装器、栏目容器或侧栏容器承担这个职责。

区块开发也应遵循同一个原则。区块内部的卡片可以保持相同标记结构，把响应能力写进样式；区块外部的布局系统负责提供宽度约束。这样，同一套卡片既可以出现在前台归档页面，也可以出现在编辑器中的窄列区域，而不必依赖特定父级选择器。

如果组件依赖容器查询来获得更丰富的布局，基础样式应仍然保证内容可读。单列图文结构通常是合适的基础形态；容器足够宽时再启用双列、增加摘要显示或扩大局部间距。这样既避免把兼容性问题转移给内容，也让组件在意外嵌套到狭窄区域时拥有合理的降级表现。

当你发现样式表中不断出现“某个页面里的某个区域中的某个卡片”这类选择器时，通常就是重构信号。先确认卡片真正依赖的是视口，还是父容器的可用空间；后者交给 container-type 和 @container，组件的复用边界会清晰得多。