F2.15.1container queries vs viewport breakpoints设计
容器查询让组件依据自身可用空间而非视口断点响应
别名: 容器查询 · @container · container query
概念解释
同一视口里，侧栏 300 px、主栏 900 px。一条媒体对象组件若只听视口断点，两边都会变成「桌面：图在左」。侧栏里其实只有 300 px，图在左会把字挤没。容器查询量的是组件自己拿到的宽，侧栏里的那份可以改成上图下文，主栏里的那份保持左右。视口断点看不见分栏之后还剩多少。
选视口失效点、中间宽度要可用，是页面壳的事。组件问的是另一把尺：我的父容器。
机制
@media 读窗口。组件不知道自己被分到了窗口的哪一块——侧栏、分屏、网格单元格都把视口切碎。容器查询读最近的容器查询容器的内宽，那才是组件真正能用的空间。同一帧里，同一组件类可以处于不同的容器宽度，因此可以处于不同的内部布局。
这不是把视口断点抄到组件上。视口 1200 时四个 280 px 的格子，对组件来说仍是「窄」，不是「桌面」。
边界
还没有容器查询的老引擎只能退回视口查询或靠父组件传宽度，行为会和现代引擎分叉，要接受降级。页面壳（是否出侧栏、是否汉堡）仍该看视口，因为那是窗口级信息架构。根容器若等于视口，容器查询退化为媒体查询，没有额外收益。
高度容器查询比宽度少见，且易和内容高度互相依赖，造成循环，需要小心。
怎么落地
- 给会被放进不同槽的组件加上容器查询，查询条件写它内部结构开始坏的宽度，不要写 768 这种视口习惯数。
- 页面级媒体查询只留给壳：导航形态、分栏数。不要用视口媒体查询去改内层卡片的图文结构。
- 验证：同一页里把该组件放进窄侧栏和宽主栏。两份若长得一样（都「桌面」或都「手机」），它在听视口。侧栏堆叠、主栏左右，才是在听容器。再拖分屏分隔条，只改容器宽、不改窗口，组件应跟着变。