container-type: inline-size 是使用 @container 的硬性前提，必须显式声明在父元素上，否则规则静默失效；它只监听宽度变化，兼容性最好，且需作用于容器内部后代元素。
container-type: inline-size 是硬性前提，漏写就等于没写
写了 @container 却没反应？不是语法错，也不是浏览器不支持——90% 的情况是父元素根本没声明 container-type: inline-size。浏览器默认不把任何元素当容器，@container 规则不会报错，也不会警告，它只是静默跳过。
必须在父元素上显式设置，例如：
.card {
container-type: inline-size;
}
-
container-type: inline-size是最常用、兼容性最好（Chrome 105+ / Firefox 110+ / Safari 16+ / Edge 105+）的类型，只监听宽度变化 -
container-type: size同时监听宽高，但block-size（高度）在 Safari 和 Firefox 中仍受限，仅 Chrome 117+ 稳定支持 -
container-type: normal或未声明 → 容器资格无效，@container彻底失效 - 不能设在
display: contents或display: none元素上——它们不生成布局盒，无法测量尺寸
@container 规则只作用于容器内部后代，且不能嵌套
@container 不是全局样式开关，它的作用域严格限定在声明了 container-type 的那个父元素及其后代里。你不能用它选中容器自己，也不能跨层影响兄弟节点。
常见误写：
@container (min-width: 400px) {
.card { display: flex; } /* ❌ 错：.card 是容器本身，这条规则不会生效 */
.card h3 { font-size: 1.25rem; } /* ✅ 对：作用于容器内部子元素 */
}
- 选择器必须指向容器内的后代元素（如
.card img、.stat-value），不能是容器自身 -
@container规则不可嵌套，也不支持and/or复杂逻辑组合（目前仅支持简单括号条件） - 匿名查询（不设
container-name）默认匹配最近的、满足container-type的祖先，适合单层结构；多层嵌套或复用组件时，建议加命名避免误触发
Flex/Grid 父容器里直接加 container-type 往往失效
别在 display: flex 或 display: grid 的父容器上直接写 container-type: inline-size——它的子项宽度由布局算法动态分配，常被计算为 0 或不可靠值，导致查询始终不触发。
正确做法是把容器声明下移一级：
- 给 Flex/Grid 的直接子元素（比如每张卡片的外层 wrapper）设
container-type: inline-size - 如果要对 Grid 项做响应式控制，每个
.grid-item内部再包一层<div> 并设 <code>container-type: inline-size - 检查父级是否加了
overflow: hidden、min-width: auto或flex: 1这类限制尺寸测量的属性 - 临时加
outline: 1px solid red到疑似容器上，确认它是否真实撑开并显示预期宽度
单位和断点逻辑与 @media 完全不同
@container 只认绝对单位（px 最稳妥）和百分比（仅当容器本身有明确百分比宽度时才可靠），不支持 em、rem。它不感知视口，只关心当前容器渲染后的实际尺寸。
断点逻辑也更“直觉”：不是“屏幕变小就切”，而是“这个盒子窄了，里面就得收缩”。例如：
@container (max-width: 250px) {
.stat-value { font-size: 1.2rem; }
.stat-chart { display: none; }
}
- 同一组件放在侧边栏（300px 宽）和主内容区（800px 宽）会各自触发对应规则，无需额外类名或 JS
- 不要指望
@container和@media混用时自动对齐断点值——它们维度不同，@media管“在哪”，@container管“怎么长” - 复杂仪表盘、可拖拽面板、嵌套卡片等场景下，
@container的价值才真正凸显：你不用预设所有可能宽度，只需定义容器行为边界
容器查询真正难的不是语法，而是思维切换——从“我适配屏幕”变成“我管好自己”。一旦父容器声明漏掉、单位用错、或者试图让它跨层级生效，问题就会悄无声息地卡住，连 DevTools 都不报错。
