CSS container-type 实战：让卡片组件按自身宽度切换布局

把一张卡片放进主栏、侧栏和弹窗后，最容易出现的不是 CSS 写错，而是组件只知道浏览器窗口有多宽，却不知道自己实际拿到了多少空间。这个示例用 CSS container-type 建立命名容器，让卡片根据自身容器宽度在纵向和横向布局之间切换；左侧拖到 560px 以上会横向排版，右侧窄栏仍保持紧凑布局。

需要复用的卡片组件，优先查询最近的容器宽度；先在父元素写 container: card / inline-size，再用 @container card (min-width: 560px) 控制子元素。

为什么媒体查询会让复用卡片变得别扭

@media 观察的是视口。页面整体很宽时，侧栏里的卡片也可能误判为“适合横排”，结果是图片挤压标题。这个问题在仪表盘、文章推荐位和抽屉面板里很常见：组件位置变了，组件代码却没有变化，布局判断的参照物才是根因。

运行示例：同一张卡片在两种容器里表现不同

下面的证据来自同一个浏览器页面和同一份 demo.html。左边按钮会把容器切到 650px 或 360px；状态栏会直接显示规则是否命中。右侧卡片固定在窄栏，用来证明视口没有变化时，父容器宽度仍然可以决定子组件布局。

容器声明要放在组件外层

本例使用 container: card / inline-size，它同时声明名称和查询类型。inline-size 足够覆盖横向书写模式下的宽度判断；如果误写成默认的 normal，尺寸查询没有可用的容器上下文。

.card-host {
  container: card / inline-size;
}

.card {
  display: grid;
  grid-template-columns: 1fr;
}

@container card (min-width: 560px) {
  .card {
    grid-template-columns: 190px 1fr;
  }
}

断点怎么定：先量内容，再写规则

560px 不是设备型号断点，而是这张卡片的内容阈值：图片占 190px 后，标题、摘要和元信息仍有足够空间。实际项目里可以先把容器拉宽、拉窄，观察标题最小可读宽度，再决定断点。不要把桌面端 768px 原样搬进组件，这会让同一个组件在侧栏中显得过晚切换。

常见坑：为什么写了 @container 却没有变化

只写了查询，没有建立容器

没有 container-type 或 container 时，尺寸查询找不到正确的容器。先用开发者工具检查父元素的计算样式，再看查询条件。

父元素宽度由内容撑开

inline-size 需要一个可计算的尺寸。如果父元素本身处于不受约束的行内布局，容器宽度可能不是你以为的值，给父级设置明确的网格列、块级拉伸或可控宽度更稳妥。

把尺寸查询写成视口查询

组件内部使用 @media 会重新依赖窗口；这类规则适合页面级布局，不适合需要跨区域复用的卡片。

相关问题

container-type 用 size 还是 inline-size？

只按横向宽度切换布局时用 inline-size；需要同时查询块方向尺寸时才考虑 size，并评估尺寸包含带来的布局影响。

container query 能完全替代 media query 吗？

不能。页面整体的导航、列数和视口适配仍适合 @media；组件内部的布局选择才更适合 @container。

如何确认浏览器真的命中了规则？

先看组件的可见排列，再在开发者工具的 Styles 面板展开对应的 @container 规则；本例额外把容器宽度和命中状态显示在卡片下方。

小结

CSS container query 的价值不在于多一个断点语法，而在于把布局判断交给真正拥有空间的父容器。给组件外层建立命名容器，使用一个贴合内容的阈值，再用浏览器实际拖动验证宽窄两态，卡片就能在主栏和侧栏之间保持同一份结构。