同一张卡片放在内容区时横向排版，挪到侧栏后仍保留两列，标题被挤成几行。过去通常继续加媒体查询，但媒体查询感知的是视口，不知道组件实际分到了多少空间。页面出现抽屉、分栏和可折叠导航后，视口宽度与组件宽度早已不是一回事。
容器查询让组件改问"我的容器有多宽"。最小实现先建立查询容器：
css
.card-slot {
container-name: card-slot;
container-type: inline-size;
}
.article-card {
display: grid;
grid-template-columns: 1fr;
gap: 12px;
}
@container card-slot (width >= 36rem) {
.article-card {
grid-template-columns: 12rem 1fr;
align-items: start;
}
}inline-size 按书写方向的行内尺寸建立上下文，在常见横向书写模式里大致对应宽度。显式命名容器能避免组件嵌套后误用最近的其他查询容器，小项目可以省略名称，组件库里最好保留。
查询容器通常放在组件外层插槽，而不是直接放在要改变布局的 .article-card 上。容器查询的样式作用于容器后代，不能让容器根据自己的尺寸反过来改变自身尺寸，否则会出现循环依赖。"谁提供空间，谁响应空间"应该在 DOM 结构中清楚表达。
断点不该从设备宽度表里抄。把组件放进真实场景，拖动容器，观察内容从单列切换到双列的自然临界点。标题、按钮组和代码片段能否舒展才是依据，示例中的 36rem 不是通用常数。
容器查询长度单位还能处理受控间距：
css
.article-card {
padding: clamp(12px, 3cqw, 24px);
}1cqw 等于查询容器宽度的百分之一。不过不要让所有字号与间距连续缩放，界面会难以预测。用 clamp() 设上下限，只把确实需要变化的量交给 cq 单位。
容器查询不会取代媒体查询。页面导航是否切换、用户是否偏好减少动画、设备是否支持悬停，仍属于视口或设备环境。卡片横竖排、工具栏收起标签、数据表切换紧凑密度，更适合容器查询。边界清楚后 CSS 反而更少。
落地时要确认容器有稳定尺寸。如果外层宽度完全由子元素撑开，条件可能不稳定。Grid 与 Flex 中还要注意 min-width: auto 让子项不肯收缩，必要时设置 min-width: 0。这不是容器查询失效，而是布局约束没有建立好。
兼容策略不必维护两套完整样式。先提供可用的单列基础样式，再用 @supports (container-type: inline-size) 增强。旧环境至少能正常阅读。若业务必须覆盖旧浏览器，可用 Grid、Flex 和少量媒体查询兜底，增强规则放在基础规则之后。
测试也应从"几个手机宽度截图"改成组件尺寸矩阵。同一组件放入 280、480、720 像素容器，测试长标题、缺图、按钮增多和语言切换。还要覆盖嵌套容器，因为命名错误往往只会在组件嵌套时出现。
容器查询的价值不是多一条 CSS 语法，而是让组件拥有自己的响应规则。布局责任回到组件后，它被放进页面哪个角落，都不需要页面作者再补一串特例，这才是组件化响应式真正省下的维护成本。
工程上还应避免把查询条件散落在几十个文件。可以按组件定义少量有语义的布局阈值，并在 Storybook 或视觉回归用例里固定对应容器宽度。CSS 自定义属性不能直接替代查询条件中的所有语法，但可以统一组件内部的间距、字号和尺寸令牌，让断点切换后的样式仍使用同一套设计约束。
遇到 @container 没生效，排查顺序是：确认目标元素是查询容器的后代；在计算样式中确认 container-type；检查名称是否匹配；查看外层实际宽度；最后检查同优先级规则是否覆盖。不要一开始就加 !important，因为查询条件根本未成立时，提高优先级没有作用。
容器查询也适合工具栏。空间充足时显示图标与文字，变窄后只保留图标并提供可访问名称；再窄时把低频操作收入菜单。这里仍要保证按钮尺寸稳定，避免文字隐藏后整排控件跳动。响应式不只是"塞得下"，还要让键盘焦点顺序和屏幕阅读器名称保持一致。