Container Query 组件响应式契约

大理论

传统 media query 只知道 viewport，不知道组件被放在 320px 的侧栏还是 840px 的内容区。组件库和 agent 生成 UI 时，经常复用同一张 card、table summary、asset tile 或 chart module；如果它们只靠全局断点，就会在嵌套布局、split view、dock panel 和 responsive dashboard 里失真。Container query 的价值是让组件声明自己的布局契约：在窄容器里保留核心信息和主操作，在宽容器里展开元数据、次级操作和更丰富的视觉结构。

小知识点

1. 先给可复用容器设置 container-type: inline-size，必要时用 container-name 避免误读最近祖先。
2. 组件断点应基于内容需要，例如标题两行、操作按钮数量、图表 legend、表格列宽，而不是复用页面 768/1024 断点。
3. 窄容器先降密度和层级：隐藏次级 metadata、把横向 action row 改成 menu、图表 legend 移到下方或转成表格摘要。
4. Container query 不替代 viewport query：页面骨架、导航、侧栏显隐仍由 viewport 或 layout state 控制。
5. 注意 container containment 对百分比尺寸、position、子孙查询和 sticky 场景的影响；不要把整个 page section 都随手设为 container。
6. RAG/设计系统条目应记录组件在 compact、regular、expanded 三种容器宽度下的内容优先级和测试截图。

设计判断

如果一个组件被放进卡片网格、抽屉、详情页侧栏和全宽内容区时都能保持同一任务含义，且不会通过缩小字号或挤压按钮来硬撑，这个组件才具备响应式契约。若组件必须知道页面路径才能正确排版，它还不是可复用组件。

实现建议

为每个 reusable module 写 container contract：最小可用宽度、推荐宽度、宽容器增强、隐藏/折叠规则、不可隐藏字段、交互替代和测试 viewport。CSS 中先定义基础 compact 样式，再用 @container (min-width: ...) progressively enhance；React 组件不要用 window.innerWidth 推导内部布局。图表组件在窄容器下提供数据表/summary fallback。

反例/风险

组件同时依赖 viewport 和父级 class 导致规则打架、容器名缺失命中错误祖先、在窄容器只缩小字体而不是重排、把重要操作藏进 hover、图表 legend 挤压绘图区、截图测试只覆盖全宽页面。

案例分析

MDN 将 container queries 定义为基于容器属性而不是 viewport/device 特征应用样式的方式；web.dev 的 Netflix case study 说明 container queries 帮助团队减少依赖 JavaScript 的布局控制，并提升组件在不同上下文中的灵活性。可学习点是：响应式设计从“页面尺寸适配”升级为“组件可放置性 contract”。

来源链接

MDN CSS Container Queries: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Containment/Container_queries MDN @container: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/%40container web.dev Container Queries: https://web.dev/learn/css/container-queries web.dev Netflix Container Query Case Study: https://web.dev/case-studies/netflix-cq