容器查询生效的前提是父容器显式声明container-type: inline-size，否则@container规则完全不触发；它仅作用于最近一个设了该属性的祖先元素，且不继承、不自动识别。
容器查询不是“写完 @container 就能用”，它必须配合父容器显式声明 container-type 才会生效。90% 的失败案例，问题出在漏掉了这一步。
为什么 @container 写了但样式完全不触发？
最常见原因是父容器没被标记为“可查询容器”。@container 不会向上遍历任意祖先，只认最近一个设置了 container-type 的父元素。
-
container-type: inline-size是最常用选项，对应宽度变化（如 flex 容器的width或max-width） -
container-type: size要求同时监听宽高，但 Safari/Chrome 对 height 变化响应有延迟，实际中慎用 -
container-type: normal（默认值）等于没开容器查询，写了也白写 - 不要依赖
display: contents或position: absolute的父元素——它们通常无法建立 containment context
@container 里该用 min-width 还是 width？
width: 320px 是精确匹配，几乎无实用价值；min-width/max-width 才是响应式逻辑的核心。
-
@container (min-width: 300px)：当容器宽度 ≥ 300px 时启用，适合“从小变大”的渐进适配 -
@container (max-width: 480px)：当容器宽度 ≤ 480px 时启用，适合紧凑态降级 - 避免混用
min-width和max-width在同一规则里，比如(min-width: 300px) and (max-width: 480px)—— 浏览器解析行为不稳定，部分版本会直接忽略 - 单位只支持
px、em、rem、%和容器单位（cqw等），不支持vw或vh
命名容器（container-name）到底什么时候必须用？
当你页面里存在多层嵌套容器，且子组件需要明确响应某一层（而非最近一层）时，命名是唯一可靠方式。
立即学习“前端免费学习笔记（深入）”；
- 没命名时：
@container (min-width: 400px)总是作用于“最近一个有container-type的祖先” - 有命名时：
@container sidebar (min-width: 200px)只匹配container-name: sidebar的那个容器，跳过中间所有其他容器 - 简写语法
container: sidebar / inline-size更安全，避免container-name和container-type分开写导致遗漏 - 注意：名称区分大小写，
sidebar和Sidebar是两个不同容器
组件里样式“闪一下”是怎么回事？
这是 React/Vue 组件首次渲染时常见的视觉抖动，根源在于容器尺寸计算时机与 CSS 解析顺序错位。
- DOM 挂载完成前，容器宽度可能是
0或未定义，@container规则可能短暂失效，回退到基础样式 - 浏览器重排（reflow）后容器尺寸确定，
@container才真正生效，造成一次样式切换 - 缓解方法：给容器加
min-width: 0或width: min-content，避免初始宽度坍缩 - 更稳妥的做法是在 JS 层预留占位尺寸（如
style={{ width: '300px' }}），等真实内容就绪再移除
真正难的不是语法，而是判断“这个容器是否值得设为 container-type”。过度使用会导致 containment 开销上升，尤其在滚动区域或动画频繁的节点上——container-type: size 的性能代价明显高于 inline-size。
