CSS容器查询实战：用@container打造真正响应式的组件，扔掉视口束缚

一次让我对“响应式”产生怀疑的重构

去年年底，我在一个后台管理系统里做组件库的统一。设计规范要求同一个产品卡片组件要在三个地方复用：主内容区的三列网格里、右侧窄侧边栏的推荐列表里、以及一个全宽弹窗的详情页里。按照多年养成的习惯，我开始写媒体查询：@media (min-width: 768px)下卡片横排显示，小于这个宽度就竖排。结果测试同事很快提了个bug——“为什么在宽屏显示器上，侧边栏里的卡片也是横向排列的？那个侧边栏总共只有280像素宽，卡片横排根本放不下，图片被挤压得只剩一条线了。”

我打开Chrome DevTools一看，确实如此。媒体查询根据的是视口宽度，而侧边栏虽然本身很窄，但整个浏览器窗口宽度超过了768像素，所以卡片依然执行了“宽屏布局”。那一刻我突然意识到，这些年来我们一直在用一个间接的标准——视口大小——来猜测组件的可用空间，而不是直接测量组件所在容器的尺寸。这就好比给你一件衣服，不是量你的身材，而是量你家的门框，大部分时间能对上，但一遇到特殊场景就露馅了。

这个问题困扰了前端很多年，直到CSS容器查询（Container Queries）出现。它允许我们定义一个元素为“容器”，然后根据这个容器自身的宽度、高度甚至内联尺寸来调整内部元素的样式，而不是依赖全局的视口。今年主流浏览器都已经稳定支持了，我觉得是时候把容器查询彻底弄明白并用到生产环境里了。这篇文章就通过一个完整的产品卡片案例，把容器查询从概念到落地全部跑一遍。

容器查询到底是什么，和媒体查询有什么本质区别

一句话概括：媒体查询监听的是视口（整个浏览器窗口）的尺寸，容器查询监听的是某个特定元素容器的尺寸。

语法上，容器查询分两步走。第一步是定义一个“容器上下文”，用container-type属性告诉浏览器：“这个元素是一个容器，请跟踪它的尺寸变化”。常用的值有：

• container-type: inline-size —— 跟踪容器的内联尺寸（对于横向书写模式就是宽度）。
• container-type: size —— 同时跟踪宽度和高度。
• container-type: normal —— 默认值，不创建容器上下文。

同时可以用container-name给容器起个名字，方便查询时指定目标。

第二步是在样式中使用@container规则，写法跟媒体查询类似，但它针对的是最近的祖先容器的尺寸：

@container (min-width: 400px) {
    .card {
        display: flex;
    }
}
            

这条规则的意思是：当卡片元素所在的容器宽度至少为400像素时，应用里面的样式。如果卡片放在一个500像素宽的容器里，就变成横向排列；如果放在一个300像素宽的容器里，就保持默认的纵向排列——不管视口有多宽。

这种“基于组件自身环境”的响应式逻辑，从根本上解决了侧边栏、弹窗、网格列等场景下组件无法自适应的问题。你不再需要为每个使用场景单独写覆盖样式，组件自己就能根据实际可用空间调整形态。

动手实践：从一个基础的产品卡片开始

我们来实现一个典型的产品卡片。卡片内容包括一张图片、产品标题、简短描述、价格和操作按钮。HTML结构如下：

<div class="card-wrapper">
    <div class="product-card">
        <img class="product-image" src="image.jpg" alt="产品图片">
        <div class="product-info">
            <h3 class="product-title">专业版机械键盘</h3>
            <p class="product-desc">Cherry MX轴体，RGB背光，全键无冲</p>
            <div class="product-footer">
                <span class="product-price">¥699</span>
                <button class="buy-btn">加入购物车</button>
            </div>
        </div>
    </div>
</div>
            

注意我用了一个card-wrapper包裹在卡片外面。这个wrapper就是我们即将定义的容器。在实际项目中，这个wrapper可能是一个网格单元格、一个侧边栏的列表项，或者一个弹窗的内容区。把容器定义在包裹层上，可以让卡片内部的样式完全不受外部布局的影响。

定义容器并编写容器查询

首先，把card-wrapper声明为容器，并且为了方便在多个地方使用，给它起个名字：

.card-wrapper {
    container-type: inline-size;
    container-name: card-container;
}
            

