容器查询（@container）是响应父容器尺寸的独立工具，非媒体查询升级版；需显式设置container-type: inline-size、父容器有可计算宽度，且不与display: contents等冲突。
容器查询（@container）不是媒体查询的升级版，而是解决完全不同问题的工具——它让组件能响应自身父容器尺寸，而不是整个视口。如果你还在用 @media 控制卡片、列表、表单等可复用组件的内部布局，那大概率已经写出了耦合高、难维护、折叠屏下直接失效的样式。
为什么 @container 规则不生效？常见配置漏项
浏览器默认不把任何元素当容器，@container 规则静默失效是常态，且控制台不会报错。必须显式开启容器上下文：
-
container-type: inline-size是最常用且兼容性最好的选项；漏掉这行，@container完全不触发 - 不要对
display: contents或position: absolute的父元素设container-type——它们不产生块格式化上下文，属性会被忽略 -
container-name是可选的，但命名后能提升选择器精度；Safari 16.4 对命名容器有解析 bug，线上项目建议优先用匿名写法：container: / inline-size - 父容器需有**可计算的尺寸**：比如设置了
width、max-width，或处于 Flex/Grid 子项中且受约束；纯height: auto+width: auto的 div 不会触发查询
@container 和 @media 混用时职责怎么划清？
二者不是替代关系，而是分层协作。混用没问题，但职责错位会导致逻辑混乱甚至样式冲突：
-
@media管全局：比如控制仪表盘整体列数（grid-template-columns: repeat(4, 1fr)→repeat(2, 1fr)），或折叠屏整页导航栏切换 -
@container管组件：比如卡片内图文排布方向、列表项图标是否显示、表单控件堆叠/并排 - 避免“双重保险”式嵌套：比如在
@media (min-width: 768px)里再写@container (min-width: 400px)——这会让组件失去独立性，且 Safari 下可能因解析顺序出问题 - 嵌套容器只响应**直接父级**：
.card的@container只看.card-container尺寸，不穿透到更外层；若需跨级响应，得逐层加container-type
折叠屏和微前端场景下，@container 的实际优势在哪？
折叠屏的典型问题是：同一页面存在多个动态尺寸区域（如展开时左侧导航收缩、右侧内容区拉伸），而 @media 只监听视口变化，完全无法感知局部容器缩放。这时候 @container 才是真解：
立即学习“前端免费学习笔记（深入）”；
- 卡片组件放在侧边栏（宽仅 300px）时，
@media (min-width: 768px)仍按桌面态渲染，文字溢出；而@container (min-width: 400px)能精准触发垂直排布 - 微前端子应用注入到主框架某区块时，其内部组件无需知道主应用的断点规则，只要父容器声明了
container-type，就能自适应 - SSR 或静态生成时，
@container在首次渲染阶段无尺寸信息，依赖 hydration 后 JS 注入才生效；关键路径上别只靠它撑布局，比如首屏标题字号不能只由容器宽度决定 - Firefox 目前（2026年5月）仍未原生支持
@container，Chrome 110+、Edge 110+、Safari 16.4+ 已支持；降级方案优先用@supports not (@container)+@mediafallback，而非 JS ResizeObserver —— 多数展示型组件 fallback 到固定布局更稳
真正容易被忽略的点是：容器查询不是“写了就自动适配”，它依赖父容器的尺寸可测量性。很多失败案例其实卡在父容器本身没约束宽度，或者用了 display: contents 这类破坏 BFC 的属性。先确保容器能“被量出来”，再谈查询逻辑。
