容器查询不能替代媒体查询，因二者职责不同：@media管整页布局，@container管组件内部适配；container-type: inline-size最常用，因仅监听宽度、性能轻量且稳定。
@container 不能直接“替代” @media，它解决的是不同层级的问题：媒体查询管整页，容器查询管组件。强行用容器查询覆盖所有响应式逻辑，反而会让布局失控。
为什么 container-type: inline-size 是最常用配置
绝大多数卡片、列表项、表单区域的响应式行为只关心父容器宽度（比如侧边栏缩放、网格列数变化），inline-size 正是监听这个维度。它比 size（宽高都触发）更轻量，也比 block-size（高度变化）更可控——浏览器对高度变化的重排开销大，且很多容器高度是内容撑开的，不具稳定性。
- 不要在
flex或grid容器上盲目加container-type: inline-size：如果父级没设明确宽度（比如flex: 1但没给max-width），它的计算宽度可能为0或不可预测值，导致查询完全不触发 -
container-name不是必须的，但命名后能避免跨组件样式污染。例如两个都叫.card的组件，一个用@container card (min-width: 400px)，另一个用@container sidebar (min-width: 280px)，互不干扰 - 开发时可临时加
outline: 1px solid red到容器元素，确认它是否真被识别为容器（Chrome DevTools 的 Layout 面板会显示 “Container” 标签）
tailwind.config.js 中 container 配置的真实作用
你写的 theme.container.type 和 theme.container.name 并不会生成任何 CSS，只是为 Tailwind 的工具类提供映射关系。真正起作用的是插件生成的原子类，比如 container-type-xs 对应 container-type: inline-size，container-name-card 对应 container-name: card。
- 配置里写
xs: 'inline-size'，不代表你必须用container-type-xs；你也可以直接写container-type-inline-size，只要插件已加载 - 如果你只用一种容器类型（比如全项目只用
inline-size），根本不用配type映射，直接用container-type-inline-size更直白 -
container-card这种复合类 =container-type: inline-size; container-name: card，省一个 class，但调试时不如拆开清晰
@container 查询条件中 min-width 失效的常见原因
写了 @container (min-width: 400px) { .card { flex-direction: row; } } 却没反应？大概率不是语法错，而是容器本身没“达标”。
- 检查容器是否真的渲染出了 ≥400px 的宽度：用 DevTools 选中容器 → Computed → 查看
container-type是否生效，以及width计算值（注意不是clientWidth，有些 flex 场景下它和 CSS width 不一致） - 容器内子元素有
min-width（如图片、输入框）且总和超限，会导致容器被撑宽 —— 看似满足条件，但其实是子元素在“硬顶”，此时应优先用minmax()或flex-shrink: 0控制子项 - 不要嵌套容器查询：A 容器里套 B 容器，B 的查询不会基于 A 的尺寸，而是基于它自己的父容器（即 A）。如果想让 B 响应 A 的尺寸，B 必须直接设
container-type，且 A 必须是它的直接父元素
什么时候该坚持用 @media，而不是硬套 @container
容器查询不是银弹。页面顶部导航栏折叠、页脚栅格断点、字体基础缩放这些，依然得靠视口维度控制 —— 因为它们天生就和屏幕物理尺寸强相关。
立即学习“前端免费学习笔记（深入）”；
- 全局布局切换（如移动端 hamburger 菜单展开）必须用
@media，@container没法感知视口变化 - 当组件被复用到未知上下文（比如第三方 CMS 插槽）时，无法保证父容器一定设置了
container-type，此时回退到视口断点更稳妥 -
@container在 Safari 16.4+、Chrome 110+、Firefox 119+ 才稳定支持，旧版 iOS WebView 仍需降级处理，别指望它 100% 替代
@container 最有效的场景就两类：卡片内部结构重组（图文横排/竖排切换）、网格项密度控制（每行 2 列 → 3 列）。其他地方硬替，容易掉进“以为在解耦，其实是在制造新耦合”的坑。 
