CSS容器查询实战：打造不依赖视口的自适应卡片组件

一、媒体查询的局限与容器查询的诞生

过去十年我们一直在用媒体查询做响应式。它的逻辑是“根据视口宽度改变样式”。但问题在于，一个页面里组件的宽度往往并不等于视口宽度。比如一个文章卡片，放在三栏布局的中间栏和放在侧边栏，宽度完全不同，但它们所处的视口可能是同一个。

所以就会出现这样的尴尬场景：为了让卡片在侧边栏里好看，我们写了@media (max-width: 320px) 的样式，结果在小屏手机上主内容区的卡片也变成了紧凑样式——这并不是我们想要的，因为主内容区在小屏手机上还有360px宽，完全可以展示更多信息。

CSS容器查询解决的就是这个问题。它允许我们根据父容器的实际尺寸，而不是视口尺寸，来改变子元素的样式。这意味着组件可以真正变得“自包含”：无论被放在页面的什么位置，只要容器的宽度变化，组件就会自动调整自身布局，就像是一个独立的小型响应式系统。

二、先跑通基本语法，然后把术语搞明白

在动手写案例之前，先把几个关键点理清，不然容易写错。

2.1 定义一个“查询容器”

不是任意一个元素都能成为容器查询的参照物。你需要显式地声明：

/* 给父容器加一个 container-type */
.article-card-wrapper {
    container-type: inline-size;
    /* 也可以同时给容器起个名字，方便后面引用 */
    container-name: card-container;
}

/* 简写形式 */
.article-card-wrapper {
    container: card-container / inline-size;
}

这里的inline-size意思是我们关心容器在行内方向（通常是宽度）的尺寸。另一个可选值是size，它同时监测块级方向（高度）和行内方向，但目前使用场景比较少，而且启用后容器必须明确设置高度，否则可能会塌陷。所以90%的场景用inline-size就行。

2.2 编写容器查询 —— @container

有了容器，就可以在内部元素的样式中使用@container规则了：

/* 引用具体的容器名称 */
@container card-container (min-width: 500px) {
    .card {
        display: flex;
        flex-direction: row;
    }
    .card__thumbnail {
        width: 200px;
    }
}

/* 如果不关心具体是哪个容器，也可以不写名称，匹配最近祖先查询容器 */
@container (max-width: 350px) {
    .card__description {
        display: none;
    }
}

它的语法和媒体查询非常像，只不过@media变成了@container，并且可以加上容器名称来精确指定参照物。这种命名容器的方式在页面中有多个相互嵌套的查询容器时特别有用——你可以让里层的容器查询只响应自己对应的那层容器尺寸，而不会被外层干扰。

三、实战：评论卡片组件的完整设计

现在来真的。我们要做一个评论卡片组件，它会在以下几种场景中使用：

• 窄容器（宽度小于360px）：头像在上方，信息垂直排列，隐藏摘要文字。
• 中等容器（360px ~ 600px）：头像在左侧，右侧是主要内容，显示摘要但字体较小。
• 宽容器（大于600px）：左右布局，同时显示更多元信息（如点赞数、时间戳、标签），并启用较大的标题字号。

在传统媒体查询时代，这三个布局需要通过不同的类名或者难以维护的嵌套选择器实现。现在用容器查询，一套代码全部搞定。

3.1 HTML骨架

<div class="comment-card-wrapper">
    <article class="comment-card">
        <div class="comment-card__avatar">
            <img src="avatar.jpg" alt="用户头像">
        </div>
        <div class="comment-card__body">
            <div class="comment-card__header">
                <h3 class="comment-card__name">李寻欢</h3>
                <span class="comment-card__badge">作者</span>
                <time class="comment-card__time">2小时前</time>
            </div>
            <p class="comment-card__summary">
                这篇文章把Flexbox和Grid的边界讲得很清楚，尤其是关于隐式网格的那部分...
            </p>
            <div class="comment-card__meta">
                <span>👍 23</span>
                <span>💬 回复</span>
            </div>
        </div>
    </article>
</div>

结构很平淡，一个包裹容器comment-card-wrapper，里面是卡片本身。注意我们把包裹容器声明为查询容器，这样卡片组件就可以响应wrapper的宽度变化了。

3.2 基础样式与容器定义

先写组件的默认样式（适用于最窄的场景），然后把容器声明加在wrapper上：

