container-query 不生效的首要原因是父容器未设置 container-type。必须在直接父容器上显式声明 container-type: inline-size 或 size，不可继承，且需确保该容器有实际尺寸。
container-query 不生效？先确认父容器是否设了 container-type
响应式容器查询（@container）不是“写了就生效”，它依赖父容器显式声明类型。没加 container-type，子元素里写再多 @container (min-width: 400px) 都会被浏览器直接忽略。
常见错误现象：@container 规则完全不触发，DevTools 里连匹配提示都没有；或者媒体查询（@media）能动，但同尺寸下容器查询没反应。
- 必须在直接父容器上设置
container-type: inline-size（最常用）或container-type: size（需同时设宽高） - 不能靠继承，也不能设在 body 或远祖元素上——只对**最近的、有
container-type的祖先**生效 - 如果父容器是 flex/grid 项，注意它可能被压缩到 0 宽，导致
inline-size查询始终为 0 -
container-name是可选的，但多人协作时建议命名，避免不同组件的容器查询互相干扰
旧版媒体查询和新版容器查询混用时，谁优先？
两者不互斥，但作用机制完全不同：@media 看视口，@container 看局部容器。它们不会“覆盖”彼此，但容易因书写顺序或逻辑重叠造成意外交互。
使用场景：比如卡片组件既要适配小屏幕（用 @media 控制整体布局），又要根据卡片自身宽度调整内部文字大小（用 @container）。
- 优先级无关顺序——
@media和@container是并行计算的，最终样式由 CSS 层叠规则决定（具体看选择器权重、位置） - 真正容易踩的坑是「重复控制同一属性」：比如都改了
font-size，结果一个按视口缩，一个按容器缩，视觉上打架 - 推荐分工：用
@media做大颗粒度布局切换（如 grid → flex），用@container做组件内微调（如头像尺寸、按钮文字换行） - Chrome 111+ 支持
container-name+@container限定范围，可避免全局污染
兼容性 fallback 怎么写才不冗余？
目前 Safari 16.4+、Firefox 117+、Chrome 105+ 支持容器查询，但 IE 和旧版 Edge 完全不认 @container。直接丢弃会断功能，全量写两套又难维护。
性能影响不大，但写法不当会导致 CSS 体积膨胀或维护成本飙升。
- 不要用 JavaScript 检测支持再注入样式——破坏 SSR，且增加运行时开销
- 用
@supports (container-type: inline-size)包裹容器查询规则，老浏览器自动跳过，新浏览器正常执行 - 基础样式（如默认字号、间距）仍写在常规选择器里，
@supports块里只放条件性增强部分 - 避免嵌套
@supports+@container—— 目前所有支持容器查询的浏览器也都支持@supports，没必要套娃
Flex/Grid 容器里用 container-query，为什么宽度总不对？
这是最常被忽略的隐性约束：容器查询的 inline-size 是指该容器在主轴上的可用尺寸，而 Flex/Grid 项默认可能被拉伸、压缩甚至溢出，导致查询值与肉眼所见不符。
典型表现：容器明明看着有 300px 宽，但 @container (min-width: 300px) 就是不触发。
- 检查父容器是否设置了
min-width: 0或min-height: 0（Flex/Grid 默认有最小尺寸限制，会撑大内容） - 给查询目标容器加
width: 100%或flex: 1，确保它真实占满可用空间 - 避免在
overflow: hidden容器里查size类型——此时size查询可能返回 0 - 调试技巧：在 DevTools 的 Layout 面板里勾选 “Show container queries”，能看到当前容器被识别的尺寸和类型
事情说清了就结束。容器查询不是媒体查询的替代品，而是补位——它解决不了视口级响应，也压不住父布局的失控。真正卡住的，往往不是语法，而是你没意识到那个 div 其实没拿到宽度。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
