容器查询响应父容器尺寸而非视口，需显式声明container-type: inline-size等，仅对直接父元素生效，单位限px/cqw等，调试需用DevTools容器面板。
容器查询比媒体查询更灵活，根本原因在于它响应的是组件自身的生存环境——父容器尺寸，而不是整个页面的视口宽度。这意味着同一个卡片组件，在侧边栏窄区自动切为竖排，在主内容区宽域自动展开为横排，无需额外 class 或 JS 干预。
container-type 必须显式声明，否则 @container 规则完全不生效
浏览器不会默认把任意 div 当作可查询容器。漏掉 container-type 是最常见失效原因，且控制台零报错，容易卡在“样式没变”却查不出问题。
-
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，比如：外层网格容器 → 中间卡片 wrapper → 内部标题区域 - 不要试图在 Flex/Grid 容器本身上设
container，它们的子项尺寸由算法动态分配，往往查不到稳定值 - 正确做法是：把
container放在 Flex/Grid 的直接子元素（如.card-wrapper）上，而非.grid或.flex-container
单位与计算逻辑和媒体查询完全不同
容器查询不支持 em、rem，也不推荐盲目用 %；它的尺寸单位基于容器自身，且 box-sizing、padding、border 都参与计算。
立即学习“前端免费学习笔记（深入）”；
- 只能用
px、vw（仅当容器本身有明确vw宽时才可靠）、cqw/cqh/cqi等容器相对单位 -
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」面板，确认目标元素是否出现在列表里，并检查 computed styles 中的 container 属性值。
