容器查询不是媒体查询的替代品：96% 的支持率，和一个没有消失的边界

CSS 容器查询在 2026 年的浏览器支持已经超过 96%，Baseline 状态稳定，从 2023 年 2 月起就是可用的。一个被反复引用的判断是：对于可复用组件，容器查询是 2026 年的默认选择——一张卡片放在宽的主区域和窄的侧边栏里，应该根据它自己的空间调整，而不是根据视口宽度，后者无法表达这种差异。这个判断是对的，但它经常被过度延伸成“容器查询替代媒体查询”，而这两者并不在同一个维度上工作。

容器查询回答的是“这个组件在它当前的容器里应该长什么样”。它让组件的响应式逻辑内聚到组件内部，不再依赖全局视口断点；迁移到容器查询之后，组件在任意容器里都能自己调整，复用的时候不需要再传一堆 size 之类的 prop 去控制布局。这是真实的工程收益：组件不再需要知道自己在页面里被放在哪，放置它的布局负责提供容器，组件负责在容器里自适应。

但容器查询不能表达设备级、媒体类型和用户偏好的条件。媒体查询仍然负责：目标媒体类型（屏幕、打印）、设备特征（指针精度、悬停能力、分辨率）、用户偏好（prefers-reduced-motion、prefers-color-scheme、对比度偏好）。一个工具提示在给定空间里长什么样，可以由容器查询决定；它是否应该因为用户开启了“减少动态效果”而改变动画，仍然是媒体查询的领域。把这两类条件混进容器查询，不会让它们工作，只会让代码在错误的地方寻找答案。

另一个容易被忽略的限制是容器查询需要祖先容器。组件只能查询它最近的、声明了 container-type 的祖先。一个深埋在布局里的组件，如果中间某一层没有正确传递容器上下文，它的查询就不会按预期工作。这不是一个语法问题，是一个布局架构问题：容器查询把“响应式”的责任从全局视口转移到了组件树的局部，但局部容器需要被正确地建立和维护。

一个务实的迁移策略是分层的。可复用组件的内部布局——卡片、列表项、工具栏、表单项——优先用容器查询，让它们在任意容器里自适应。页面级布局、设备能力、用户偏好、打印样式继续用媒体查询。两者不是竞争关系，是不同粒度的工具：容器查询管“我在这个盒子里怎么排”，媒体查询管“用户在什么设备、什么偏好、什么媒介下看”。先把组件从视口断点里解耦出来，再保留媒体查询处理它仍然唯一擅长的那一层。96% 的支持率意味着容器查询可以放心用，不意味着媒体查询可以退休。