现在浏览器会实时监控card-wrapper的宽度变化。接下来我们写卡片的默认样式（窄容器下的竖排布局）：

.product-card {
    border: 1px solid #e0e0e0;
    border-radius: 8px;
    overflow: hidden;
    background: #fff;
}

.product-image {
    width: 100%;
    aspect-ratio: 4 / 3;
    object-fit: cover;
}

.product-info {
    padding: 16px;
}

.product-title {
    font-size: 18px;
    margin: 0 0 8px;
}

.product-desc {
    color: #666;
    font-size: 14px;
    margin: 0 0 12px;
}

.product-footer {
    display: flex;
    justify-content: space-between;
    align-items: center;
}

.product-price {
    font-size: 20px;
    font-weight: bold;
    color: #e53935;
}

.buy-btn {
    padding: 8px 16px;
    background: #6c5ce7;
    color: #fff;
    border: none;
    border-radius: 6px;
    cursor: pointer;
}
            

这是卡片最基础的样式，图片在上、信息在下，适合手机屏幕或侧边栏这类窄容器。

接着写容器查询。当容器宽度超过450像素时，卡片应该变成横向排列——图片在左，信息在右：

@container card-container (min-width: 450px) {
    .product-card {
        display: flex;
        align-items: stretch;
    }

    .product-image {
        width: 40%;
        aspect-ratio: auto;
        object-fit: cover;
    }

    .product-info {
        flex: 1;
        display: flex;
        flex-direction: column;
        justify-content: space-between;
    }
}
            

这几行CSS的价值在于：这个横向布局是否生效，只取决于card-wrapper自身的宽度，与外层布局完全无关。如果把card-wrapper放在一个600像素宽的主内容区，卡片自然就是横向布局；如果把同一个card-wrapper放到一个280像素宽的侧边栏里，它就会退化成纵向布局。你完全不用针对侧边栏单独写样式覆盖，也不需要计算父容器的宽度再动态添加类名。

更进一步：根据容器宽度切换更精细的布局

容器查询的妙处在于你可以定义多个断点，就像媒体查询一样。我们来给卡片增加一个“紧凑模式”——当容器宽度小于350像素时，进一步简化卡片的显示，比如隐藏描述文字和按钮文字，只保留图标。

@container card-container (max-width: 350px) {
    .product-title {
        font-size: 16px;
    }

    .product-desc {
        display: none;
    }

    .buy-btn {
        padding: 6px 12px;
        font-size: 12px;
    }
}
            

这样，同一个卡片组件在三种不同宽度的容器里会呈现完全不同的形态：

• 超过450像素：图片在左，信息在右，完整展示所有内容。
• 350到450像素之间：纵向排列，图片在信息上方，但标题和描述都显示。
• 小于350像素：纵向排列，隐藏描述文字，按钮文字缩小，适合更窄的空间。

所有这些变化都由容器宽度自动触发，组件与使用场景解耦。当你在一个宽度会动态变化的布局（比如拖拽调整侧边栏宽度、或者窗口大小改变导致网格列数变化）中使用这个卡片时，卡片会在各个形态之间平滑切换，用户体验非常流畅。

容器查询与网格布局的配合：实现自适应网格列数

容器查询的另一个强大应用场景是配合CSS Grid，让网格容器内部的元素根据网格列宽自动调整内部布局，但网格本身的列数需要靠外部控制。不过这里有一个更优雅的用法：用auto-fit和minmax让网格自动决定列数，然后网格的单元格作为容器，触发卡片的内部自适应。

假设我们有一个页面，需要展示多个产品卡片。页面的整体布局用Grid，列数不固定，由视口宽度决定：

.product-grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
    gap: 24px;
}
            

这样当视口很宽时，网格可能显示4列甚至5列，每列宽度也就300多像素；当视口变窄，列数减少，每列宽度变大。每个网格单元格就是卡片的容器。由于我们已经在card-wrapper上定义了容器查询，卡片会根据单元格的实际宽度自动切换横排/竖排和紧凑模式。用户调整浏览器窗口大小时，从5列到1列，卡片形态平滑过渡，整个过程不需要任何媒体查询。

