R3.03.1container-based breakpoints设计
断点应基于容器而非仅视口
别名: 容器查询断点 · 槽宽而非视口 · container query breakpoint
概念解释
组件该在哪一档换布局，应当看它自己被分到的槽有多宽，而不是只看浏览器窗口有多宽。视口查询默认假设这块界面横跨整个窗口。仪表盘、分栏、侧栏里的卡片、嵌入的小工具，窗口可以很宽，槽可以很窄。同一张卡片在主栏里走多列、在侧栏里走单列，发生在同一视口里。
视口断点管的是外壳（整页导航、通栏头图）。槽里的组件若也绑在视口上，会在宽窗口的窄槽里误用「桌面」布局，或在窄窗口的宽槽里误用「手机」布局。
机制
@media 读的是视口。组件真正能用的是父级分给它的宽度。两者只在组件碰巧拉满窗口时重合。分栏、网格、可调分隔条、嵌入式小组件让它们经常不重合：桌面视口下侧栏可能只有 280px，主栏有 900px。绑在视口上的卡片会在侧栏里仍按 900px 那档排，挤出溢出或小到不能点的控件。
以容器宽度为断点，同一套卡片规则在侧栏和主栏各自触发，不要求窗口先变。窗口没变、槽变了（拖分隔条、从单栏换成双栏外壳），布局也会跟着变。响应的对象是可用宽度，不是设备名，也不是「现在像不像手机」。
边界
确实拉满窗口的外壳——全宽导航、通栏营销头、整页画布——视口仍是那个容器，用视口查询没有错。邮件、部分 WebView、旧环境没有容器查询时，退回视口是环境限制，不是设计选择；这些环境里应避免把同一组件同时塞进差别很大的槽。原生窗口把窗口宽度当作容器，和「再套一层视口」不是一回事。打印页的容器是纸张，不是屏幕视口。极窄的装饰条（图标轨）不应套用内容卡片的容器断点，那一套是为可读内容槽写的。
怎么落地
- 先标出会出现在多种槽宽里的组件（卡片、筛选条、数据表工具栏），给它们写基于槽宽的换档，而不是复用页级视口档。
- 页级外壳继续可以用视口；不要把外壳档位复制进每一个子组件。
- 在设计里同时画「宽窗口 + 窄槽」和「宽窗口 + 宽槽」，避免只提供按设备框起来的画板。
- 验证：固定一个桌面视口，把同一组件放进侧栏和主栏。两处布局应能按槽宽分开。两处长得像按同一个视口档算出来的，就是断点还绑在窗口上。