嵌套滑动冲突：RecyclerView 嵌套 RecyclerView 的解决方案
说实话，嵌套滑动冲突这个问题，几乎是每个做复杂列表页面的 Android 开发者都会遇到的坎。我记得刚入行那会儿，产品经理丢过来一个需求：首页要展示多个分类，每个分类下面又有横向滚动的商品列表。我当时想都没想，直接 RecyclerView 套 RecyclerView，结果一跑起来……嗯，滑动体验简直灾难。
今天我们就来彻底聊聊这个问题。我会把我在项目中踩过的坑、试过的方案，以及最终沉淀下来的最佳实践，一次性讲清楚。
为什么会发生嵌套滑动冲突？
你想想看，两个 RecyclerView 嵌套在一起，手指一滑，到底该让谁响应？父 RecyclerView 想上下滚动，子 RecyclerView 也想上下滚动（或者横向滚动），系统就懵了。说白了，这是 Android 事件分发机制在作祟。
Android 的触摸事件是从外层 View 向内层 View 传递的。如果内层 View 消费了事件，外层 View 就收不到了。但 RecyclerView 本身有自己的一套滑动逻辑，它不会轻易把事件交出去。这就导致了「抢事件」的局面。
核心矛盾：父 RecyclerView 需要上下滑动，子 RecyclerView 也需要上下滑动（或横向滑动）。两者都想消费同一个触摸事件，冲突由此产生。
常见的嵌套场景
我在项目中遇到过三种典型的嵌套场景，每种的处理方式都不一样：
| 场景 | 描述 | 推荐方案 |
|---|---|---|
| 垂直嵌套垂直 | 父 RecyclerView 垂直滑动，子 RecyclerView 也垂直滑动 | 禁用子 RecyclerView 的滑动，或使用 NestedScrollView 包裹 |
| 垂直嵌套水平 | 父 RecyclerView 垂直滑动，子 RecyclerView 水平滑动 | 默认即可，但需处理事件拦截 |
| 水平嵌套水平 | 父 RecyclerView 水平滑动，子 RecyclerView 也水平滑动 | 类似垂直嵌套垂直，禁用子 RecyclerView 滑动 |
方案一：禁用子 RecyclerView 的滑动（最简单粗暴）
如果你确定子 RecyclerView 不需要独立滑动，那直接禁掉它的滑动能力就行。我个人习惯用这个方式处理「垂直嵌套垂直」的场景。
// 在代码中设置
childRecyclerView.isNestedScrollingEnabled = false
// 或者在 XML 中
android:nestedScrollingEnabled="false"这样做之后，子 RecyclerView 的所有滑动事件都会交给父 RecyclerView 处理。子列表的内容会全部展开，父 RecyclerView 负责整体滚动。
提示：禁用嵌套滑动后，子 RecyclerView 的 item 数量如果很多，会导致父 RecyclerView 的 item 高度非常大。建议配合「预加载」或「分页加载」使用，避免一次性渲染太多 View。
方案二：使用 NestedScrollView 包裹（适合简单场景）
如果你不想动 RecyclerView 的代码，可以用 NestedScrollView 把整个布局包起来。但要注意，NestedScrollView 本身不支持 RecyclerView 的缓存复用机制，性能会差一些。
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/parentRecyclerView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:nestedScrollingEnabled="false" />
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/childRecyclerView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:nestedScrollingEnabled="false" />
</LinearLayout>
</androidx.core.widget.NestedScrollView>警告：NestedScrollView + RecyclerView 的组合，如果数据量超过几百条，卡顿会非常明显。我曾经在一个电商首页用过这个方案，结果用户反馈滑动掉帧严重，后来不得不重构。
方案三：自定义事件拦截（最灵活，推荐）
如果你需要精细控制滑动行为，那就得自己动手写事件拦截逻辑。说白了，就是重写父 RecyclerView 的 onInterceptTouchEvent 方法，根据滑动方向决定是否拦截事件。
class NestedParentRecyclerView @JvmOverloads constructor(
context: Context,
attrs: AttributeSet? = null,
defStyleAttr: Int = 0
) : RecyclerView(context, attrs, defStyleAttr) {
private var lastX = 0f
private var lastY = 0f
override fun onInterceptTouchEvent(e: MotionEvent): Boolean {
when (e.action) {
MotionEvent.ACTION_DOWN -> {
lastX = e.x
lastY = e.y
// 不拦截 DOWN 事件，让子 View 有机会处理
return false
}
MotionEvent.ACTION_MOVE -> {
val deltaX = Math.abs(e.x - lastX)
val deltaY = Math.abs(e.y - lastY)
// 如果水平滑动距离大于垂直滑动距离，不拦截
// 这样横向滑动的子 RecyclerView 就能正常工作
if (deltaX > deltaY) {
return false
}
}
}
return super.onInterceptTouchEvent(e)
}
}这段代码的核心逻辑是：当手指水平滑动距离大于垂直滑动距离时，父 RecyclerView 不拦截事件，让子 RecyclerView 处理。反之，父 RecyclerView 拦截事件，自己处理垂直滑动。
关键点：不要拦截 ACTION_DOWN 事件。一旦拦截了 DOWN 事件，后续的所有事件都会直接交给父 View，子 View 永远收不到任何触摸事件。
方案四：使用 NestedScrollingChild 和 NestedScrollingParent 接口
这是 Android 官方提供的嵌套滑动机制。RecyclerView 本身就实现了这两个接口，所以理论上支持嵌套滑动。但实际使用中，默认行为并不总能满足需求，需要我们自己调整。
我建议的做法是：让子 RecyclerView 在滑动到边界时，把剩余的距离「汇报」给父 RecyclerView。这样就能实现「先滑子列表，滑到头了再滑父列表」的效果。
// 子 RecyclerView 的嵌套滑动辅助类
childRecyclerView.setNestedScrollingEnabled(true)
// 父 RecyclerView 需要重写 onNestedPreScroll 方法
// 在子 RecyclerView 滑动前，父 RecyclerView 可以先「消耗」一部分滑动距离这个方案比较底层，代码量也大。我个人只在需要「联动滑动」效果时才会用，比如类似淘宝首页那种「头部吸顶 + 列表滑动」的复杂场景。
SVG 流程图：嵌套滑动冲突解决思路
实战建议：我踩过的坑
最后，分享几个我在项目中实际踩过的坑，希望能帮你少走弯路：
- 不要滥用 NestedScrollView：我曾经在一个新闻资讯 App 里用 NestedScrollView 包裹了三个 RecyclerView，结果列表超过 200 条时，滑动卡顿到让人崩溃。后来全部改成了「禁用子 RecyclerView 滑动 + 分页加载」的方案，流畅度提升明显。
- 注意 ViewHolder 的复用：嵌套 RecyclerView 时，子 RecyclerView 的 ViewHolder 复用机制可能会失效。我建议在子 RecyclerView 的 Adapter 中显式设置
setHasStableIds(true)，并重写getItemId()方法。 - 性能监控不能少：嵌套滑动场景下，建议用
android:profileable="true"配合 Systrace 或 Profiler 工具，实时监控帧率。如果掉帧超过 16ms，就要考虑优化方案了。
我的个人习惯：在项目初期，我会先用「禁用子 RecyclerView 滑动」的方案快速实现功能。等产品逻辑稳定后，再根据实际体验决定是否需要换成「自定义事件拦截」方案。不要一开始就追求完美方案，迭代优化才是正道。
嵌套滑动冲突没有银弹。每种方案都有它的适用场景和局限性。你想想看，如果你的子列表只有三五个 item，那禁用滑动完全够用。但如果子列表有几十个 item，而且需要独立滑动，那就得老老实实写事件拦截。
嗯，以上就是我对 RecyclerView 嵌套 RecyclerView 滑动冲突的完整总结。希望对你有所帮助。