@container 能解决组件“水土不服”问题，因其让组件根据父容器实际尺寸而非视口宽度响应：侧边栏中280px容器不触发min-width:400px规则，保持竖排；主内容区960px容器则立即启用横向布局，无需额外类名或JS测量。
@container 能让组件真正“自适应”，而不是靠猜视口大小来硬套样式。 它不替代 @media，但解决了媒体查询在组件复用中根本性失灵的问题——比如同一张卡片放进侧边栏、弹窗、主内容区，尺寸不同却被迫共用同一套 @media (min-width: 768px) 断点，结果不是挤爆就是留白。
为什么 @container 能解决组件在不同容器里“水土不服”？
传统媒体查询只看 window.innerWidth，而组件实际可用空间由父容器决定。@container 把响应逻辑下沉到组件自身容器层级：
- 卡片在侧边栏（容器宽仅
280px）时，@container (min-width: 400px)不触发，保持垂直堆叠 - 同一张卡片在主内容区（容器宽
960px）时，该规则立即生效，切换为横向图文布局 - 无需为不同位置写
.card--in-sidebar、.card--in-modal等变体类名 - 组件 CSS 和使用上下文解耦，复制粘贴到新项目也能直接工作
@container 规则不生效？大概率是漏了这三件事
它不会报错，也不会警告，静默失效是常态。常见配置断点：
- 父元素没加
container-type: inline-size—— 浏览器默认不把它当容器，@container直接被忽略 - 父元素是
display: contents或position: absolute—— 这些值不产生块格式化上下文，container-type属性无效 - 父容器尺寸不可计算：比如纯
width: auto; height: auto且无 flex/grid 约束，浏览器无法得出内联尺寸，查询无法触发
@container 和 @media 混用时，怎么划清责任边界？
二者不是“谁取代谁”，而是分层协作。混用没问题，错位才出事：
立即学习“前端免费学习笔记（深入）”；
-
@media管全局结构：比如整页从grid-template-columns: repeat(4, 1fr)切到repeat(2, 1fr)，或折叠屏下隐藏导航栏 -
@container管组件内部排布：比如卡片内图标是否显示、表单项是堆叠还是并排、标题字号随容器宽度阶梯变化 - 避免嵌套：别在
@media (min-width: 768px)里再套@container—— 这会让组件失去独立性，Safari 16.4 对嵌套解析还有 bug - 容器查询只响应直接父级：
.card的@container只读.card-container尺寸，不会穿透到外层.sidebar
真正难的不是语法，是思维切换：从“页面有多少像素宽”转向“这个组件盒子有多大”。一旦习惯，你会发现很多过去靠 JS 计算尺寸、动态加 class 的场景，现在一行 container-type 就能收口。但得记住——它不自动生效，每个容器都得手动“激活”。
