容器查询的 container-type 必须显式设置为 inline-size 或 size；grid 容器默认不是查询容器，需手动添加 container-type 才生效，仅设 container-name 会导致静默失效。
容器查询的 container-type 必须显式设置为 inline-size 或 size
CSS Grid 容器默认不是查询容器，即使你用了 display: grid，也不会自动触发容器查询。浏览器不会把 Grid 容器当作可查询上下文，除非你手动加 container-type。
常见错误是只写 container-name 却漏掉 container-type，结果媒体查询完全不生效，控制台也无报错——它就静默失效了。
-
container-type: inline-size：适用于响应宽度（最常用，兼容性更好） -
container-type: size：同时响应宽高，但目前仅 Chromium 117+ 和 Safari 17.4+ 支持，Firefox 仍不支持 - 不能写成
container-type: block-size或其他值，无效
Grid 子项用 @container 时，查询的是父容器尺寸，不是网格轨道尺寸
容易误以为 @container (min-width: 400px) 是在查某个 grid column 的宽度，其实它查的是该子项**直接父容器**的 inline-size（即内容框宽度），和 Grid 的 grid-template-columns 或 fr 单位无关。
这意味着：即使你用 grid-template-columns: 1fr 2fr，子项的容器查询依然基于父容器整体宽度，而不是它被分配到的那条轨道的实时宽度。
- 若想按“实际占据宽度”响应，得让子项自己成为容器（即给子项设
container-type），再让它的子元素查询 - Grid 的
fit-content()、minmax()等函数不影响容器查询的基准尺寸 - 注意 margin/padding/border 会缩小内容框尺寸，从而影响查询断点匹配
嵌套 Grid + 容器查询时，container-name 作用域是局部的
多个 Grid 容器可以共用同一个 container-name，但 @container 规则只会向上查找**最近的、匹配该 name 且设置了 container-type 的祖先容器**。
典型陷阱：外层 Grid 设了 container: root / inline-size，内层 Grid 也设了同名容器，结果内层子项的 @container 查到的是外层容器，而非预期的内层。
- 推荐为每层容器设唯一
container-name，比如container: card / inline-size、container: card-header / inline-size - 不要依赖匿名容器（即只写
container-type不写container-name），因为@container无法匹配匿名容器 - Safari 对多层命名容器的解析更严格，Chrome 可能“碰巧”工作，但不可靠
Flexbox 替代方案在部分场景下反而更可控
当 Grid 列数动态变化（如 grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))）且你希望每个格子独立响应自身宽度时，强行用容器查询 + Grid 容易陷入尺寸套娃：父容器尺寸变 → Grid 重排 → 子项尺寸变 → 查询再触发 → 样式抖动。
这时改用 Flexbox + 容器查询往往更稳：
- 给每个卡片项设
container: card / inline-size - 用
display: flex; flex-wrap: wrap替代 Grid 布局 - 每个卡片内部用
@container (min-width: 320px)控制自身结构，互不干扰 - 避免 Grid track sizing 与容器查询之间的隐式耦合
真正难处理的不是语法，而是「谁的尺寸被谁查询」这个链路是否清晰。一旦嵌套超过两层，或者容器尺寸受 aspect-ratio、contain: layout 干预，就得用 DevTools 的 Layout 面板逐层检查 container query boundary。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
