容器查询比媒体查询更合适折叠屏，因其能响应单个容器尺寸变化而非仅视口；需显式设置container-type和container-name，推荐inline-size；@container语法类似@media但作用域受限，须避免嵌套过深及与@media混用。
容器查询（Container Queries）在折叠屏上为什么比媒体查询更合适
因为折叠屏设备存在同一页面内多个可变尺寸区域（比如展开时左侧导航栏收缩、右侧内容区拉伸），而 @media 只能监听视口（viewport）变化，无法感知某个 div 自身尺寸的改变。容器查询让组件“自己看自己”，更适合折叠屏中局部区域的响应式行为。
典型场景：折叠态下显示精简卡片，展开后自动切换为带图标的宽卡片 —— 这个切换应由卡片容器宽度触发，而非整个屏幕宽度。
启用容器查询前必须设置容器查询上下文
浏览器不会默认把任意元素当作可查询容器。必须显式声明 container-type（以及可选的 container-name）才能启用查询能力。
-
container-type: inline-size是最常用选项，表示按容器的行内方向（通常是宽度）做查询；size和block-size目前支持度低，不建议在折叠屏项目中使用 - 必须给目标容器加一个
container-name（如container: card / inline-size），否则@container规则无法匹配到它 - 父容器需有明确尺寸（比如设置了
width、max-width，或处于 Flex/Grid 子项中且尺寸受约束），否则查询可能始终不触发
@container 规则写法和常见失效原因
@container 语法和 @media 类似，但作用域限定在已声明容器查询上下文的祖先元素内。容易出错的地方集中在选择器范围和单位处理上：
立即学习“前端免费学习笔记（深入）”；
- 查询条件里只能用
width、inline-size（推荐），不能用min-width或max-width—— 正确写法是@container card (min-width: 320px) - 不要在
@container外层再套@media做“双重保险”，这反而会破坏容器查询的独立性；折叠屏适配应优先靠容器本身尺寸驱动 - 如果卡片组件被 Vue/React 动态挂载，确保
container属性在元素渲染完成时已存在（避免 JS 插入后才加样式导致首次不生效） - Chrome 110+、Edge 110+、Safari 16.4+ 支持，Firefox 尚未支持；线上项目务必加降级方案（例如 fallback 到
@media (min-width: ...)）
@container card (min-width: 320px) {
.card-content {
display: grid;
grid-template-columns: 1fr max-content;
}
}
@container card (min-width: 480px) {
.card-icon {
display: block;
}
}
折叠屏真实布局中如何组织容器层级
折叠屏 UI 常见“双栏变单栏”结构，但直接对根容器做查询往往不够精细。真正有效的做法是让每个功能区块自包含查询逻辑：
- 导航区域设为
container: nav / inline-size，内部用@container nav (max-width: 360px)隐藏二级菜单 - 主内容区设为
container: main-content / inline-size，根据自身宽度切换网格列数或图文比例 - 避免跨多层嵌套查询（比如容器 A 包含 B 包含 C，只在 C 上写
@container），Chrome 对深度嵌套的容器查询性能较敏感，折叠屏动画期间易掉帧 - 若使用 CSS-in-JS（如 Emotion），注意部分库默认不透传
container属性，需手动通过style或className注入
容器查询不是银弹 —— 折叠屏的 hinge 区域遮挡、横竖屏切换时的 layout shift、以及系统级“应用连续性”（App Continuity）API 未暴露给 CSS，这些都得靠 JS 辅助判断。容器查询只管“尺寸变了之后怎么画”，不管“为什么变”。
