F2.11.3scoped mix of fluid and adaptive设计
两者混用需明确各自的作用范围
别名: 流式自适应混用 · hybrid responsive
概念解释
常见做法是：壳在几个宽度跳变（汉堡 / 侧栏 / 双栏），栏内的列和字号跟着宽度流。混用没问题，前提是写清谁在跳、谁在流、哪一段宽度。混乱来自同一属性有时流有时跳：页面在 900 px 自适应成两列，内层卡片网格却用 auto-fill 自己流出三列，作者和测试都无法预测这一宽上到底几列。
范围不清，产品会在同一视口里同时表现成两套策略。
机制
流式和自适应是两种时间尺度。连续插值改尺寸，离散跳变改拓扑。属性（列数、导航形态、padding、字号）必须被标成其中一种，并标上生效的宽度区间。同一属性在同一区间既跳又爬，预测模型就没了：QA 不知道该截采样点还是该拖，开发不知道该写媒体查询还是写分数。
嵌套是重灾区。页面级自适应和组件级 auto-fill / 容器查询叠在一起，外层说「现在是桌面两栏」，内层说「我有 280 px，我要堆叠」。两者都对，页面看起来像坏了。
边界
完全只用一种策略的小站点不需要这张分工表。设计系统一旦被多个团队拿去嵌套，分工表就变成接口：壳团队管跳，组件团队管流，或反过来，但不能两边都对列数负责。
动画可以从一种结构过渡到另一种，那是跳变的可视化，不等于该属性变成了流式。
怎么落地
- 做一张模块 × 属性 × {流 | 在 W 跳} 的表。列数、导航、字号、padding 都要填。同一格填了两种的，拆区间或删掉一种。
- 禁止页面媒体查询和内层 auto-fill 同时决定「几列」而不写谁优先。
- 验证：按这张表抽查。声称在流的属性，拖 40 px 应平滑变，不应跳；声称在跳的属性，只应在写下的 W 变拓扑。发现既跳又爬的属性，记下宽度，改表直到一种行为。再在嵌套最深的那块（侧栏里的卡网格）看列数是否还能从这张表推出来——推不出来就还没分工完。