@container 比 @media 更灵活，根本原因是响应对象从视口变为直接父容器尺寸；必须显式声明 container-type（首选 inline-size），且仅对直接父元素生效，单位仅支持 px/cqw/cqh，需确保容器尺寸稳定可测。

@container 比 @media 更灵活，根本原因不是语法新，而是它响应的对象变了：从整个浏览器窗口（视口）切换到了组件**直接父容器**的尺寸。这意味着同一个组件，在侧边栏、弹窗、网格项里能各自“看脸下菜”，不用靠 JS 或一堆 class 控制。

container-type 必须显式声明，否则 @container 完全不生效

浏览器不会默认把任意 <div> 当作可查询容器——漏掉这步是最常见的失效原因，且控制台零报错，只看到“样式没变”，排查起来像在黑盒里摸开关。 <ul> <li> <code>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 才能真正开始工作。