必须给容器显式设置 contain: size（至少）才能触发 @container 规则，否则浏览器直接忽略；flex/grid 子项需加 min-width: 0 或 width: fit-content 才具备可测尺寸，且 @container 与 @media 作用域不同、无 fallback 关系。
Container Queries 怎么写才不会被忽略
浏览器不执行你的 @container 规则，大概率是因为容器没设 contain 属性。css 容器查询不是“只要写了就生效”，它依赖显式声明的布局隔离边界。
必须给父容器加 contain: layout style size（至少含 size），否则查询条件永远不触发。现代框架如 React/Vue 的组件根元素常是 div，但默认不含 contain，得手动加。
-
contain: size是最低要求，只监听尺寸变化；加layout才能避免子元素溢出影响父容器尺寸计算 - 不要用
contain: content—— 它不包含size，@container直接失效 - 如果容器宽高来自弹性布局（如
flex: 1或grid自适应轨道），需确保其父级有明确尺寸约束，否则size无法稳定测量
为什么 container-query 在 flex/grid 子项里经常不工作
因为 flex 或 grid 容器默认不把子项的尺寸变化反馈给自身——子项尺寸由容器算法决定，而非反过来驱动容器重排。容器查询需要“可测量的、独立的尺寸上下文”，而默认 flex item 是尺寸被动方。
常见错误：把 contain: size 加在 display: flex 的直接子元素上，期望它响应内部文字增减。实际该子元素尺寸仍由父 flex 容器统一分配，自身无“自主尺寸”可查。
立即学习“前端免费学习笔记（深入）”；
- 解决方案：给该子项加
min-width: 0或width: fit-content，打破 flex 默认的最小尺寸限制，让它真正“按内容收缩” - 或者换思路：把容器查询移到上一级——即 flex 容器本身设
contain: size，再对它的子项用@container查询其宽度 - 注意 chrome 114+ 才支持在
display: contents元素上启用容器查询，旧版本会静默忽略
container-query 和 media-query 混用时的优先级陷阱
两者不互斥，但作用域和触发时机完全不同：@media 看视口，@container 看局部容器。混用时容易误判“哪个规则该生效”。
典型翻车场景：组件在小屏幕下靠 @media (max-width: 600px) 切成单列，同时又用 @container (min-width: 400px) 控制内部卡片间距。结果在窄屏手机上，容器宽度可能只有 300px，@container 条件不满足，但开发者以为“既然屏幕小，那卡片肯定也挤”，其实卡片根本没进查询范围。
-
@container规则只在容器满足尺寸条件时才计算其内部样式，不满足时完全跳过，不会 fallback 到 media 查询 - 不要指望
@container替代断点逻辑；它适合“组件内自适应”，比如一个卡片组件在 200px 宽度下隐藏图标，在 350px 下显示标题，在 500px 下展开详情——这些都应基于卡片自身宽度，而非整个页面 - 调试技巧：在容器上加
outline: 1px solid red，再打开 DevTools 的 “Layout” 面板勾选 “Show container query boundaries”，能直观看到哪些区域被识别为可查询容器
React 组件中怎么安全启用 container-query
jsX 不会自动注入 contain 样式，且 SSR 渲染时若服务端未生成对应 CSS，首屏可能漏掉容器查询逻辑，导致样式闪动或失效。
关键不在 JS，而在 CSS 注入时机和选择器稳定性。用 styled-components 或 Emotion 时，动态生成的类名可能导致 @container 选择器无法匹配到真实 dom 节点。
- 最稳做法：用普通
.css文件写@container，并确保容器元素有稳定 class 名（如class="card-container"），而不是依赖 JS 动态拼接的类 - 避免在
useEffect里动态加style.contain—— 容器查询依赖样式计算阶段，JS 运行时修改无效 - Vite/Next.js 用户注意：默认 CSS 提取插件可能剥离
@container规则，需确认构建后 CSS 文件里仍保留该语法（检查生成的.css输出）
容器查询不是“写完就能跑”的新特性，它要求你重新思考组件边界的定义方式——尺寸感知必须落在组件自身容器上，而不是假设父级或全局状态能兜底。这点最容易被跳过，也最难事后补救。