/* 查询容器声明 */
.comment-card-wrapper {
    container: comment-container / inline-size;
    /* 下面只是为了示例美观加的，与容器查询无关 */
    max-width: 100%;
    margin: 0 auto;
}

/* 卡片内部基础样式 —— 默认为窄容器布局 */
.comment-card {
    display: flex;
    flex-direction: column;      /* 垂直排列 */
    gap: 12px;
    padding: 16px;
    background: #ffffff;
    border: 1px solid #eaeaea;
    border-radius: 12px;
}

.comment-card__avatar img {
    width: 40px;
    height: 40px;
    border-radius: 50%;
    display: block;
}

.comment-card__name {
    font-size: 1rem;
    margin: 0;
    font-weight: 600;
}

.comment-card__badge {
    font-size: 0.7rem;
    background: #f0f0f0;
    padding: 2px 6px;
    border-radius: 4px;
    color: #555;
}

.comment-card__time {
    font-size: 0.8rem;
    color: #888;
}

.comment-card__summary {
    display: none;  /* 窄容器下默认隐藏摘要 */
    font-size: 0.9rem;
    color: #444;
    margin: 0;
}

.comment-card__meta {
    display: flex;
    gap: 12px;
    font-size: 0.8rem;
    color: #666;
}

你会发现基础样式完全没有用到任何查询，就是常规CSS。这很重要——容器查询是增强，不是替代，组件在未匹配任何查询时应当有一个合理的默认外观。

3.3 中等容器：大于360px时

当wrapper的宽度超过360px，我们切换到水平布局，并显示摘要文字：

@container comment-container (min-width: 360px) {
    .comment-card {
        flex-direction: row;        /* 变为水平 */
        align-items: flex-start;
    }

    .comment-card__avatar img {
        width: 48px;
        height: 48px;
    }

    .comment-card__summary {
        display: block;            /* 显示摘要 */
        margin-top: 8px;
    }

    .comment-card__header {
        display: flex;
        align-items: center;
        gap: 8px;
        flex-wrap: wrap;
    }
}

这里我没有直接设置comment-card__body的样式，因为弹性布局下它会自动占据剩余空间。一个细节：在中等容器下头像稍微大了一点，但远不如宽容器下那么大——这就是容器查询带来的细腻控制。

3.4 宽容器：大于600px时

进一步扩展布局，让元数据更丰富，标题字号更大，同时头像继续增大：

@container comment-container (min-width: 600px) {
    .comment-card {
        gap: 20px;
        padding: 24px;
    }

    .comment-card__avatar img {
        width: 64px;
        height: 64px;
    }

    .comment-card__name {
        font-size: 1.3rem;
    }

    .comment-card__summary {
        font-size: 1rem;
        line-height: 1.6;
    }

    /* 宽容器下显示额外的统计信息（假设HTML里有对应的元素，可以按需显示） */
    .comment-card__meta {
        justify-content: flex-start;
        gap: 20px;
        font-size: 0.95rem;
        margin-top: 10px;
    }
}

完整的三段式自适应就这么搞定了。你可以试着把.comment-card-wrapper放到一个宽度可拖拽的容器里（比如放在一个设置了resize: both; overflow: auto;的div中），实时拉拽感受一下效果。卡片会在不同断点处丝滑切换布局，而且完全不关心视口是啥尺寸。

四、容器查询单位：让组件内部尺寸也联动起来

除了@container规则，CSS还推出了几个与查询容器配套的单位，比如cqw（容器宽度的1%）、cqh（容器高度的1%）、cqi（容器行内尺寸的1%）、cqb（容器块级尺寸的1%）。这些单位让子元素的尺寸可以直接按比例跟随容器大小变化，不用写一堆查询断点。

举个例子：我想让卡片标题的字体大小在容器宽度300px到800px之间有个流畅的缩放，可以这样写：

.comment-card__name {
    /* 基于容器宽度的动态字号 */
    font-size: clamp(0.9rem, 5cqi, 1.5rem);
}
/* 需要先确保该元素处于一个查询容器内部，否则cqi单位不会生效 */

这里的5cqi意思是容器行内尺寸的5%。当容器宽度为600px时，5cqi = 30px，配合clamp()函数就能实现平滑缩放。我在一个数据仪表盘项目里用过这个技巧，某些卡片里的环形图半径直接用cqw单位设置，拉伸容器时图表完美自适应，视觉效果非常顺滑。

