Container Queries不是媒体查询替代品，而是解决组件级响应式的正确工具；它要求显式声明container-type: inline-size才能激活查询能力，否则@container规则静默失效，且仅作用于直接父容器内后代元素。
Container Queries 不是媒体查询的替代品，而是解决“组件内部响应”问题的正确工具——它让组件能根据自身容器宽度而非整个视口宽度来调整样式。
为什么 @container 规则必须配合 container-type 才生效
浏览器不会自动把任意元素当作容器；必须显式声明 container-type: inline-size（或 size）才能启用查询能力。漏掉这一步，@container 规则会被完全忽略，控制台也不会报错，极易误判为语法写错。
-
container-type: inline-size是最常用类型，仅基于容器的内联方向（通常是宽度）触发查询 -
container-type: size同时监听宽高变化，但开销更大，且需容器有明确尺寸（如设置了width或inline-size） - 容器元素不能是
display: inline，否则container-type无效——推荐用display: flow-root或block
如何写一个真正可复用的卡片组件（带 @container）
关键不是“适配屏幕”，而是让同一张卡片在窄栏、宽栏、侧边栏里自动切换布局。下面这个例子中，.card 自身就是容器，内部子元素直接响应它的宽度：
/* 卡片容器 */
.card {
container-type: inline-size;
}
<p>/<em> 默认：紧凑单列 </em>/
.card h3 { font-size: 1rem; }
.card .meta { display: none; }</p><p>/<em> 容器 ≥ 400px 时显示元信息 </em>/
@container (min-width: 400px) {
.card h3 { font-size: 1.25rem; }
.card .meta { display: block; }
}</p><p>/<em> ≥ 600px 时改为横向布局 </em>/
@container (min-width: 600px) {
.card { display: flex; gap: 1rem; }
.card img { width: 80px; height: 80px; flex-shrink: 0; }
}注意：@container 里的选择器必须作用于容器内部元素（不能选容器本身），且规则作用域仅限该容器后代——这是和媒体查询本质区别。
立即学习“前端免费学习笔记（深入）”；
常见失效场景与调试方法
如果 @container 没反应，先检查三件事：
- 目标容器是否设置了
container-type？用 DevTools 的 Layout 面板看 “Container query” 是否被标记为 active - 容器是否有确定的尺寸？若父级是
display: flex且未设flex-basis或width，容器宽度可能为 0 —— 加min-width: 0或flex: 1通常能修复 - 是否误用了
@media语法？@container (width >= 400px)是错的，正确写法是@container (min-width: 400px)（只支持min-width/max-width/width等有限条件）
和 @media 混用时的优先级与边界
两者互不干扰，但逻辑上要分清职责：@media 控制页面级结构（比如网格列数），@container 控制组件级细节（比如按钮图标是否显示文字）。混用时注意：
- 同一元素同时匹配
@media和@container规则时，后者优先级更高（因为更具体） - 不要试图用
@container替代断点布局——它无法改变父容器的grid-template-columns，只能影响自身后代 - 嵌套容器要注意层级：内层容器的查询范围仅限其直接父容器，不继承外层容器尺寸
真正难的不是语法，是判断“这个响应逻辑到底该由谁决定”——容器查询的价值，只在组件脱离上下文仍需自洽时才不可替代。
