容器查询让卡片自己适配
卡片只关心所在容器的宽度。
来源:17golang原创
时间:2026-09-15 23:27:09 387浏览 收藏
同一个文章卡片被放进主栏、侧栏或弹窗时,按浏览器视口写的媒体查询很容易失去复用性:视口很宽,侧栏里的卡片却仍然只有一小段空间。CSS container queries 的解决方式是把响应式条件交给卡片所在容器。先给容器建立 inline-size 查询上下文,再用 @container 按容器宽度切换卡片布局,组件就不必知道自己被放在哪里。
container-type: inline-size 让元素成为按内联尺寸查询的容器。@container 的条件比较的是合格祖先容器,不是浏览器视口。container-name 或 container 简写锁定查询对象,同时准备媒体查询回退。先做一个最小的文章列表:外层控制卡片可用宽度,卡片本身只负责内容。这里选 inline-size,因为目标是根据横向可用空间在单列和两列之间切换;不需要让查询依赖块方向尺寸。
容器查询让卡片自己适配
卡片只关心所在容器的宽度。
.card-list {
/* 只按内联尺寸建立查询上下文,不把视口宽度传给组件。 */
container-type: inline-size;
display: grid;
gap: 1rem;
}
.post-card {
/* 默认状态给窄容器使用,先保证内容不会横向挤压。 */
display: grid;
grid-template-columns: 1fr;
gap: 1rem;
}
@container (width >= 42rem) {
.post-card {
/* 容器达到阈值后才切成封面加正文两列。 */
grid-template-columns: 12rem 1fr;
}
}
这段规则的关键不是阈值数值,而是阈值的参照物。card-list 只有在自身宽度达到 42rem 时才触发两列;同一张卡片放进窄侧栏,仍会回到默认单列。

@container 条件的静态关系。默认情况下,@container 会寻找最近的、具备相应容器上下文的祖先。如果列表外面还有布局壳层、侧栏和嵌套卡片,最好给真正负责宽度的元素命名,避免以后增加包装层时命中意外对象。
.layout-shell {
/* 页面壳层可以负责整体布局,但不参与卡片宽度查询。 */
display: grid;
grid-template-columns: minmax(12rem, 18rem) minmax(0, 1fr);
gap: 1.5rem;
}
.card-list {
/* 简写同时声明容器名字和查询轴,便于条件明确指向列表。 */
container: card-list / inline-size;
}
@container card-list (width >= 42rem) {
.post-card {
/* 只有名为 card-list 的容器达到阈值才使用横向卡片。 */
grid-template-columns: 12rem 1fr;
}
}
container: card-list / inline-size 是 container-name 与 container-type 的简写。若项目需要分别维护声明,也可以写成 container-name: card-list 和 container-type: inline-size。命名只负责选对象,不会替你改变查询轴。
| 设置 | 查询依据 | 适合场景 |
|---|---|---|
inline-size | 容器的内联尺寸 | 横向响应式卡片、列表和组件 |
size | 内联与块尺寸 | 确实需要同时参考两个方向的组件 |
normal | 不建立尺寸查询容器 | 只保留命名容器或样式查询语义 |
多数横向布局用 inline-size 就够了。直接改成 size 并不会让卡片更“响应式”,反而会把块方向尺寸也纳入约束。另一个常见误区是只写了 container-name,却没有建立尺寸容器,之后的宽度条件自然无法生效。

容器查询是增强层,默认样式应先能读。对仍需兼容旧环境的项目,可以用 @supports 把增强规则包起来,并保留一个基于视口的粗粒度回退。回退不可能知道卡片真正所在的列宽,但至少能避免所有内容挤在一个不可读的状态。
.post-card {
/* 基础样式不依赖容器查询,旧环境也能渲染单列。 */
display: grid;
grid-template-columns: 1fr;
}
@supports (container-type: inline-size) {
.card-list {
/* 支持容器查询时,组件改用自身容器作为判断依据。 */
container-type: inline-size;
}
@container (width >= 42rem) {
.post-card {
grid-template-columns: 12rem 1fr;
}
}
}
@supports not (container-type: inline-size) {
@media (min-width: 42rem) {
.post-card {
/* 这是视口级近似回退,不要把它当成容器条件。 */
grid-template-columns: 12rem 1fr;
}
}
}
验收时不要只拖动浏览器窗口。先让页面保持宽屏,再把卡片放进窄侧栏;如果它仍按视口切换,说明查询上下文没有落在正确祖先上。再检查命名容器是否与 @container card-list 完全一致,拼写差异会让规则看起来像“没生效”。
页面整体布局、打印和设备级策略仍适合媒体查询;可复用组件需要根据所在列宽变化时,优先使用容器查询。两者可以同时存在,职责不要混在同一条规则里。
先检查祖先是否设置了 container-type 或 container,再检查查询条件是否选中了正确的命名容器。只有 container-name 没有尺寸类型时,宽度查询不会得到预期结果。
不必。rem 更适合跟随根字体大小的布局阈值;重要的是阈值来自组件内容真正需要的空间,而不是照搬某个设备宽度。
容器查询的落点可以概括成一句话:先让组件拥有明确的查询容器,再把布局阈值写在 @container 条件里。这样同一份卡片 CSS 才能在主栏、侧栏和弹窗中保持一致的自适应边界。