嘿，这两个问题都是移动端交互设计里的常见疑问，我来给你掰扯清楚～

• 交互语义冲突：Bottom Navigation的核心是切换独立的顶级功能模块（比如首页、消息、我的），用户点击它的预期是跳转到完全不同的功能域；而ViewPager的横向滑动是同一模块内的内容分页（比如首页的推荐、热点、关注），滑动的预期是浏览同类型的更多内容。混用的话，用户可能会搞不清自己到底是在同一模块内翻页，还是切换了整个功能区，认知成本蹭蹭涨。
• 状态管理混乱：每个Bottom Navigation对应的页面如果嵌套ViewPager，切换回来的时候很容易丢失ViewPager的当前页码、滚动位置这些状态。虽然可以通过ViewPager2的saveState()/restoreState()或者ViewModel来处理，但额外增加了开发复杂度，而且稍有不慎就会出现状态错乱的bug，用户体验直接拉胯。
• 违反导航层级逻辑：主流的移动端设计规范里，Bottom Navigation是明确的顶级导航控件，负责区分最核心的几个功能入口；而ViewPager属于内容层级的控件，用来组织同一功能下的细分内容。把两者绑定，相当于把“导航切换”和“内容分页”混在了一起，打破了清晰的层级结构，用户很容易迷路。

• 违背用户操作预期：在移动端，横向滑动几乎已经成为“浏览同一内容集合内更多项”的默认交互（比如电商的商品横向列表、新闻的专题分页）。如果用横向动效来做不同视图（比如从首页跳转到消息页）的过渡，用户会产生困惑：我到底是在翻同一块内容，还是跳了新页面？这种预期不符会让用户觉得交互“不贴心”。
• 视觉认知负担大：移动端屏幕宽度有限，横向动效在切换视图时，需要把整个页面从一侧滑入滑出，视觉上的位移距离长，用户需要追踪整个页面的变化，容易产生视觉疲劳，甚至对有前庭功能障碍的用户不友好（比如眩晕感）。相比之下，纵向或者淡入淡出这类过渡，视觉冲击更小，更符合移动端的空间特性。
• 破坏导航层级的清晰度：不同视图之间的过渡，本质是导航层级的切换（比如从顶级页面到二级页面，或者不同顶级模块切换）。横向动效的模糊性，会让用户无法清晰感知自己当前处于哪个导航层级，时间长了就会对APP的结构产生混乱感，降低使用效率。
• 可访问性问题：对于依赖屏幕阅读器的用户，横向动效的页面过渡可能无法被正确识别为“页面切换”，而是被当成了同一页面内的内容滚动，导致辅助技术无法准确播报当前页面的信息，影响可访问性。

内容的提问来源于stack exchange，提问作者user6138916