container-type 必须显式声明，否则 @container 规则不生效；需在有明确宽度约束的父元素上设置 container-type: inline-size，配合 cqw 等容器单位或兼容 px/rem，并通过命名、@supports 和降级方案确保跨浏览器稳定运行。
container-type 必须显式声明，否则 @container 规则不生效
很多人写了 @container 却没效果，根本原因是父容器没启用查询上下文。CSS 不会自动把任意 <div> 当作容器——必须用 container-type: inline-size（最常用）或 container-type: size 显式声明。
常见错误：
- 只写
@container (min-width: 400px) { ... }，但父元素没设container-type - 在没有宽度限制的元素上设
container-type，比如一个纯display: block且没width、max-width或flex-basis的<div>，浏览器无法计算inline-size，查询直接跳过 - 误以为 Bootstrap 的
.container类自带容器查询能力 —— 它只是 CSS 类，和container-type无关
正确做法：给有明确宽度约束的包装元素加样式，例如：.card-wrapper { container-type: inline-size; max-width: 600px; }
@container 规则里不能混用视口单位，要用 cqw/cqh
容器查询的断点单位不是 px 或 rem，而是基于容器自身尺寸的新单位：cqw（container query width）、cqh（height）、cqi（inline-axis）、cqb（block-axis）。它们类似 vw/vh，但基准是容器，不是视口。
立即学习“前端免费学习笔记（深入）”；
如果你写 @container (min-width: 400px)，它依然能工作（兼容旧写法），但语义模糊；而 @container (min-width: 40cqw) 明确表示“当容器宽度的 40% 达到阈值时触发”，更可控、更易复用。
注意：cqw 是实验性单位，目前仅 Chrome 115+、Firefox 119+ 支持，生产环境建议优先用 px 或 rem 写断点，再配合 @supports 做渐进增强。
嵌套容器要命名，否则查询可能命中错误父级
多个 container-type: inline-size 的元素嵌套时，@container 默认匹配最近的、满足条件的祖先容器。如果不命名，容易在复杂布局中查错层级。
比如侧边栏卡片和主区卡片都用了相同断点逻辑，但希望各自独立响应，就该分别命名：
.sidebar-card { container: sidebar / inline-size; }.main-card { container: main / inline-size; }
然后写：@container sidebar (max-width: 320px) { ... }@container main (min-width: 600px) { ... }
不命名也能跑，但一旦结构微调（比如加了一层 wrapper），查询就可能意外落到外层容器上，导致样式错乱。
旧浏览器降级方案不是可选，而是必须考虑的现实
Container Queries 在 Safari 16.4+、Chrome 105+、Firefox 110+ 才原生支持。2026 年仍有相当比例用户停留在旧版 Safari 或企业内网 IE/Edge Legacy 环境。
不能只靠 @supports (container-type: inline-size) 包一层就完事。实际要分三步：
- 先写一套基于
@media的兜底布局（覆盖主流断点） - 再用
@supports开启@container规则，覆盖局部组件细节 - 对关键交互组件（如弹窗内卡片），加轻量 JS 监听
ResizeObserver，动态切换 class，避免白屏或错位
最常被忽略的是：容器查询依赖父容器有稳定尺寸。如果父容器本身靠 JS 动态撑开（比如展开折叠菜单后才设置宽度），那 container-type 可能初始化时无效，得手动触发重计算。
