容器查询需显式声明 container-type: inline-size 才生效，仅响应直接父容器宽度变化，不支持 em/rem 和 or 逻辑，调试须用 DevTools 容器面板验证。
因为容器查询响应的是组件直接父容器的实际渲染尺寸，不是整个视口宽度——同一组件在侧边栏窄容器里自动切竖排，在主内容区宽容器里展开为横排，完全不用 JS 或额外 class。
container-type 必须显式声明，否则 @container 规则静默失效
浏览器不会默认把任何 div 当作可查询容器。漏掉 container-type: inline-size 是最常见失效原因，控制台不报错，样式就是不生效，容易卡在“明明写了却没反应”上。
-
container-type: inline-size是首选，只监听宽度变化，开销小、兼容稳 -
container-type: size同时监听宽高，但重排更频繁，Safari 16.4+ 对它的支持仍有边界 case - 不能设在
display: contents、position: absolute或float元素上——它们不产生块格式化上下文，属性被静默忽略 - 推荐用简写：
container: card / inline-size，一行搞定类型和命名（但命名非必需）
@container 只对直接父容器生效，不穿透嵌套层级
子元素的 @container 规则只能响应其**直接父元素**的尺寸变化，不会向上冒泡或跨层捕获。想让深层组件响应外层布局容器，必须逐层声明 container-type。
- 错误做法：在
.grid或.flex-container上设container-type—— Flex/Grid 容器子项尺寸由算法动态分配，往往查不到稳定值 - 正确做法：把
container-type放在 Flex/Grid 的直接子元素（如.card-wrapper）上 - 若需卡片内部标题响应外层卡片宽度，就得确保
.card自身已声明container-type: inline-size
单位和计算逻辑完全不同，别套用媒体查询习惯
容器查询不支持 em、rem，也不推荐盲目用 %；它的尺寸单位基于容器自身，且 box-sizing、padding、border 都参与计算。
立即学习“前端免费学习笔记（深入）”；
- 只能用
px、cqw/cqh/cqi等容器相对单位；vw仅当容器本身有明确vw宽时才可靠 -
gap不计入inline-size，但padding和border会——如果你设了box-sizing: border-box，那inline-size就等于你写的width值 - 条件组合只支持
and，不支持or或嵌套逻辑；也不能把@container写在@media内部
真正难的不是语法，而是让容器「尺寸稳定可测」：Flex 子项被 min-width: 0 压缩、Grid 列宽受 fr 动态影响、JS 动态插入内容后未触发 resize —— 这些都会导致查询条件迟迟不匹配。调试时务必打开 DevTools 的「Container query containers」面板确认容器是否注册成功。
