F2.10.3breakpoint count multiplies QA cost设计
断点数量增加会成倍增加验证成本
别名: 断点组合爆炸 · breakpoint matrix
概念解释
四个断点不是「多画四张稿」，是页面数 × 方向 × 状态 × 断点。二十个页、两种方向，已经一百六十个布局状态要看。从框架抄来 xs / sm / md / lg / xl / xxl，再乘一遍。多出来的断点如果没有对应的内容失效，就是纯成本。
数量本身会成倍放大验证，这条不讨论某个断点该不该在 900 还是 768——那是失效点怎么选。
机制
布局状态和其他变异是笛卡尔积：方向、语言（德文拉长）、空/满数据、键盘弹出、分屏。每加一个断点，就把这个积再乘一维。人的评审和自动化截图都按积走，不是按和走。所以「多一个断点更精细」的直觉，会在第三、第四个断点之后变成测不完。
测不完的结果是中间宽度反而没人看——和「断点之间要可用」对着干。断点越少、每个都对应真失效，中间槽才有精力去拖。
边界
真正有多套信息架构的产品（桌面侧栏 + 平板双栏 + 手机单栏 + 折叠展开）可能需要三个结构跳变，那不是抄来的六个。组件级的容器断点不进这个视口矩阵，不该算进「页面断点数量」。
打印样式、深色、高对比是另外的轴，也会乘；它们不是断点，但提醒你：能不加的视口采样就不要加。
怎么落地
- 每个视口断点写一句「它修复哪个模块的哪种坏法」。写不出的删除，合并到相邻失效点。
- 把验证矩阵画出来：断点数 × 关键页 × 方向。超过团队一周能过完的，先减断点，再谈覆盖。
- 验证：删掉一个讲不出失效的断点，回归拖拽全程。若没有新的溢出或半列，这个断点就是成本。留下的每一个，都要在矩阵里占一列，并且那一列有人真的点过主路径。