想象一个项目管理页面：左侧是任务列表，右侧是详情面板。你把一张原本很好看的任务卡片放进右侧，标题突然被挤成好几行，按钮也贴到了边缘。浏览器明明很宽，为什么卡片还是像住进了小房间？
问题可能出在判断依据上。页面宽度只能告诉我们整个窗口有多大，卡片真正拿到多少空间，还取决于它被放在什么位置。CSS 容器尺寸查询，就是让组件根据所在容器的尺寸调整布局。
同一块屏幕里，可以有很多种空间
媒体查询经常用来判断视口宽度，再调整整页布局。比如窗口变窄后，把页面从多列改为单列。这类规则依然有用，因为它处理的是页面层面的变化。
但组件的处境更具体。任务卡片可能在主列表里占一整行，也可能放在侧边面板里，还可能出现在一个可拖动宽度的弹窗中。即使浏览器尺寸始终不变，它能使用的空间也在变化。
如果卡片只根据视口决定横排或竖排，就可能在窄面板里继续坚持横排。外部条件告诉它“空间足够”，实际容器却没有兑现这份承诺。布局变形，未必是断点数量太少，也可能是断点观察错了对象。
容器尺寸查询把观察位置移近了组件：判断一个符合条件的祖先容器，再把样式应用到内部元素。这样，一张卡片就能在宽位置采用展开布局，在窄位置保留紧凑布局。
先确定谁提供空间，再确定谁变化
理解这种关系，可以先在脑子里画两个框。外框负责提供空间，内框装着卡片内容。外框被设为尺寸查询容器，内部卡片根据查询结果改变排布。
对于常见的横向书写页面，内联方向通常对应水平方向。声明内联尺寸容器后，就能围绕这一方向的可用空间设计尺寸条件。它并不是让卡片任意读取自己，再用读到的结果反复修改自己。
这样的分工很重要：谁决定容器有多宽，谁响应这个宽度，必须清楚。如果布局本身没有稳定的空间分配，只是机械加上查询规则，仍可能得到令人困惑的结果。
在多层嵌套页面中，还要确认规则实际找到了哪个容器。需要区分不同层级时，可以给容器命名，让查询更明确。否则你以为观察的是侧边面板，实际匹配的却可能是更近的一层包装。
布局阈值应该从内容里长出来
回到任务卡片。它可能包含标题、状态、负责人和操作按钮。先做一个窄空间也能阅读的基础布局：标题自然换行，操作区域有独立位置，必要信息不互相遮挡。
接着逐渐拉宽外框，观察什么时候有条件让状态和操作区域并排。这个位置可以成为候选阈值。它来自内容的实际需要，比直接复制一组手机、平板、桌面的固定分类更贴合组件。
这里也不必追求每宽一点就出现一种新样式。变化太频繁，会增加阅读与维护负担。优先选择真正改善信息层级的转折点，例如从上下分区变为左右分区。
还要拿不同内容试一试：短标题看起来舒服，不代表长项目名也放得下；中文状态标签合适，不代表切换语言后仍然合适。容器查询负责判断条件，内容是否被合理组织，仍然要靠设计。
页面规则与组件规则一起工作
一个实用的分工是：页面决定任务列表与详情面板怎样分配空间，组件决定在获得的空间里如何呈现。前者可以使用网格、弹性布局和媒体查询，后者再根据容器条件细化内部布局。
这能减少一些隐性的关联。页面不必为每种卡片位置写一份特殊规则，卡片也不用猜测自己是不是在某个特定页面中。复用时，空间成为双方更直接的约定。
但它不代表所有响应式问题都应该改写成容器查询。面向整个页面的调整，依然可以由页面规则承担；在目标环境中使用前，也应确认具体特性的支持情况，并让基础布局本身可读。
检查界面时，不妨做一次简单实验：保持浏览器宽度不变，只改变侧栏或弹窗宽度。如果组件因此失去可读性，你就找到了一个值得考虑容器查询的位置。
你遇到过哪种“页面很宽，局部却很挤”的布局问题？