Container Queries是组件级响应式方案，需容器设container-type并建立BFC，折叠屏下须动态viewport、防尺寸跳变、避免flex/grid子项直接查询。
Container Queries不是媒体查询的替代品，而是组件级响应式方案
用 @container 做适配，核心是「容器有尺寸、元素能感知」——这和 @media 完全不同。折叠屏设备（如 Galaxy Z Fold、Pixel Fold）展开后宽度突变，但页面里某个卡片组件可能仍卡在窄列布局里，@media 拿不到这个局部上下文，这时候必须靠容器查询。
常见错误现象：@container 写了但完全不触发，控制台也没报错；或者只在刷新时生效，折叠/展开屏幕没反应。
- 必须给容器设
container-type: inline-size（或size），不能只写container-name - 容器需有明确的块级格式化上下文（BFC），常见手段：加
display: flow-root、float、overflow: hidden或contain: layout - 折叠屏下，某些浏览器（如旧版 Chrome）对
inline-size容器的尺寸更新有延迟，建议搭配resize: horizontal强制监听
折叠屏双态切换时，容器尺寸可能跳变，要防“断层”响应
展开瞬间，一个网格项从 360px 突然变成 680px，如果只写 @container (min-width: 500px)，中间 360→500 这段就永远进不去，UI 卡在窄态。这不是 bug，是设计使然——容器查询只看当前尺寸，不插值、不过渡。
- 用区间写法更稳妥：
@container (min-width: 320px) and (max-width: 480px)、@container (min-width: 481px) - 避免依赖单一阈值，比如不要只靠
768px切换两栏，折叠屏展开后常是 672px 或 720px，得实测设备报告的screen.width和容器实际渲染宽 - 可配合
container-name给不同区域命名（如card-container、sidebar-container），避免全局尺寸干扰
Chrome 110+ 支持原生 Container Queries，但折叠屏需额外处理 viewport
很多折叠屏默认把 viewport 设为折叠态宽度（如 320px），即使展开也不自动更新，导致容器尺寸计算基准错误。这不是 CSS 问题，是 meta 标签没跟上物理屏幕变化。
立即学习“前端免费学习笔记（深入）”；
- 必须加动态 viewport：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">，且不能硬编码width=320 - 部分 Android 折叠屏系统 WebView 对
container-query支持滞后，可用@supports (container-type: inline-size)做降级 - 测试时别只看 DevTools 的 device toolbar —— 它模拟的是 viewport 变化，不是真实容器重排，真机调试不可省
别在 flex 或 grid 子项上直接写 container 查询
Flex item 和 grid item 默认不建立 BFC，即使设了 container-type，浏览器也无视。这是最隐蔽的失效原因，错误现象是样式完全不应用，控制台零提示。
- 给子项加
contain: layout style paint或display: flow-root才能激活容器查询能力 - 若父容器已是
display: grid，推荐把查询逻辑上提一层，写在 grid 容器本身（它天然满足 BFC 条件） - 折叠屏下频繁切换 flex 方向（
flex-direction: column → row）时，容器尺寸重算可能延迟，可加will-change: width提示渲染引擎
折叠屏的「宽度」不是静态值，它随展开角度、多任务窗格、系统手势栏状态实时变动。容器查询真正起效的前提，是你已经让那个 DOM 节点「稳住自己的尺寸边界」——其它都是锦上添花。
