容器查询实践：组件响应式不能只依赖视口宽度
一、视口断点解决不了所有布局问题
传统响应式设计常依赖视口宽度，例如 768px 以下改成单列，1200px 以上展示三列。但组件真正可用的空间不一定等于视口宽度。一个卡片可能在桌面端被放进窄侧栏，也可能在移动端横屏获得较宽空间。只看视口，会让组件在不同容器里表现不稳定。
容器查询的思路是让组件根据自身容器宽度调整布局。这样组件更独立，也更适合设计系统。一个用户信息卡片放在详情页、弹窗、侧栏或列表中，都可以根据容器空间决定头像、标题、操作按钮如何排列，而不是依赖全局断点。
二、布局关系：组件关注自己的可用空间
flowchart TD A[页面视口] --> B[主内容区] A --> C[侧栏] B --> D[信息卡片] C --> E[同一个信息卡片] D --> F[宽容器布局] E --> G[窄容器布局]使用容器查询时，首先要为父容器声明container-type。组件内部再根据容器尺寸写样式。这样同一个组件在不同布局区域中可以自动适配。它特别适合卡片、工具栏、表单组、图表面板和复杂列表项。
需要注意的是，容器查询不是替代所有媒体查询。页面整体栅格、导航结构和大范围布局仍然适合用视口断点；组件内部排列和局部细节更适合容器查询。两者分工清楚，响应式代码会更容易维护。
三、代码示例：让卡片在窄容器里自然换行
下面示例展示一个信息卡片如何根据容器宽度调整布局。
.profile-card-shell { container-type: inline-size; } .profile-card { display: grid; grid-template-columns: 48px 1fr auto; gap: 12px; align-items: center; } @container (max-width: 360px) { .profile-card { grid-template-columns: 40px 1fr; } .profile-card__actions { grid-column: 1 / -1; justify-self: start; } }这段样式关注的是组件容器，而不是页面视口。卡片在宽区域时操作按钮放右侧，在窄区域时操作按钮换到下一行。这样的行为更符合组件复用逻辑，也减少了业务页面为组件写覆盖样式。
命名上建议把容器声明放在组件外壳，而不是随意放在任意父级。设计系统中可以明确哪些组件支持容器查询，哪些布局由页面负责。边界清楚，后续维护才不会混乱。
四、设计配合：响应式规则要进入组件文档
容器查询要求设计稿也改变思路。设计不应只提供移动端和桌面端两张图，而应说明组件在不同容器宽度下的行为。例如 320px 以下隐藏辅助文本，480px 以上显示次要操作，640px 以上启用双列。这样研发实现时有明确依据。
测试也要覆盖容器宽度。视觉回归不能只跑几个视口，还要把组件放进不同宽度的容器中截图。否则组件在侧栏、弹窗和主内容区的表现可能被漏掉。组件库文档可以提供可拖拽宽度的预览，这对设计评审很有帮助。
最后要避免过度响应。每个组件设置太多断点，会让行为难以预测。优先选择 1 到 2 个关键断点，解决真正影响可用性的布局问题。响应式不是让所有像素都变化，而是让内容在不同空间里保持清晰。
五、总结
容器查询让组件根据自身可用空间响应，解决了单纯视口断点难以处理的复用问题。页面级布局仍可用媒体查询，组件级细节更适合容器查询。把规则写进组件文档和测试，响应式设计才会稳定。