CSS 容器查询允许开发者根据父容器的实际尺寸来调整子元素的样式，而不是像传统媒体查询那样只能基于浏览器视口宽度做判断。这个能力对组件化开发尤其重要，因为同一个组件可能被复用在页面中不同宽度的区域里。通过 CDN 引入容器查询的 polyfill 或直接托管样式文件，可以让这项特性更快地落地到现有项目中，同时减少构建配置的复杂度。
容器查询与媒体查询的核心差异
媒体查询通过检测视口宽度来触发不同样式，这在页面整体布局设计时很有效，但当我们需要单独调整某个组件内部结构时就会显得力不从心。例如一个侧边栏组件在宽屏主内容区中应该展示为横向排列的卡片，而被放到窄小的侧边栏后则需要变成纵向堆叠，但媒体查询无法知道组件所在容器的宽度，只能依赖全局断点，这往往导致需要维护大量冗余的类名或嵌套查询。
容器查询直接以最近的具有容器上下文的祖先元素作为参考。在使用前，需要给目标容器声明 container-type: inline-size，这样浏览器就会跟踪该容器的内联尺寸变化，并允许在 @container 规则中针对该容器编写条件样式。与媒体查询相比，容器查询的断点属于局部作用域，不会影响页面其他部分，这极大提升了组件的可复用性。
来看一个简单的语法对比。传统媒体查询控制卡片布局时，断点写死为视口宽度；而容器查询可以针对卡片父容器定义规则，比如当容器宽度小于400px时切换为单列布局。
/* 传统媒体查询 */
@media (max-width: 700px) {
.card-list {
grid-template-columns: 1fr;
}
}
/* 容器查询 */
.card-list-container {
container-type: inline-size;
}
@container (max-width: 400px) {
.card-list {
grid-template-columns: 1fr;
}
}
上面的代码展示了与媒体查询相比，容器查询只需要在容器上设置一个声明，之后所有 @container 规则都会参照该容器的宽度。对于嵌套在不同布局中的组件，这种写法省去了反复计算全局断点的麻烦。
通过CDN引入容器查询兼容方案
现代浏览器已原生支持容器查询，但仍有部分旧版本浏览器无法识别 container-type 和 @container 语法。为了兼容这些环境，可以引入社区提供的 polyfill。比较常用的方式是使用 container-query-polyfill，它能模拟容器查询的主要行为。通过 CDN 加载这个 polyfill 非常简单，只需要在 HTML 中按顺序加入脚本即可。
CDN 的优势在于资源会被缓存到离用户更近的节点，加载速度更快，而且不需要在本地项目中维护额外的依赖文件。当然，如果只是把普通 CSS 文件托管到 CDN，也可以直接通过 <link> 标签引用，容器查询的样式会随文件一起加载。需要注意的是，polyfill 需要放在样式表之后运行，这样才能正确解析已有的 CSS 规则。
下面是一个通过 jsDelivr 引入 polyfill 的示例。示例中的 script 标签需要放在 body 结束前，并且要等到 DOM 加载完成后再初始化。
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>容器查询兼容示例</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<div class="card-list-container">
<div class="card-list">
<div class="card">卡片一</div>
<div class="card">卡片二</div>
<div class="card">卡片三</div>
</div>
</div>
<script src="https://cdn.jsdelivr.net/npm/container-query-polyfill@1.0.2/dist/container-query-polyfill.min.js"></script>
<script>
if (window.containerQueryPolyfill) {
containerQueryPolyfill();
}
</script>
</body>
</html>
除了 jsDelivr，也可以使用 unpkg 等公共 CDN，只需替换对应的 URL 即可。加载完成后，polyfill 会扫描页面中的样式表，识别容器查询规则并将其转换为基于 ResizeObserver 的 JavaScript 实现，这样旧浏览器也能获得类似原生容器查询的效果。不过要注意，polyfill 会增加一定的运行时开销，所以只在需要兼容的浏览器中按需加载会更合理。
编写一个完整的容器查询组件
假设要开发一个文章卡片组件，它可能出现在主内容区宽容器中，也可能出现在右侧窄边栏里。我们希望当容器宽度足够时，卡片内图片与文字横向排列；当容器宽度变窄时，自动改为上下排列。使用容器查询可以轻松实现，而无需为不同区域额外编写样式覆盖。
首先给包裹卡片的父容器声明 container-type: inline-size，然后在 @container 规则中根据容器宽度调整内部布局。这里以 500px 作为断点：大于 500px 时使用网格两列布局，小于等于 500px 时切换为单列。
.article-card-wrapper {
container-type: inline-size;
container-name: article-card;
}
.article-card {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
@container article-card (min-width: 500px) {
.article-card {
grid-template-columns: 200px 1fr;
align-items: center;
}
}
配合对应的 HTML 结构，这个组件就能在不同容器中自动切换布局。值得注意的是，container-name 可以为容器命名，方便在多个容器上下文中精确控制规则作用范围。如果页面中存在多个嵌套的容器查询，使用命名可以避免样式冲突。
下面再给出一个基于字体大小的容器查询示例，展示如何根据容器宽度调整标题字号。这种用法在仪表盘或数据卡片中非常实用，可以保证文字在狭小空间内仍然清晰可读。
.metric-box {
container-type: inline-size;
}
.metric-title {
font-size: 18px;
}
@container (max-width: 300px) {
.metric-title {
font-size: 14px;
}
}
这两个示例展示了容器查询在组件内部布局和排版上的灵活性。与媒体查询相比，开发者不再需要关心组件具体被放置在页面的哪个位置，只需要定义好容器自身的断点逻辑。
性能影响与使用建议
容器查询虽然方便，但引入额外的容器跟踪会带来一定的布局计算成本。每当容器尺寸发生变化，浏览器就需要重新评估匹配的 @container 规则并更新样式。如果大量容器都开启 container-type，性能敏感页面可能会出现卡顿。因此建议只对真正需要响应式行为的容器设置该属性，避免贪图方便对所有盒子开启。
在实际项目中，可以结合 @supports 规则检测当前浏览器是否原生支持容器查询，从而为不支持的环境提供降级方案。例如，先编写一套基于媒体查询的兜底样式，再在支持容器查询的浏览器中覆盖为更精细的局部响应式规则。这种渐进增强策略能兼顾兼容性和用户体验。
此外，容器查询与媒体查询并不是互斥关系。页面整体布局依旧适合使用媒体查询，比如顶部导航的折叠、全局栅格系统的断点；而组件内部布局则适合交给容器查询。两者配合可以显著减少样式代码的复杂度，提升维护效率。
对于通过 CDN 引入 polyfill 的方案，还需要注意 CDN 的可用性和版本锁定。建议在生产环境中固定具体版本号，避免使用 latest 等浮动标签，以防 polyfill 更新后引入不兼容的变更。同时可以为 polyfill 设置异步加载或延迟加载，避免阻塞首屏渲染。