@container 解决组件在不同容器中的自适应问题，它依据父容器宽度而非视口宽度触发样式变化，需显式声明 container-type 且容器宽度必须可计算，与 @media 分层协作而非替代。
容器查询不是“升级版媒体查询”，它解决的是完全不同的问题：@media 回答“屏幕多宽”，@container 回答“这个卡片所在的盒子多宽”。在组件复用、折叠屏、微前端等场景下，后者才是真解。
为什么 @container 能让组件真正“自适应”
媒体查询对组件所在容器一无所知。同一个 .card 放在 300px 宽的侧边栏和 900px 宽的主区，只要视口是 1440px，@media (min-width: 768px) 就统一生效——结果是侧边栏里的卡片文字溢出、图标错位。
@container 则只看直接父容器尺寸：@container (min-width: 400px) 在窄容器里不触发，在宽容器里才生效，组件表现始终贴合实际生存环境。
- 组件无需暴露额外 class 或依赖 JS 判断容器宽度
- 同一份 CSS 可在不同布局中复用，不需为每个嵌入位置写定制逻辑
- 折叠屏展开时，侧边栏容器仍保持窄宽，卡片自动维持紧凑态，不会被视口跳变“误判”
@container 生效的前提比 @media 严格得多
漏掉 container-type: inline-size，整个 @container 规则静默失效，控制台不报错、DevTools 里也看不出异样——这是最常卡住人的地方。
必须同时满足三个条件：
- 目标元素显式声明
container-type: inline-size（或简写container: card / inline-size） - 该元素有可计算的宽度（如设置了
width、max-width，或在 Flex/Grid 中受约束） - 不能设在
display: contents、position: absolute或float的父元素上（它们不产生块格式化上下文）
用 DevTools 的 Computed 面板查 container-type 和真实 width 值，是最直接的验证方式。
和 @media 混用时职责必须划清
二者不是替代关系，而是分层协作：@media 控制全局节奏（比如整页列数、导航栏折叠），@container 控制组件内部细节（比如卡片内图文方向、表单项是否并排）。
常见反模式：
- 在
@media块里再套@container—— Safari 下可能因解析顺序失效，且破坏组件独立性 - 给
body或main加container-type试图“全局启用”——这些元素往往没明确宽度，计算值为 0，查询永不触发 - 用
@container控制导航栏折叠——它依赖父容器宽度，而导航栏通常撑满视口，此时不如@media稳定
真正难的不是写法，而是让容器尺寸“稳得住”
语法很简单，但实际落地时，最大的坑在于容器宽度不可控：
- Flex 子项被
min-width: 0压缩后宽度骤降，导致断点反复触发 - Grid 列宽用
1fr动态分配，浏览器无法稳定计算 inline-size - JS 动态插入内容后未触发 resize，容器尺寸未更新，查询条件迟迟不匹配
调试时建议临时加 outline: 1px solid red，Chrome Layout 面板会显示 “Container” 标签，确认是否真被识别——别靠猜，要亲眼看到容器被激活。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
