C1.23.2Horizontal scroll affordance设计
横向滚动通常需要显式的横向内容或修饰键，否则被忽略
别名: 横向滚动 · 修饰键 · 内容溢出
概念解释
横向滚动只有在容器确有可访问的横向溢出、横向轨道或明确交互约定时才有意义。许多纵向阅读界面会忽略横向两指位移，或要求 Shift 等修饰键把滚轮转为横移，避免轻微斜滑造成无意义的页面抖动。
机制
滚动容器根据可滚范围、主滚动轴和系统事件决定是否消费横向增量。没有横向内容时消费它只会制造死操作或与导航冲突；有嵌套横向列表时又需决定由内层还是外层接收，清晰边界与可见提示帮助用户预测结果。这里还有一层更硬性的约束：不少支持触控板的系统本身就把横向双指滑动预留给了"返回上一页/前进下一页"这类系统级导航手势，应用如果直接拿原始的横向位移量去驱动页面内的横向滚动，等于在和一个优先级更高、由系统而不是应用决定归属的手势抢同一份输入信号，这不是应用调整阈值能单方面解决的，而是从一开始就该避免让内容层的横滚和系统导航手势共用同一种触发方式。
边界
忽略横向输入不意味着横向内容不可达：可用滚动条、箭头、分页或拖动。反之，显式横向内容也不应完全隐藏纵向主任务；过多横滑区域会增加手势竞争和发现成本。一个具体的边界情况是内嵌横向轮播已经滚动到最左或最右端：此时用户继续往同一方向划动，如果容器仍然把这段输入当成"已到边界、什么都不做"吞掉，用户就会感觉手势失灵；比较合理的处理是在到达自身可滚动范围的尽头后，把后续的同向输入交还给外层，允许它被系统导航手势接管，而不是让输入停在一个既不移动内容、又不触发任何后续动作的死角里。
怎么落地
- 仅对真实横向溢出容器启用横滚，并显示边缘裁切、轨道或箭头线索。
- 为横向内容提供按钮、拖动条和键盘替代，不只依赖斜滑手势。
- 验证办法：专门测试横向轮播已滑到自身可滚动范围尽头之后再继续同向划动的情况，确认这段输入被正确交还给外层或系统手势，而不是被无声吞掉。