@container不生效是因为父元素未设置container-type: inline-size；必须显式声明，不可继承；调试需用devtools layout面板勾选“container queries”确认容器识别状态。
为什么 @container 写了却没反应？
绝大多数人第一次用容器查询时，@container (min-width: 400px) { ... } 完全不生效——不是语法错，也不是浏览器不支持，而是父元素压根没被识别为“可查询容器”。
必须显式设置 container-type: inline-size（或 size），否则查询逻辑根本不会启动。这个声明不能省略，也不能靠继承获得。
-
container-type: inline-size是最常用、兼容性最好的选项，只响应宽度变化 -
container-type: size同时响应宽高，但触发重排开销更大，且 Firefox 目前对 height 部分支持不稳定 - 别往
、<main></main>或未设 layout containment 的语义标签上直接加container-type；它们默认不具备 containment context - DevTools Layout 面板里勾选 “Container queries” 可立刻看到哪些元素被识别为 container，这是最快定位问题的方式
如何给卡片组件加命名容器避免误触发？
不命名的 @container (max-width: 360px) 会匹配页面中任意一个带 container-type 的祖先，容易跨组件污染。尤其当多个卡片类型共存时，样式会互相干扰。
推荐统一用 container-name 显式绑定作用域：
- 在卡片包装器上写
container: card / inline-size（这是container-name+container-type的简写） - 查询时写
@container card (min-width: 400px)，确保只影响该类卡片 - 名字区分大小写、不能含空格或特殊字符；多个名字用空格分隔，如
container-name: card featured - 同一元素重复设置相同 name 会被后者覆盖，所以不要在 JS 动态多次 setAttribute
容器查询和媒体查询能一起用吗？怎么配合才不打架？
可以共存，但它们是两套完全独立的机制：@media 看视口，@container 看父容器尺寸。没有优先级覆盖关系，但容易因触发条件不同产生意外交互。
- 典型搭配：用
@media控制整体布局断点（比如 sidebar 折叠成 hamburger），用@container card控制卡片内部结构（图片横/竖排、文字截断方式） - 避免把同一类样式同时塞进两者，比如都写
.card { display: flex }，一旦容器窄而视口宽，行为就不可预测 - 调试时可临时加
outline: 1px solid red到容器元素，肉眼确认当前生效的是哪个查询上下文 - 旧浏览器兜底必须用
@supports not (container-type: inline-size)包裹@media回退逻辑，不能只靠caniuse的全局支持率判断
哪些地方最容易写出低效甚至崩溃的容器查询？
容器查询不是“更高级的媒体查询”，它会在容器尺寸变化时反复计算并应用样式。频繁 resize（比如拖拽面板、动画展开）下，性能陷阱比想象中更隐蔽。
- 避免在
@container块内写高成本样式：多层box-shadow、filter: blur()、大量伪元素叠加 - 不要用
container-type: size去监听高度微调，尤其当子元素有异步加载内容（如图片、懒加载区块）时，可能触发无限 layout cycle - 卡片内部若含第三方组件（如地图、图表库），它们自身的 resize observer 可能与容器查询冲突，建议用
contain: layout style paint隔离其渲染边界 - 真正难的从来不是语法，而是想清楚“这个卡片到底该响应谁的尺寸”——是它外面那个
div.panel？还是section.grid-col？一旦容器层级选错，整个自适应逻辑就崩了
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
