必须显式设置 container-type: inline-size 才能启用 @container 查询，否则规则静默失效；该属性需在父元素 CSS 中声明，监听其行内方向宽度，兼容主流浏览器且性能最优。
直接给父元素加 container-type: inline-size，否则 @container 规则根本不会生效——这是 90% 人踩坑的起点。
为什么 @container 写了却没反应？
浏览器默认不把任何元素当作容器，@container 不是“自动监听父级宽度”的魔法开关。它必须配合显式声明才能激活查询上下文。
-
container-type: inline-size是最常用、兼容性最好的类型（Chrome 105+、Firefox 110+、Safari 16+、Edge 105+ 全支持），只监听宽度变化，性能开销小 -
container-type: size同时监听宽高，但 block-size（高度）支持较晚（Chrome 117+ 才稳定），慎用 -
container-type: normal或未声明 → 容器资格被忽略，@container规则静默失效 - 别指望
display: contents或display: none的父元素能当容器——它们不生成布局盒，无法测量尺寸
container-name 什么时候必须写？
命名不是必需的，但决定你能否复用或精准控制查询范围。
- 匿名查询（不写
container-name）：适用于单个、唯一的父容器，例如.card { container-type: inline-size; }+@container (min-width: 400px) { ... } - 命名查询（带
container-name）：多个同类组件并列时避免样式污染，比如.card-1 { container-name: card-1; }和.card-2 { container-name: card-2; } - 同一个元素上不要同时设两个
container-type，浏览器只认最后一个声明 - 名字冲突？用唯一值（如
container-name: card-${id}）或直接省略名字改用匿名查询
Flex/Grid 父容器里为啥查询失效？
常见陷阱：父容器本身被限制了尺寸测量能力。
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden、overflow: clip会截断布局测量，导致容器宽度被错误计算为 0 - Flex 项目默认不拉伸，如果父 Flex 容器没设
min-width: 0或flex-basis，子容器可能无法正确报告尺寸 - Grid 容器中，若父项用
grid-template-columns: minmax(0, 1fr)这类弹性轨道，需确认其实际渲染宽度是否可测 - 验证方式：临时加
outline: 1px solid red到父元素，看它是否真实撑开并显示预期宽度
和 @media 混用时怎么分工？
两者不是替代关系，而是层级协作：视口管“在哪”，容器管“怎么长”。
-
@media处理页面级结构切换：导航栏折叠、全局字体缩放、主/侧边栏比例调整 -
@container处理组件内部形态：卡片从竖排变横排、图标大小随容器缩放、表格列数按可用宽度动态增减 - 别用
@container去模拟视口断点（比如写@container (min-width: 768px)），这违背设计初衷，也容易在嵌套容器中产生歧义 - 真要叠加响应，优先让
@media控制容器本身尺寸（如.sidebar { width: 300px; }），再由@container驱动其子组件行为
真正难的不是语法，而是判断“这个组件到底该响应谁”——有时候你以为它该响应父容器，结果发现父容器的宽度又由祖父容器的 Grid 轨道决定，而那个轨道又被 @media 动态修改。这种嵌套依赖链，才是调试时最耗时间的地方。