这种组合拳让响应式设计的颗粒度从“页面级”细化到了“组件级”。你写的CSS不再是一堆“如果屏幕宽度大于XXX”的条件，而是一堆“如果我的容器宽度大于XXX”的条件。我觉得这才是真正符合组件化思想的样式编写方式。

容器高度查询：垂直方向上的自适应

我们平时更关注宽度自适应，但高度容器查询在特定场景下同样有价值。比如一个固定高度的仪表盘面板，内部需要根据面板高度来决定显示多少行数据。要把容器设置为同时监听宽和高，需要container-type: size，然后就可以写@container (min-height: 400px)这样的查询了。

不过需要注意的是，开启size类型后，容器的高度必须是明确的（比如设置了height或者被flex/grid分配了确定的高度），否则容器高度会是auto，查询可能不按预期工作。一个典型的安全做法是给容器设置height: 100%或具体的像素值。

这里给出一个垂直自适应的例子：假设我们在一个高度有限的面板里显示一组按钮，面板高度足够时就纵向排列按钮，高度不足时就横向排列。先定义容器：

.panel {
    container-type: size;
    height: 100%;
}
            

然后写查询：

@container (min-height: 300px) {
    .button-group {
        flex-direction: column;
    }
}

@container (max-height: 299px) {
    .button-group {
        flex-direction: row;
    }
}
            

这种基于高度的自适应在仪表盘和监控大屏中非常实用，能保证界面在任意尺寸的终端上都有合理的布局。

用命名容器区分多个嵌套容器的作用域

有时候一个组件内部可能有多层容器，你需要精确指定查询的是哪一个容器。这时container-name就派上用场了。不加名字时，@container默认查询最近的一个容器祖先。加了名字后就可以精确指定：

@container card-container (min-width: 500px) {
    /* 样式 */
}
            

如果你有一个外层的大布局容器和一个内层的小组件容器，通过命名可以把样式准确地绑定到目标层级上，避免混淆。

浏览器兼容性和渐进增强策略

容器查询在Chrome 105+、Edge 105+、Safari 16+、Firefox 110+都已经获得稳定支持。考虑到现在的浏览器升级节奏，大部分用户已经覆盖到了。但是为了安全，我们依然可以写一套渐进增强的样式。

做法很简单：先把适合窄容器的布局作为默认样式（也就是我们在移动优先策略中常做的事情），然后在@supports里启用容器查询：

/* 默认样式：适合窄容器 */
.product-card {
    display: block;
}

/* 如果浏览器支持容器查询，应用增强样式 */
@supports (container-type: inline-size) {
    .card-wrapper {
        container-type: inline-size;
        container-name: card-container;
    }

    @container card-container (min-width: 450px) {
        .product-card {
            display: flex;
        }
    }
}
            

这样即使在不支持容器查询的浏览器里，卡片也能以基础样式正常显示，不会出现布局崩溃。随着时间的推移，你甚至可以逐步移除@supports包裹。

在实践中有一个容易被忽略的坑

容器查询不能查询容器自身在样式上的变化。比如你不能在容器查询里改变容器的width属性，因为这会形成一个循环——容器宽度改变触发查询，查询又改变容器宽度，浏览器会直接忽略这样的规则。如果你需要根据容器宽度调整容器自身的布局，应该把查询写在容器的父元素上，或者用别的方式重新组织HTML结构。

另外，容器查询内部的样式权重和普通的CSS规则是一样的，仍然遵循层叠顺序。如果你发现在某个断点下样式没生效，先检查是不是有其他选择器覆盖了它。使用@container不会自动提高优先级。

容器查询带来的思维转变

写完产品卡片这套组件之后，我回头审视项目里以前那些大段大段的媒体查询，发现相当一部分都可以用容器查询替代。那些曾经让我头疼的“侧边栏特殊样式”“弹窗内组件适配”“仪表盘小卡片模式”全部变得顺理成章。组件不需要知道它被放在哪里，只需要知道自己的容器有多大。这种“关注点分离”的程度，是媒体查询时代我一直向往却无法做到的。

如果你还在为同一个组件在不同场景下的样式覆盖写大量额外代码，不妨从今天开始，挑一个组件，用容器查询重构一遍。不用一下子全项目迁移，先感受一下那种“组件自己照顾自己”的清爽感。我想你很快会像我一样，一有机会就想把剩下的媒体查询也一个个换成容器查询。