容器查询必须先声明container-type，否则@container规则无效；仅inline-size广泛支持；不可用于:root或body；禁用em/rem等相对单位；推荐px单位；container-name实现命名隔离；Chrome105+等主流浏览器原生支持。
container查询必须先声明container-type
不加container-type，@container规则完全无效——浏览器直接忽略，连报错都不会有。这是最常被跳过的一步。
- 必须在父容器上显式设置
container-type: inline-size（或size，但后者需同时设container-name且兼容性更差） -
inline-size是目前唯一广泛支持的取值，覆盖宽度变化场景；size要等宽高都变化才触发，实用性低 - 不能写在
:root或body上——body默认不是格式化上下文，多数情况下不生效；推荐用div、section等块级容器 - 如果父容器是
display: flex或grid，需确认它没被压缩（比如子项设了flex-shrink: 0但父容器没设min-width），否则实际可查询宽度可能远小于视觉宽度
@container里不能用em/rem/vw等相对单位
容器查询的断点单位只能是px、%（仅当父容器有明确宽度时）、ch等基于容器自身尺寸的单位。用em或rem会退化为视口基准，失去“响应父容器”的意义。
- 错误写法：
@container (min-width: 30em)—— 这里的em按根字体大小算，和容器无关 - 正确写法：
@container (min-width: 480px)或@container (min-width: 50%)（前提是父容器本身宽度固定或受约束） -
%容易踩坑：如果父容器宽度由内容撑开（如width: max-content），50%可能等于0px；建议优先用px - Chrome 110+ 支持
cap、ic等新单位，但 Safari / Firefox 尚未跟进，生产环境慎用
container-name用于多容器嵌套隔离
当一个页面里有多个可查询容器，又想让某条@container规则只作用于特定容器时，container-name就是唯一可控手段。
- 给父容器设
container-name: sidebar，然后写@container sidebar (min-width: 320px) { ... }，这条规则就只对这个命名容器生效 - 不命名的容器默认属于匿名组，所有匿名
@container规则都会匹配它们——容易误触发 - 命名不区分大小写，但建议全小写+短横线，避免和自定义属性冲突
- 同一元素可以有多个名字：
container-name: header, nav，对应多个@container块
兼容性现状和降级方案
Container Queries 在 Chrome 105+、Edge 105+、Safari 16.4+ 原生支持；Firefox 119+ 开始支持，但需手动开启layout.css.container-queries.enabled标志（不稳定）。没有polyfill能真正模拟容器查询逻辑。
立即学习“前端免费学习笔记（深入）”；
- 不要指望
@supports (container-type: inline-size)完美兜底——它在不支持的浏览器里恒为false，但无法阻止后续样式被解析 - 稳妥做法：基础布局用传统媒体查询（
@media）保底，容器查询作为增强层叠加 - 例如：先用
@media (min-width: 768px)设卡片为两列，再用@container (min-width: 320px)在窄容器内进一步微调内边距 - 构建工具如PostCSS目前无成熟插件转译
@container，别试图编译降级
真正难的是判断“哪个父级该设container”——它必须是布局边界清晰、宽度可预测的容器，而不是语义化但尺寸浮动的article或main。很多时候得为容器查询专门加一层div，这点和响应式设计直觉相反。
