@container 无效的主因是父元素缺失 container-type 声明；必须显式设置 container-type: inline-size（或 size），且不能直接用于 body/main 等无 layout containment 的元素。
为什么@container写了却没反应？缺 container-type 声明
最常见的情况是：你写了 @container (max-width: 400px) { ... }，但样式死活不生效。根本不是语法写错，而是浏览器压根没把父元素当成“可查询的容器”。container-type: inline-size 必须显式加在父容器上，否则整个 @container 规则被忽略。
注意以下几点：
-
container-type目前只稳定支持inline-size（宽度）和size（宽高），block-size在主流浏览器中仍不可靠 - 不能直接写在
或<main></main>上——它们默认没有 layout containment，得靠 CSS 显式触发 - 如果父容器已设
container-type，子容器再设不会继承，但也不冲突；可以各自独立查询 - DevTools 的 Layout 面板里勾选 “Container queries”，能立刻看到哪些元素被识别为 container
怎么让同一张卡片在侧边栏和主内容区自动切换布局？用 container-name 精准匹配
不加 container-name 的 @container (min-width: 300px) 会匹配页面里所有带 container-type 的祖先容器，容易误触发。尤其在微前端或低代码看板里，多个卡片类型混排时极易串样式。
推荐写法：
- 给卡片外层容器加
container: card / inline-size（等价于container-name: card; container-type: inline-size） - 查询时写
@container card (max-width: 360px)，只作用于这个命名容器 - 名字区分大小写、不能含空格或特殊字符；多个名字用空格分隔，如
container-name: card featured - 同一 DOM 元素重复设置相同 name，后者覆盖前者
@container 和 @media 能一起用吗？能，但别混逻辑
@container 和 @media 是两套完全独立的机制，不存在优先级覆盖关系，但容易产生意外交互。
典型合理分工：
-
@media控制整体布局断点（比如折叠 sidebar、切换暗色模式） -
@container控制组件内部结构（比如卡片内图片横/竖排、按钮是否显示图标） - 不要在
@container外再套一层@media (min-width: 1200px)做“双重保险”——这反而会让容器查询失效，因为它的触发条件被视口逻辑干扰了 - 折叠屏场景下，
@container更可靠：哪怕视口是 1920px 宽，只要卡片被塞进 280px 宽的 drawer，@container card (max-width: 360px)就会立刻生效
移动端高频 resize 下卡顿？避开重绘陷阱
拖拽面板、折叠 sidebar、iPad 分屏这些操作会频繁触发容器尺寸变化，@container 规则也会反复重算。如果里面写了高开销样式，主线程就会卡住。
实操建议：
- 避免在
@container里叠加多层box-shadow、大量filter或transform: scale() - 慎用
aspect-ratio+object-fit组合做图片自适应——某些旧版 Safari 会触发额外重绘 - 如果卡片内容由 React/Vue 动态插入，确保
container属性在首次渲染时就存在，而不是 JS 挂载后再补 —— 否则首次进入窄容器时查询不触发 - 兼容性兜底必须做：
@supports not (container-type: inline-size)内回退到@media，否则 iOS 16.3 及更早版本直接白屏
.sidebar），还是它爷（.dashboard-grid）。一旦容器层级选错，@container 再精准也救不回错位的布局。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
