容器查询不能替代媒体查询，因前者针对组件父容器宽度自适应，后者响应视口宽度；误用如导航栏折叠或在无明确宽度元素上设container-type会导致失效。
容器查询不能替代媒体查询，二者根本不是同一层的问题：@media 管整页布局节奏，@container 管单个组件在父容器里的自适应行为。强行用 @container 覆盖所有响应式逻辑，反而会让页面失去视口级控制力。
为什么 @container 不能直接“替代” @media
媒体查询回答的是“当前浏览器窗口多宽”，容器查询回答的是“这个卡片所在的盒子多宽”。同一个卡片放在 300px 宽的侧边栏和 900px 宽的主区，视口可能都是 1440px，@media (min-width: 768px) 会统一生效，但 @container (min-width: 400px) 只对后者触发——这才是组件该有的行为。
典型误用场景：
- 用
@container控制整个导航栏折叠/展开：它依赖父容器宽度，而导航栏通常撑满视口，父容器宽度≈视口宽度，此时反而不如@media稳定 - 在
body或main上加container-type: inline-size，期望全局生效：这些元素往往没设明确宽度（比如width: 100%但父级是display: flex），计算出的容器尺寸可能为 0，查询完全不触发
container-type: inline-size 是最常用配置的原因
绝大多数组件适配只关心父容器宽度变化（如卡片列数、表单项排列方向），inline-size 正是监听这个维度。它比 size（宽高都监听）更轻量，也比 block-size（监听高度）更可控——浏览器对高度变化重排开销大，且很多容器高度由内容撑开，不稳定。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 只在有明确宽度约束的元素上设
container-type: inline-size，例如max-width: 400px、width: 300px或flex: 0 0 320px - 避免在
flex或grid直接子项上盲目添加，除非你确认它的计算宽度 ≥ 查询断点（可用 DevTools 的 Computed 面板查container-type和width） - 开发时临时加
outline: 1px solid red，Chrome Layout 面板会显示 “Container” 标签，确认是否真被识别
@container 查询条件中 min-width 失效的常见原因
写了 @container (min-width: 400px) { .card { flex-direction: row; } } 却没反应？大概率不是语法错，而是容器本身没“达标”。
排查步骤：
- 打开 DevTools → 选中容器元素 → Computed 面板检查
container-type是否为inline-size - 查看该元素的
width计算值（注意不是clientWidth，是 CSS 渲染后的真实 width）是否 ≥ 400px - 确认没有其他样式（如
overflow: hidden或transform）意外创建了新的包含块，干扰容器尺寸计算 - 若用了
container-name，确保@container name (min-width: 400px)中的 name 和 HTML 中的container-name: card完全一致（区分大小写）
Tailwind CSS 中 container 配置的真实作用
tailwind.config.js 里写的 theme.container.type 和 theme.container.name 不会生成任何 CSS，只是为工具类提供映射关系。真正起作用的是插件生成的原子类，比如 container-type-xs 对应 container-type: inline-size，container-name-card 对应 container-name: card。
实用建议：
- 如果全项目只用
inline-size，根本不用配type映射，直接写container-type-inline-size更直白 -
container-card这种复合类 =container-type: inline-size; container-name: card，省一个 class，但调试时不如拆开清晰 -
container-name不是必须的，但命名后能避免跨组件样式污染，比如两个都叫.card的组件，一个用@container card (min-width: 400px)，另一个用@container sidebar (min-width: 280px)，互不干扰
真正容易被忽略的是：容器查询生效的前提，是容器必须“真实渲染出足够宽度”，而不是“理论上应该有”。很多问题不是语法或兼容性导致的，而是容器在布局流中被 flex/gap/transform 等特性悄悄压扁了——先确认容器尺寸，再写查询，比反复调断点更高效。
