container-type 必须显式声明为 inline-size 或 size，否则 @container 规则静默失效；常见错误包括遗漏 container-type、在无布局盒元素上设置、容器尺寸不可测、与 @media 错误嵌套及 Safari 命名 bug。
container-type 必须显式声明，否则 @container 完全不生效
浏览器默认不会把任何元素当作容器，@container 规则静默失效是常态——控制台不报错、DevTools 里也看不出异常，但样式就是不应用。核心条件只有两个：container-type: inline-size（最常用）或 container-type: size，缺一不可。
常见踩坑点：
- 只写了
container-name: card，没配container-type→ 查询永远不触发 - 给
display: contents或position: absolute的父元素设container-type→ 属性被忽略，因为它们不生成布局盒 - 对
<span></span>这类内联元素直接设container-type→ 尺寸不可测，必须先加display: block或display: flow-root - 在
display: flex或display: grid的直接子项上设容器 → 无效；需额外包一层 wrapper，并确保该 wrapper 有稳定尺寸（如加min-width: 0）
父容器必须有可测量宽度，否则查询条件永不满足
即使 container-type 写对了，如果容器本身宽度无法稳定计算，@container 依然不会响应。关键不是“有没有宽”，而是“浏览器能不能可靠拿到它”。
典型不可测场景：
立即学习“前端免费学习笔记（深入）”；
- 父容器是
float或position: absolute→ 脱离文档流，尺寸无锚点 - 父容器仅靠内容撑开，且未设
width、max-width或flex-basis→ 浏览器无法在布局前确定其inline-size - 父容器是 Grid/Flex 子项，但父级 Grid/Flex 没设约束（如
grid-template-columns或flex: 1）→ 尺寸由算法动态分配，非静态可查
稳妥做法：给 wrapper 加 contain: layout style size，既隔离子内容影响，又确保尺寸上下文稳定；避免用 contain: content，它不包含尺寸隔离能力。
@container 和 @media 职责必须分清，不能嵌套混用
@container 不是 @media 的替代品，也不是升级版。前者管组件内部细节（比如卡片图文方向、按钮图标显隐），后者管页面结构（比如导航栏折叠、网格列数切换）。混用没问题，但嵌套就出问题。
错误写法示例：
@media (min-width: 768px) {
@container (min-width: 400px) {
.card { display: flex; }
}
}
后果：
- 组件失去独立性——它的行为被视口和容器双重绑定
- 在折叠屏或微前端场景下，卡片可能在窄容器中仍按桌面态渲染，导致图标溢出、文字换行错乱
Safari 命名容器存在解析 bug，线上项目优先用匿名写法
在 Safari 16.4 中，container-name 的匹配不稳定，尤其在动态插入或 SSR hydration 后。推荐降级为匿名 + 类名选择器兜底：
- 正确匿名写法：
.card-wrapper { container-type: inline-size; }+@container (min-width: 320px) { ... } - 命名写法（慎用）：
.card-wrapper { container: card / inline-size; }+@container card (min-width: 320px) { ... } - 不支持时，
@container规则被浏览器静默丢弃，不影响其他样式，所以不用@supports包裹整块
真正容易被忽略的点是：容器查询生效的前提不是“写了样式”，而是“容器尺寸在布局阶段已被浏览器确认”。很多移动端动态面板、拖拽卡片、弹窗内组件首次渲染时样式不生效，往往是因为容器 DOM 插入后未触发重排，或 JS 插入时机早于 CSS 解析完成。这种情况下，加 contain: layout 或强制触发一次 getBoundingClientRect() 可能比改断点更有效。
