@container 比 @media 更灵活，根本原因是响应对象从视口变为直接父容器尺寸；必须显式声明 container-type（首选 inline-size），且仅对直接父元素生效，单位仅支持 px/cqw/cqh，需确保容器尺寸稳定可测。
@container 比 @media 更灵活，根本原因不是语法新，而是它响应的对象变了：从整个浏览器窗口（视口）切换到了组件**直接父容器**的尺寸。这意味着同一个组件，在侧边栏、弹窗、网格项里能各自“看脸下菜”，不用靠 JS 或一堆 class 控制。
container-type 必须显式声明，否则 @container 完全不生效
浏览器不会默认把任意 <div> 当作可查询容器——漏掉这步是最常见的失效原因，且控制台零报错，只看到“样式没变”，排查起来像在黑盒里摸开关。
-
container-type: inline-size是首选，只监听容器行内方向（通常是宽度），开销小、兼容稳 -
container-type: size同时监听宽高，但重排更频繁；Safari 16.4+ 对它的支持仍有边界 case - 不能设在
display: contents、position: absolute或float元素上——它们不产生块格式化上下文，container-type被静默忽略 - 推荐用简写：
container: card / inline-size，一行搞定类型和命名
@container 只对直接父元素生效，不穿透嵌套层级
子元素的 @container 规则，只能响应其**直接父元素**的尺寸变化，不会向上冒泡，也不会跨层捕获外层容器的宽高。
- 想让深层组件响应外层布局容器？必须逐层声明
container-type：比如外层.grid→ 中间.card-wrapper→ 内部.card-header - 别在 Flex/Grid 容器本身上设
container——它们的子项尺寸由算法动态分配，往往查不到稳定值 - 正确做法是把
container放在 Flex/Grid 的**直接子元素**（如.card）上，而非.grid或.flex-container
单位和计算逻辑完全不同，px/cqw/cqh 才是真朋友
容器查询不支持 em、rem，也不推荐盲目用 %；它的尺寸单位基于容器自身，且 box-sizing、padding、border 都参与计算。
- 可用单位只有：
px、cqw（容器宽度的 1%）、cqh（容器高度的 1%）、cqi（容器内联尺寸的 1%，等价于cqw） -
gap不计入inline-size，但padding和border会——如果你设了box-sizing: border-box，那inline-size就等于你写的width值 - 条件组合只支持
and，不支持or或嵌套逻辑；也不能把@container写在@media内部
真正难的不是写 @container，而是让容器“尺寸稳定可测”
很多 @container 条件迟迟不匹配，问题不在 CSS，而在容器本身的尺寸是否可预测：
- Flex 子项被
min-width: 0压缩后，宽度可能突然跳变 - Grid 列宽受
fr动态影响，inline-size无法稳定读取 - JS 动态插入内容后未触发 resize，容器尺寸没更新，查询条件卡住
这些都不是语法错误，而是布局模型与容器查询机制之间的隐性冲突——得先让容器“站稳了”，@container 才能真正开始工作。