不过有个小坑得注意：容器查询单位必须在已经定义为查询容器的后代元素中使用，否则它们会退回到根元素（视口），导致行为不符合预期。如果你发现cqw没效果，第一时间检查祖先元素有没有声明container-type。

五、嵌套容器查询：当卡片里还有轮播图的时候

现实中的组件往往不是扁平的。比如上面那个评论卡片，如果它的正文里嵌入了一个“推荐阅读”子卡片，而子卡片也希望根据自己所在的容器（也就是评论卡片的正文区域）宽度来自适应，该怎么办？

这就是嵌套容器查询的用武之地。我们可以在内部子组件的外层再声明一个查询容器：

<div class="comment-card__body">  <!-- 这个元素也可以声明为容器 -->
    <div class="recommend-card-wrapper" style="container: recommend-container / inline-size;">
        <article class="recommend-card">
            ...
        </article>
    </div>
</div>

然后在子卡片内部使用：

@container recommend-container (max-width: 280px) {
    .recommend-card {
        flex-direction: column;
    }
}

注意外层查询内层查询互不干扰，因为指定了不同的容器名称。如果没有命名容器，@container会匹配最近的祖先查询容器。所以我的建议是永远给容器命名——你永远不知道这个组件以后会被谁嵌套在什么样的布局里。名字清晰，逻辑就清晰。

六、兼容性与渐进增强策略

截至2024年中，容器查询的浏览器支持已经相当不错：Chrome 105+、Edge 105+、Safari 16+、Firefox 110+ 都完整支持。全球覆盖率超过93%。对于我们的后台管理系统来说，完全可以直接使用。

但如果你需要兼容一些老旧的浏览器，也很简单——容器查询不支持的浏览器会直接忽略@container规则和容器单位，退回到组件的基础样式。而我们刚才写的默认样式（窄容器垂直布局）其实在大多数场景下也是可用的，只是没那么精致。

所以实际上不需要做任何额外的polyfill或回退脚本，CSS的容错机制已经帮你处理了。这个“渐进增强”的思路在团队推广新特性时非常舒服——即便用户浏览器不支持，功能也不受影响。

七、个人在实践中踩到的两个坑

第一个坑：忘记了容器需要明确的尺寸上下文。 如果你把查询容器放在一个flex或grid子项上，而它本身没有设置宽度（比如flex: 1），容器查询依然会生效，因为浏览器会根据弹性布局计算出它的实际宽度。但有一种情况会失效：容器自身的宽度依赖于子元素内容撑开、且父级没有设置任何宽高约束时，容器查询可能拿到0值。解决办法很简单——给容器加一个width: 100%或max-width，让它有一个明确的尺寸计算基准。

第二个坑：容器查询不能用于容器本身。 你不能在一个查询容器内写@container (min-width: 500px)去改变这个容器自己的样式，因为这会造成循环依赖。容器查询只能影响容器内部的后代元素。如果你确实需要根据容器尺寸改变容器自身的边框或背景，可以把样式写在一个内部的装饰元素上，或者用:has()选择器配合其他技巧间接实现（但这个话题就超出了本文范围了）。

八、是不是可以完全抛弃媒体查询了？

我个人目前的结论是：媒体查询仍然有用，但角色变了。 现在媒体查询更适合处理页面级别的宏观布局（比如整体是两栏还是三栏、导航栏是否折叠），而容器查询负责组件内部的微观自适应。这两个东西并不冲突，而是各司其职。

比如在一个后台框架里，我用媒体查询决定侧边栏是展开还是缩成图标；而侧边栏里放置的每一个小组件（日历、待办列表、最近评论）全部用容器查询控制自身显示。这种搭配让代码职责非常清晰，维护成本直线下降。

九、小结

CSS容器查询终于把我们喊了多年的“组件级响应式”变成了现实。它最核心的价值在于：组件的样式完全由它的容器决定，而与页面视口解耦。 这意味着一个组件可以被任意复用，放到任何页面、任何布局位置，都能自动调整到最佳状态。

我推荐的入门路径就是先拿一个已有的简单组件（比如按钮组、头像卡片）改造成容器查询版本，熟悉container-type、@container和容器查询单位，然后再逐步应用到复杂组件上。在这过程中你会发现，原本需要用一堆class切换或者复杂JavaScript监听来实现的效果，现在几行CSS就干净利落地解决了，那种爽感，写过的都懂。