做Android开发的人十有八九在ScrollView里套过RecyclerView然后被滑动冲突折磨过。这个问题的报错不一定有但表现很明确要么RecyclerView滚不动要么ScrollView滚不动要么两个一起抢事件、页面滑动像抽风。网上搜“嵌套滑动冲突”帖子无数方案五花八门但很多拿下来要么治标不治本要么引入新的性能坑。这篇文章不打算只给你贴一段代码就完事我会把事件分发原理、四种可行方案、每种方案的坑和适用场景全部拆开讲清楚。看完以后你至少知道为什么冲突、哪个方案适合哪种页面、以及怎么从根上避免踩坑。1. 滑动冲突的本质事件分发与嵌套滑动的底层逻辑1.1 事件分发三步曲dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent安卓的触摸事件从诞生那一刻起就有一个明确的派发规则理解这条规则是解决一切冲突的前提。事件从Activity往下走经过PhoneWindow、DecorView一路传到各个ViewGroup最后才能到达具体的View。每一层ViewGroup都有两个核心机会参与决策dispatchTouchEvent负责派发onInterceptTouchEvent负责决定要不要把事件拦下来自己处理onTouchEvent则负责最终消费。这三个方法之间的关系我常用一个“快递派送”的类比讲给团队新人快递到了小区门口先由门卫ViewGroup.dispatchTouchEvent决定要不要直接收下。门卫有自己的判断标准onInterceptTouchEvent如果他说“这件快递是我要的”那快递就直接留在门卫这楼上的住户子View永远摸不到。如果门卫不认得这个快递那快递继续往楼上送一层一层往下问直到某一层住户说“这是我的快递”onTouchEvent返回true事件才算有了归属。这个机制里的关键是一次完整的手势序列通常从ACTION_DOWN开始后续的ACTION_MOVE、ACTION_UP都会跟第一个拿到DOWN事件的View绑定。如果ViewGroup在DOWN时不拦截但在MOVE时突然改变主意拦截了系统会先给子View发一个ACTION_CANCEL然后把后续事件全部交给ViewGroup。这就是很多“滑动到一半突然失灵”现象的根源。1.2 冲突是怎么产生的ScrollView的拦截判定ScrollView是一个纵向滚动的FrameLayout它的滑动依赖事件拦截机制。简单看一下它的onInterceptTouchEvent逻辑就能明白问题。当手指按下并开始移动时ScrollView会计算当前事件和上次事件在Y轴上的位移差一旦这个差值超过了一个叫做TouchSlop的阈值——通常由ViewConfiguration.getScaledTouchSlop()给出大约是8dp左右——它就认为用户是想滚动页面于是返回true把事件拦截下来。关键在于ScrollView做这个判断时根本不在乎手指此刻是按在RecyclerView上还是按在普通TextView上。它只关心自己能不能滚动、位移量是否达标。在一个标准布局里ScrollView的内容高度大于屏幕高度所以它永远是“可滚动”的于是手指在RecyclerView上轻轻一划ScrollView就把事件抢走了。事件被抢走之后RecyclerView会收到一个ACTION_CANCEL随后所有MOVE事件都由ScrollView消费。结果就是RecyclerView内部的列表内容纹丝不动整个页面倒是被ScrollView滚来滚去这和你把手指放在页面空白区域滑动时的效果一模一样。这就是你遇到的第一个冲突表现。1.3 NestedScrolling本该协调的机制为什么还会失效Android 5.0之后引入了NestedScrolling嵌套滑动机制为的就是解决这种“父View抢事件、子View没机会”的尴尬。RecyclerView是NestedScrollingChild它会把自己的滚动意图通过startNestedScroll、dispatchNestedPreScroll等方法通知给实现了NestedScrollingParent的父View。理论上子View和父View可以协商先让父View滚动父View滚不动了再让子View滚反之亦然。可惜这套机制救不了ScrollView嵌套RecyclerView的经典场景。标准ScrollView虽然实现了NestedScrollingParent接口API 21起但它的onInterceptTouchEvent拦截逻辑并没有在嵌套场景下做特殊优化。它照样在位移超过TouchSlop的那一刻直接拦截连协商的机会都不给。而且事件一旦被拦截后续的嵌套滑动回调基本都没有意义了。这也是为什么很多人从ScrollView换成androidx.core.widget.NestedScrollView之后冲突现象有所缓解。NestedScrollView本身就是针对嵌套滚动场景设计的它对子View的滚动能力有更多感知配合RecyclerView的嵌套滑动通知确实能形成一套相对顺滑的协商流程。但官方组件之间能处理好不代表业务代码不用管如果RecyclerView不关闭嵌套滑动在复杂的页面层级里仍然会出现“滚动不跟手”或者“两个滚动容器来回拉扯”的感觉。这里面的细节我会在后面的方案实战里详细说。2. 方案选型从“能跑”到“彻底”的四种思路先声明我个人的立场既然冲突的根源是“两个垂直方向都能滚动的容器叠在一起”那最彻底的办法就是“别叠在一起”。基于这个立场我把社区里常见的方案分成四个梯队按照推荐程度从高到低排下来。2.1 方案一单一RecyclerView加多ItemType架构上消灭冲突这个方案我放在第一位因为它是让我感觉最踏实的。做法很直接把原来ScrollView里的一大坨内容拆成一个RecyclerView的几个ItemType。比如页面顶部原来是Banner、中间是一组宫格入口、下面是一段普通图文列表那就把这些内容都塞进同一个RecyclerView用不同的ViewHolder承载不同视觉区块。好处是显性的整个页面只有一个可滚动容器事件分发路径变得极其干净压根不存在“两个容器抢事件”的问题。性能也比嵌套方案好得多RecyclerView的复用机制会在滚动过程中回收不可见Item内存占用和初始化速度都远优于“一次性渲染所有子View”的嵌套方案。缺点只有一个你需要把原来的静态内容改造成Adapter的Item代码结构上会多一些类型判断和ViewHolder类。这个方案的适用面其实比想象中大。电商首页、新闻详情页、信息流Feed天然就是多区块组合用单一RecyclerView管理再合适不过。甚至连“下拉刷新、吸顶标签、加载更多”这些交互都可以通过多ItemType加监听器的方式在同一个RecyclerView里实现。2.2 方案二NestedScrollView加RecyclerView快速但需控数据量如果页面结构已经定死短期内又不想大改NestedScrollView嵌套RecyclerView是一个能落地的快速方案。核心就两行代码布局里用NestedScrollView替换ScrollView代码里给RecyclerView调用setNestedScrollingEnabled(false)。但我要提醒一句这个方案的本质是“关闭RecyclerView的嵌套协作能力让它老老实实接受父容器的高度测量”。这会导致RecyclerView把所有可滚动区域一次性测量并渲染出来不再复用ViewHolder。列表数据量是几十条、Item又简单那没问题一旦是几百上千条、每项还带图片和复杂布局初次加载就能让你感受到明显的卡顿极端情况下还会直接OOM。所以这个方案适合“确认数据量不大”的场景比如商品详情页底部的那几个相关推荐、个人信息页里的几个设置分组。2.3 方案三自定义ScrollView按触摸目标决定是否拦截有些场景绕不开原生ScrollView或者项目历史包袱太重。这种时候可以自己写一个ScrollView子类在onInterceptTouchEvent里判断当前触摸点是否落在RecyclerView区域内如果是就放行让RecyclerView自己处理事件。这个方案的思路是“按需分发”实现起来不复杂但它有一个天然缺陷RecyclerView被放行之后如果它已经滚动到自己内容的边界——比如顶部或者底部——剩下的滑动距离该怎么交给外层ScrollView这个“交接”逻辑很繁琐你做不好就会出现“滑到边界后页面愣住不动”的新问题。所以我通常建议这个方案只适用于“RecyclerView本身就占了ScrollView里将近全部高度基本不需要两层协作滚动”的情况一旦需要两层有来有回地接力就老老实实回到方案一或者方案二。2.4 方案四CoordinatorLayout联动复杂页面交给Behavior当页面需求远不止“滚动”这么简单比如顶部要有一个可折叠的头部滚动过程中头部逐渐消失、标签吸顶、底部还有个跟手面板这时候NestedScrollView和自定义ScrollView都撑不住应该直接上CoordinatorLayout。CoordinatorLayout配合AppBarLayout和RecyclerView提供的AppBarScrollingViewBehavior可以靠Behavior来协调两个滚动组件的嵌套滑动关系。这个方案的优势是场景覆盖率极高很多大型App的首页和详情页就是这套组合撑起来的代价是理解成本高Behavior的自定义开发有门槛布局层级也比普通方案复杂。如果你的页面未来会往“复杂动效、吸顶、折叠”方向演进早点迁到CoordinatorLayout比等需求来了再重构要省事得多。2.5 四方案对比短板和适用边界一目了然方案核心思路冲突解决程度性能风险实现成本推荐场景单RecyclerView多ItemType消灭嵌套彻底低中首页、信息流、富内容详情页NestedScrollView嵌套官方组件协作缓解高数据量大时低小数据量固定列表自定义ScrollView按触摸目标拦截中等中中特型布局、遗留代码改造CoordinatorLayoutBehavior协调滚动彻底中高折叠头部、复杂交互页面这张表看着简单但它背后是一个选型逻辑先看页面复杂度再看数据量级最后评估改造成本。如果没有特殊硬性约束单选或多项RecyclerView的组合永远是我的第一选择顺序。3. 方案一实战用多ItemType重构页面彻底告别嵌套这一章直接给你一套可以抄走用的核心代码。场景假设是这样的页面顶部有一块Banner轮播中间是一排四个入口宫格下面是一条条普通列表内容。老代码大概率是ScrollView套一层LinearLayout里面手写Banner、宫格和ListView。我这里把它全部改成单一RecyclerView。3.1 布局改造外层只剩一个RecyclerView新布局非常简单一个Activity的根布局直接就是一个RecyclerView下面这段XML就是全部?xml version1.0 encodingutf-8? FrameLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_parent androidx.recyclerview.widget.RecyclerView android:idid/main_recycler android:layout_widthmatch_parent android:layout_heightmatch_parent android:overScrollModenever android:clipToPaddingfalse android:paddingTop0dp / /FrameLayout注意我给RecyclerView设置了overScrollMode为never目的是在部分机型上避免滚动到边缘时的蓝色光晕这个纯属审美习惯不设也不影响功能。clipToPadding设为false的用途是“允许内容延伸到padding区域”如果后面要给列表底部留出虚拟导航条间距或者安全区域的空白这个属性会很关键。3.2 Adapter核心代码多个ViewHolder共存接下来是Adapter的定义。我建议写成静态内部类的形式每个ViewHolder对应一种ItemType。下面这段代码你可以直接复制到工程里然后把布局文件换成你自己项目的就行public class HomeAdapter extends RecyclerView.AdapterRecyclerView.ViewHolder { private static final int TYPE_BANNER 0; private static final int TYPE_GRID 1; private static final int TYPE_ITEM 2; private final ListObject data new ArrayList(); public HomeAdapter() { data.add(new BannerData()); data.add(new GridData()); // 后面继续添加普通列表数据 data.add(new ItemData(第一条)); data.add(new ItemData(第二条)); } NonNull Override public RecyclerView.ViewHolder onCreateViewHolder(NonNull ViewGroup parent, int viewType) { LayoutInflater inflater LayoutInflater.from(parent.getContext()); switch (viewType) { case TYPE_BANNER: return new BannerViewHolder( inflater.inflate(R.layout.item_banner, parent, false)); case TYPE_GRID: return new GridViewHolder( inflater.inflate(R.layout.item_grid, parent, false)); default: return new ItemViewHolder( inflater.inflate(R.layout.item_list, parent, false)); } } Override public void onBindViewHolder(NonNull RecyclerView.ViewHolder holder, int position) { Object item data.get(position); if (holder instanceof BannerViewHolder) { // 绑定Banner数据比如RecyclerView内部再嵌套一个横向滚动列表 } else if (holder instanceof GridViewHolder) { // 绑定宫格数据 } else if (holder instanceof ItemViewHolder) { ((ItemViewHolder) holder).title.setText(((ItemData) item).title); } } Override public int getItemViewType(int position) { Object item data.get(position); if (item instanceof BannerData) { return TYPE_BANNER; } if (item instanceof GridData) { return TYPE_GRID; } return TYPE_ITEM; } Override public int getItemCount() { return data.size(); } static class BannerViewHolder extends RecyclerView.ViewHolder { BannerViewHolder(NonNull View itemView) { super(itemView); } } static class GridViewHolder extends RecyclerView.ViewHolder { GridViewHolder(NonNull View itemView) { super(itemView); } } static class ItemViewHolder extends RecyclerView.ViewHolder { TextView title; ItemViewHolder(NonNull View itemView) { super(itemView); title itemView.findViewById(R.id.item_title); } } }这段代码里有几个容易被忽略的细节。第一个是getItemViewType里我直接用instanceof判断这个方法简捷但缺点是每调一次都要遍历判断数据量大的时候可以改成用position范围判断比如“position 0就是Bannerposition 1就是宫格其余都是列表”性能更好也更好读。第二个是onCreateViewHolder里每个类型都Inflate自己的布局这里千万注意parent参数不能传null否则生成的布局参数会丢失RecyclerView会按错误尺寸去摆放Item。3.3 数据绑定的位置陷阱position不等于列表下标很多从ListView时代转过来的开发者在RecyclerView里最容易踩的坑就是把onBindViewHolder里的position当成普通列表的下标直接用。这个习惯在现代RecyclerView里很危险因为多ItemType的页面里position是包含所有类型Item的总序号不是某种子列表的序号。比如数据源里有两个Banner、五个宫格、三十条列表你在绑定列表Item时发现position7那它对应的其实是宫格里的第五个数据还是列表里的第五条只有你自己心里清楚。我的建议是不要在列表里维护一个单独的ArrayList然后靠position去映射而是把所有类型都放进同一个List里像示例代码那样用Object的统一容器绑定的时候用instanceof判断类型再取对应的数据对象。这样虽然多了一点类型判断但整个数据模型清晰多了。另一个细节是刷新数据时不要用notifyDataSetChanged无脑通知。多ItemType的页面里闪现、跳动、整体重绘的概率本来就高正确的做法是使用DiffUtil或者手动计算变更范围用notifyItemRangeInserted和notifyItemRangeRemoved精准更新。对于列表较长、Item较多的页面这一条几乎是必须的。3.4 加载更多与上拉刷新怎么融入多ItemType结构单一RecyclerView方案里还有一个经常被问到的问题加载更多怎么办最简单的做法是再加一种TYPE_LOAD_MORE在ItemType里单独留一个底部状态位。滚动到底部时由滑动监听触发放数据数据回来后把加载更多Item从“加载中”变成“没有更多了”或者直接移除。这里我强烈建议用addOnScrollListener而不是OnScrollListener的旧接口。AndroidX的新接口把回调拆分成了更细粒度的方法在onScrolled里判断canScrollVertically(1)是否返回false就能知道是不是到底了。实际开发中滚动到底部的判断我会加一个提前量当lastVisibleItemPosition itemCount - 3时就触发预加载用户体验比完全到底再加载要顺滑得多。4. 方案二实战NestedScrollView嵌套的正确姿势和性能红线如果你接手的是一个短期要上的页面不想大改NestedScrollView嵌套RecyclerView是最快的降级方案。这一章把正确姿势和性能红线讲透。4.1 布局和代码只差一个关键开关改法非常简单先把外层ScrollView标签换成androidx.core.widget.NestedScrollView它的子容器照旧是LinearLayout里面放你原来的Banner、宫格等内容最下面放RecyclerView高度写wrap_content。然后给RecyclerView加一行recyclerView.setNestedScrollingEnabled(false);这行代码是整套方案的核心。关闭嵌套滑动之后RecyclerView不会再向父NestedScrollView发送滚动前的预通知而是把自己当成一个普通的、高度为wrap_content的内容区块老老实实待在NestedScrollView里。手指滑动时NestedScrollView作为唯一的外层滚动容器接管整个页面的滚动RecyclerView不再尝试自己滚动。你可能要问那列表内容还能不能滚答案是能但它是跟着整个页面一起滚的没有独立的滚动区域这也正是这个方案和普通滚动行为最大的区别。4.2 为什么要关掉嵌套滑动而不是好好开着一个官方组件很多人不理解为什么用了NestedScrollView还要关掉RecyclerView的嵌套滑动。原因是如果开着嵌套滑动RecyclerView和NestedScrollView会同时参与事件的协商在页面里来回扯皮。实际体验到的情况是手指在RecyclerView上滑动时列表内容先滚滚到边界后页面再滚这个“接力”过程需要精确的位移量计算一旦某个版本号、某个机型上计算出偏差就会出现滚动不跟手、划一下页面飞出去一大截的现象。关闭嵌套滑动则让整个页面的行为退化为一个朴素的ScrollView手指滑动页面滚动没有中间态体验和之前的“ScrollView套ListView”的老时代完全一致。同时这个关闭操作也让RecyclerView变成彻底的一次性测量渲染因为父容器NestedScrollView的高度测量模式会给子View一个UNSPECIFIED的MeasureSpecRecyclerView会把所有Item的高度全加起来当成自己的高度。4.3 性能红线数据量多少算“不能忍”一次性渲染带来的性能代价是这套方案最需要警惕的地方。RecyclerView不复用ViewHolder意味着每一个Item包括每一条数据对应的布局都要被实例化。50条以内你可能感知不到差异但到了200条以上初次加载就会从原来的“碎片化渲染”变成“一次性全部Inflate”卡顿是必然的。我自己的判断标准很粗暴Item类型简单单个TextView、ImageView加一行文字、数据量小于100条可以用这个方案Item带复杂布局、有网络图片、数据量可能增长到几百上千条想都不要想。另外提醒一个隐蔽坑RecyclerView的数据在NestedScrollView方案里如果加载了全量数据而且Item高度不固定那页面底部的内容会随着图片异步加载不断“顶下去”用户滑动到底部时可能发现内容还在增长。解决这类问题要么固定Item高度要么改用占位图保证布局稳定这在电商详情页里特别常见。4.4 适合用这套方案的典型页面我自己实际用过并且觉得舒服的场景有这么三类第一类是App设置页这种页面Item数量少、结构固定、不需要复杂滚动动画用NestedScrollView嵌套一个两三层的小列表非常轻量。第二类是电商商品详情页顶部是商品大图、中间是属性参数表格、底部是一些推荐商品内容整体高度可控且数据量不会爆炸。第三类是登录注册、用户协议这种简单页面内容固定完全可以在ScrollView里放一个RecyclerView展示条款列表。反过来说如果你的页面是“无限刷新”的Feed流、聊天记录、订单列表就算短期内数据量不大也千万别用这个方案因为产品不会答应数据量永远不涨。5. 方案三实战自定义ScrollView按触摸目标放行事件如果项目里确实没办法把ScrollView换成NestedScrollView或者改成单RecyclerView自定义ScrollView是一个“针对性规避”的招法实现起来比较直接。我放在第三个讲因为它虽然代码少但局限性明显。5.1 核心实现在onInterceptTouchEvent里判断触摸点思路是重写onInterceptTouchEvent当手指按下的目标是RecyclerView时直接返回false不拦截把事件直接交给RecyclerView去消费。下面是核心代码public class InterceptScrollView extends ScrollView { public InterceptScrollView(Context context) { super(context); } public InterceptScrollView(Context context, AttributeSet attrs) { super(context, attrs); } Override public boolean onInterceptTouchEvent(MotionEvent ev) { if (isTouchOnRecyclerView(ev)) { return false; } return super.onInterceptTouchEvent(ev); } private boolean isTouchOnRecyclerView(MotionEvent ev) { if (getChildCount() 0) { return false; } View content getChildAt(0); if (!(content instanceof ViewGroup)) { return false; } ViewGroup container (ViewGroup) content; float x ev.getX(); float y ev.getY(); for (int i 0; i container.getChildCount(); i) { View child container.getChildAt(i); if (child instanceof RecyclerView x child.getLeft() x child.getRight() y child.getTop() y child.getBottom()) { return true; } } return false; } }这段代码没什么高深技巧就是把event坐标和RecyclerView的边界做一次包含判断。要注意的是getX和getY拿到的是相对于ScrollView自身的坐标所以判断子View边界时直接用child.getLeft和getTop即可不需要再做坐标转换。如果你的ScrollView里嵌套了两层布局再用坐标循环判断会更稳妥。5.2 局限性RecyclerView滚到边界后的“交接”难题这套方案最大的坑是RecyclerView滚动到边界时的处理。假设页面结构是“上方一大段说明文案中间是RecyclerView下方是其他内容”。用户手指在RecyclerView上向下滑RecyclerView内部滚动一直滑到列表末尾这时候用户继续往下滑期望的是外层ScrollView接管让整个页面向下翻动把RecyclerView下面的内容露出来。但我的代码是“只要触摸点在RecyclerView区域内就不拦截”事件全部给了RecyclerViewRecyclerView已经没有可滚动的距离了于是页面卡住。解决这个问题的思路是在RecyclerView这边做增强重写它的onTouchEvent或者dispatchTouchEvent检测到canScrollVertically(1)为false时主动请求父ScrollView处理后续事件。但这个“主动请求”的处理非常繁琐要在MOVE事件里实时判断、动态修改拦截状态稍不留神就会引入新的跳跃和抖动。我试过的实际做法是先判断RecyclerView能否继续向下滚动不能的话调用getParent().requestDisallowInterceptTouchEvent(false)允许父View重新获得拦截权但代码的健壮性还需要多机型验证。5.3 什么时候才值得用这个方案我个人对这个方案的使用态度很保守。它只适合一种情况RecyclerView在ScrollView里占据了几乎整屏的高度而且列表数据量本身不小不能关掉嵌套滑动但又没有时间做大改造的临时项目。比如一个直播间的消息滚动列表上面是一个视频区域下面是RecyclerView聊天消息消息量很大且滚动频繁中间还有大量消息不断插入。这种场景里用户的大部分交互都发生在RecyclerView区域内外层ScrollView只是给了一个有限的剩余空间事件“偶尔”需要分给外层用自定义ScrollView按目标放行是合理的。一旦页面需要两层频繁接力滚动别犹豫直接切回方案一。6. 实战中的坑与排查记录我从项目里踩过的那些坑滑动冲突类问题在开发中最容易让人破防的是“现象一堆原因藏在很底层”。这一章我把这几年在真实项目里遇到过的代表性坑和排查思路整理一下给你当速查手册。6.1 滑动乱象快速排查表下面这几条是我自己整理的最常见问题对照表发现问题先对着找能省很多时间。现象可能原因排查方向RecyclerView内容完全滚不动ScrollView抢走了事件给RecyclerView设置嵌套滑动开关或改用NestedScrollView整个页面跟着RecyclerView一起飞RecyclerView关闭嵌套滑动后高度等于所有Item总高确认数据量考虑换单一RecyclerView方案滑动到一半突然跳一下父View先放行后拦截触发ACTION_CANCEL检查onInterceptTouchEvent里是否在MOVE阶段改了返回值列表滑到底后外层页面“卡住”RecyclerView可滚动距离用完但事件不释放自定义ScrollView方案中需要增加边界检测和事件交接页面初始化时肉眼可见卡顿RecyclerView在嵌套布局中一次性渲染所有Item缩小数据量或改用多ItemTypeItem点击失效或触发长按父View拦截机制影响手势识别检查自定义拦截逻辑和requestDisallowInterceptTouchEvent使用Activity切换时崩溃且报RecyclerView相关异常布局中RecyclerView未设置LayoutManager或Adapter检查初始化时layoutManager和adapter是否为空6.2 为什么手指在RecyclerView上“不跟手”有段时间我在开发一个详情页里面的RecyclerView放在NestedScrollView里默认开着嵌套滑动。用户反馈“列表滑动很绵手指都快划出屏幕了列表才慢慢走松手后还会滑好久”。排查的时候我先怀疑是不是LayoutManager设置了smoothScroll查了一圈发现不是最后定位到问题出在嵌套滑动的消费比例上。NestedScrollView作为父View会参与RecyclerView的滚动过程RecyclerView每次滚动一段距离都会先询问父View要不要消费父View消费掉一部分剩下的再由RecyclerView执行。如果父View消费的位移量计算有偏差手指移动的物理距离和列表实际滚动的距离就会对不上造成“不跟手”的感觉。这个问题的正解就是在不需要双层滚动的页面里直接setNestedScrollingEnabled(false)让RecyclerView和父容器彻底解耦。6.3 数据刷新后位置跳动的根源多ItemType页面里新手最容易遇到的一个问题是下拉刷新或者插入新数据后整个列表突然跳到顶部或者跳到奇怪的position。原因通常是直接调用notifyDataSetChanged所有Item被整体重绘而getItemViewType和onBindViewHolder里如果用了旧的position逻辑数据位置就乱了。我的处理习惯是重写getItemViewType时不用总索引去猜类型而是用数据对象本身携带的类型字段绑定数据时也不依赖position和ArrayList的映射而是从统一List里取出对象再分支处理。刷新时优先用DiffUtil它会把新旧列表的差异算清楚再调用精准的notifyItemRangeInserted、notifyItemRangeRemoved这样列表的滚动位置自然稳定。这个坑看着不大但排查起来非常浪费时间。6.4 滑动验证还不完善的边缘场景最后说几个容易漏掉的边缘场景都是我在测试中踩过的。第一RecyclerView放在ScrollView中时外层ScrollView滚动到边界后继续下拉部分机型的阻尼效果表现不一致不要在这个阶段做过于复杂的自定义阻尼动画。第二如果页面嵌入了EditText软键盘弹出、收起会导致ScrollView重新测量高度RecyclerView如果有固定高度可能会出现内容偏移排查时需要关注adjustResize相关配置和软键盘监听。第三多ItemType页面如果嵌入了ViewPager2或者横向滚动的子RecyclerView事件方向不同会带来新的二级冲突排查时优先确认为什么方向的事件会被错误消费。7. 我的最终建议与一点实话这篇文章从事件分发原理讲到了四种方案的代码核心只有一句话能不用嵌套就不用嵌套能用一个RecyclerView装下所有内容就别整ScrollView。嵌套方案不是不能碰但它需要你清楚数据量的边界、版本兼容的范围和滚动体验的取舍。如果你现在的页面正好是电商首页、内容详情页这种“Banner加宫格加列表”的结构大胆用多ItemType重构把嵌套彻底删掉你会回来感谢这个决定。如果只是临时要上线的小模块就用NestedScrollView加setNestedScrollingEnabled(false)顶住同时心里要有一条明确的数据量警戒线一旦产品说“再加一点推荐位”、“列表数据量再翻一倍”立刻切换到单一RecyclerView方案。最后再分享一个小技巧排查滑动冲突时不要只看onInterceptTouchEvent记得在dispatchTouchEvent和onTouchEvent里打上日志把每一次事件的动作、坐标、返回值都记录下来。事件分发这条链路很短但变量很多日志里的一次ACTION_CANCEL往往就是问题真正的起点。这条经验我用了好几年比翻源码高效得多。