关键区别在于响应逻辑的判定基准：@media看视口宽度，@container看父容器宽度；需三步生效——声明container-type、可选命名、@container查条件；未声明container-type则全部无效。
Container Queries和媒体查询到底差在哪？
关键区别不在语法，而在“谁决定响应逻辑”。@media看的是视口宽度，@container看的是父容器宽度——这意味着同一个组件，在侧边栏展开/收起、卡片网格列数变化、甚至嵌入不同尺寸的iframe时，能自主适配，不用等全局断点触发。移动端常见场景如仪表盘卡片、弹窗内表格、折叠面板里的图表，用@media硬写断点反而容易冲突或漏判。
怎么写一个真正生效的容器查询？
三步缺一不可：给父容器设container-type、加container-name（可选但推荐）、在子元素里用@container查条件。容易漏掉的是第一步——没声明container-type，后续所有查询都无效。
-
container-type: inline-size最常用，适用于宽度变化驱动的布局调整（如按钮文字换行、图标显隐） -
container-type: size同时监听宽高，适合需要比例控制的组件（如罗盘时钟的刻度环缩放） - 命名不是必须，但加
container-name: card后，可用@container card (min-width: 300px)精准匹配，避免嵌套时误触发
移动端组件里哪些地方该用，哪些不该用？
适合用：卡片内容区、表格容器、模态框主体、图表wrapper——这些区域尺寸由上下文动态决定，且内部结构需随尺寸精简（比如小容器里隐藏次要列、把文字按钮换成图标）。不适合用：全屏导航栏、固定高度页脚、根或——它们尺寸由视口锚定，@container查不到有意义的变化。
性能注意点：container-type会触发浏览器创建新的布局作用域，频繁重排的容器（如带动画的抽屉菜单）要慎用；实测中，Chrome 128+ 和 Safari 17.5+ 支持稳定，Firefox 127 需开启layout.css.container-queries.enabled标志。
兼容性 fallback 怎么写才不翻车？
不能只靠@supports包裹——因为旧浏览器忽略整个@container块，但不会报错，结果是组件卡在默认样式。稳妥做法是先写一套@media基础适配，再用@container覆盖更细粒度场景：
/* 基础兜底：按视口适配 */
.card-content { font-size: 1rem; }
@media (max-width: 480px) {
.card-content { font-size: 0.875rem; }
}
<p>/<em> 容器增强：按实际占用空间微调 </em>/
@container card (max-width: 320px) {
.card-content { font-size: 0.75rem; }
}</p>
真正容易被忽略的是容器尺寸计算时机——它基于渲染后的最终尺寸，如果组件初始display: none或visibility: hidden，容器查询不会生效；务必确保容器至少有一次正常渲染。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
