F2.15.4too many container breakpoints become unpredictable设计
过度细分的容器断点会造成组件行为难以预测
别名: 容器断点过多 · container breakpoint sprawl
概念解释
一张预告卡在 300 藏摘要、340 露一行、380 露两行、420 加上头像——自动填充网格里邻卡只差 20 px，看起来像两个组件。六个容器宽度，作者记不住 meta 何时消失、CTA 何时变图标；QA 也截不完。嵌套容器再乘一遍：卡在网格里、网格在侧栏里，同一组件一页上出现三张脸。
容器查询的好处是局部响应；切太细，局部变成随机。
机制
每个切换都是隐藏状态。状态一多，宽度到布局的映射不再是一张能讲的短表，变成要背的函数。自动填充让邻格宽度连续分布，函数在邻格上取到不同值，同一模块看起来不一致。嵌套时，外层容器和内层容器各自切，组合数是积。人无法预测「这一张为什么没有日期」，只会报 bug。
预测性死于「差一点宽度就换一套结构」。两三种结构、切换点隔得开，人还能建立模型。
边界
数据可视化、复杂工具栏内部可能真的需要多档，但那是专家表面，调用方是同一团队，映射可以写进内部手册。面向全公司复用的卡、列表行，切换超过三档就会在别的团队手里失控。动画过程中的中间宽不应再切一刀。
怎么落地
- 每个组件最多三种内部结构，两种更好。每个切换点必须对应一种失败（图文挤爆、按钮掉行、meta 不可读），对不上的合并。
- 禁止为「再多露一个字」加切换；那是流式或截断的事。
- 验证：把该组件从 200 px 拖到 700 px，每 20 px 截一张排成电影。相邻两帧若像两个产品，合并中间的切换。再把它放进三层嵌套（侧栏 > 网格 > 卡），数一页上出现几种脸。超过两种，减切换，直到同事不看代码也能说出「窄堆叠、宽横排」这种短规则。