去年年底把一个 React Native 的新版本跑上 OpenHarmony 真机时第一个让我加班到凌晨的问题不是环境配置也不是包体积而是页面上那个看似人畜无害的 NestedScroll 滚动冲突。外层 ScrollView 里套一个 FlatList手指往上滑页面纹丝不动快速滑动时列表甚至会直接跳到最底部。这个问题在 Android 上我闭着眼都能解决但换到 OpenHarmony 上连排查路径都不一样了。这篇内容适合两类人看一类是在 OpenHarmony 上做 RN 应用适配、正在被滚动问题折磨的开发者另一类是只听说过 ArkUI 和 RN 能互通、但还没实际踩过坑的前端或客户端工程师。我会从事件分发的机制差异讲起把我在真机上调通 NestedScroll 的完整思路、代码配置和踩坑记录都摊开来说不绕弯子。1. 问题从哪来OpenHarmony 的滚动容器与 RN 手势体系如何互相误解先说结论OpenHarmony 上的滚动冲突本质上是两套“滚动世界观”在抢夺同一条触摸事件链路。RN 的 ScrollView 组件在原生层是一个自定义的 ViewGroup它遵循的是 Android 的 NestedScrolling 协议那套逻辑而 OpenHarmony 的 ArkUI 容器组件比如 Scroll、List、Grid走的是自己的手势系统和事件分发机制。两者互不认识冲突就来了。1.1 ArkUI 滚动体系的底层逻辑ArkUI 的滚动容器不是简单的 View它内部有一套基于手势识别的事件处理链路。你在 ArkUI 里写Scroll底层对应的是一个专门的滚动控制器它通过“手势绑定GestureBinding”来监听触摸事件然后翻译成滚动偏移量。关键点在于ArkUI 的滚动容器默认是自己消化触摸事件的。当手指在屏幕上滑动时触摸事件会被上层容器的手势识别器优先判断。如果外层是 Scroll它识别出这是纵向滑动趋势就会直接把事件认领走内层嵌套的 RN 列表根本拿不到后续的 move 事件。这和 Android 的 onInterceptTouchEvent 机制完全不同——Android 是父 ViewGroup 先看到事件决定要不要拦截而 ArkUI 是手势识别器之间竞争谁的规则优先级高谁获胜。所以你在 OpenHarmony 上遇到的现象往往是内层 FlatList 滚动倒是正常但手指刚贴上去轻轻一滑外层页面就开始滚了内层列表纹丝不动。这就是外层 Scroll 的手势识别器抢赢了。1.2 RN 手势事件如何在 OH 的触摸通道中流转RN 在 OpenHarmony 上的运行依赖的是 OpenHarmony 官方维护的 RN 适配层社区叫“react-native-oh”或者公司内部自研的接入层。这一层要做的事情是把 ArkUI 侧的触摸事件翻译成 RN 侧的 TouchEvent再转发给 JS 层的响应系统。这里有一个隐蔽的坑RN 的 ScrollView 在原生侧会自己处理滚动而它在处理时通常也会消费掉触摸事件。也就是说RN 原生视图一旦把事件消费了ArkUI 上层的 Scroll 手势识别器可能就收不到事件了。反过来如果 ArkUI 上层 Scroll 先用 Axis 方向判定了滚动意图RN 内层列表的手势识别就会直接被干掉。这形成了一个死结外层想滚内层也想滚外层抢了事件内层就滚不起来内层消费了事件外层页面就卡住。网上很多帖子说“用 NestedScrollView 包一层就好了”在 Android 上这招确实灵因为 RN 的 NestedScrollView 实现了 Android 的 NestedScrollingChild 协议能跟父容器协商。但 OpenHarmony 上根本没有这个协议你包了也白包——这就是为什么很多从 Android 直接搬过来的解决方案在 OH 上全部失效。1.3 生产环境最常见的冲突形态我梳理了一下在 OpenHarmony RN 的真实业务里滚动冲突主要集中在四类场景页面级纵向滚动容器内嵌 FlatList/ScrollView典型形态是“详情页头部 多 tab 列表”。外层横向 ViewPager 内嵌纵向列表典型形态是“首页 banner 下方 tab 页”。底部弹层/半模态面板内部有列表弹层本身又跟随手势上下拖动。吸顶头部和内容区列表联动滚动的复杂页面。这四类场景有个共同特点滚动方向不一致或同一方向多层嵌套。方向不一致时ArkUI 的手势识别器需要通过轴向来判断方向一致时则需要明确的“谁先滚、滚到边界后再交给谁”的协商机制。缺了这套机制任何一个场景都会出问题。2. 冲突为什么难缠五个高频场景的根因分析不是所有滚动冲突都长一个样。我建议你在动手解决之前先把手头的问题归类。因为不同场景的根因不同对应方案也完全不同。我挑了五个高频场景逐个拆开说。2.1 垂直嵌套外层 Scroll 套内层 FlatList这是最常见的。典型的页面结构是ArkUI Scroll └── RN 页面根组件 └── RN FlatList现象内层 FlatList 的数据很少时正常数据量一大手指在内层列表上滑动内层不动外层页面却开始滚了。根因分析ArkUI 外层 Scroll 的手势识别器在纵向滑动意图上优先级更高它会先于 RN 内层拿到事件流。RN 的 FlatList 在原生层虽然也想滚动但它无法向外层 ArkUI Scroll 发出“我已经滚到边缘了请接管”的信号。所以只要手指在动外层就默认这是自己的滚动。我在排查时发现一个判断技巧看内层 FlatList 的onScroll事件是否频繁触发。如果在滑动时 onScroll 几乎不触发只有偶尔抖动说明事件被外层拦截了如果 onScroll 一直在触发但滚动距离是 0说明事件到了内层但被某个条件阻止了。这两种情况修法完全不同。2.2 水平嵌套外层 ViewPager 内嵌横向轮播场景外层是 RN 的 ViewPager 或 ArkUI 的 Swiper内层是个横向滚动的列表或轮播图。现象手指在内层轮播上左右滑动偶尔会把外层 ViewPager 也带得翻页反过来在外层翻页时内层轮播也会跟着横向滑一下。根因两个横向滚动容器都监听横向滑动手势识别器都认为这是自己的菜。ArkUI 的 Swiper 有自己的手势优先级RN 的横向 ScrollView 也有但两者之间没有协调机制谁能抢到事件全凭触摸点的微小位移和手势识别器的判定阈值。这种场景在 Android 上通过 GestureDetector 的onTouchEvent返回值来控制都不太好弄在 OH 上更麻烦。2.3 吸顶头部与列表联动这是详情页最常用的结构顶部一个头部视图向下滚动时头部先滚出屏幕然后吸顶后续列表继续滚。在 Android 上这种交互靠 CoordinatorLayout AppBarLayout 或者自己监听滚动偏移实现。但在 OH RN 下如果你用一个 ArkUI Scroll 包住整个页面再在里面放 RN 的内容头部吸顶逻辑就变成外层 Scroll 滚动到头部高度后内层列表接着滚。可问题是外层 Scroll 滚到头部消失后内层列表的数据渲染是独立的你很难精确控制哪一段滚动该由谁负责。接手过一个项目他们把头部吸顶做成了两层外层 ArkUI Scroll 只负责滚动头部内层 RN 列表负责自己的数据滚动。结果手势冲突变得极其诡异——有时候头部滚上去了内层列表滚不动有时候内层列表滚了头部又跟着动。2.4 弹层/半模态面板内嵌列表半模态面板本身可以通过手势下拉关闭面板内部又有个可滚动的列表。用户手指在列表上往下滑到底是滚列表到底部还是下拉关闭面板这个场景的冲突非常难通过“监听事件”来排查因为根本做不到在 JS 层判断用户意图。Android 的做法是面板先接收列表回传的滚动位置列表滚动到顶部了且继续下拉时面板再接管。但 OH 上 RN 列表并不会主动上报“我在顶部”面板的手势识别器也无法直接获取内部 RN 列表的滚动状态。2.5 快速滑动的惯性阶段冲突还有一种最容易误导人的问题慢速滑动时一切正常快速滑动就乱跳。原因在于滚动分两个阶段跟手阶段和惯性阶段。慢速滑动时没有惯性事件处理链路清晰快速滑动时手指离手后进入 fling 惯性阶段这个阶段的位移和速度由滚动容器自己计算。如果你在 JS 层监听了onScroll并且调用了外部状态更新ArkUI 容器和 RN 容器各自的惯性计算相互叠加就会出现页面“跳一下”或者“突然加速”的现象。这类问题不太像传统意义上的“手势争夺”更像是两侧各自为政导致的动画叠加。排查时不能用常规的拦截思路要从“减速/惯性动画是否被重复触发”的角度去查。3. 处理滚动手势的三条路径事件拦截、嵌套协议与自定义判定在 OpenHarmony 上处理 RN 的滚动冲突我摸索下来有三条可落地的路径按推荐程度排序分别是启用原生嵌套滚动协议、父容器按场景拦截、自定义手势互斥判定。下面分别说清楚每条路径的原理和适用边界。3.1 路径 A启用原生嵌套滚动协议OpenHarmony 从特定版本开始ArkUI 的 Scroll、List 组件提供了一个关键属性nestedScroll。这个属性就是 OH 自己定义的“嵌套滚动协议”类似 Android 的 NestedScrolling 机制只是名称和 API 完全不同。使用方法是在 ArkUI 侧给外层滚动容器设置Scroll() { // 这里放 RN 的容器 } .nestedScroll({ scrollForward: NestedScrollMode.PARENT_FIRST, scrollBackward: NestedScrollMode.SELF_FIRST })scrollForward和scrollBackward分别代表滚动正向和反向时的优先级策略。NestedScrollMode有几种可选值模式含义SELF_FIRST自身先滚动滚到边界再交给父组件PARENT_FIRST父组件先滚动父组件不动再自己滚SELF_ONLY只自己滚不交给父组件PARENT_ONLY只父组件滚自己不滚如果你在 ArkUI 外层容器上设置了SELF_FIRST或PARENT_FIRST并且你的 RN 内层列表是基于 ArkUI 的滚动容器封装的比如 RN for OH 的实现层面复用了 ArkUI 的 List那么嵌套协议是能生效的冲突会大幅减少。但要注意如果内层不是 ArkUI 官方滚动容器而是 RN 侧自定义的原生视图或者是旧的 WebView 桥接这个属性不保证生效。因为它要求整个滚动链路上的组件都认识这套协议。3.2 路径 B父容器按场景拦截事件如果内置协议走不通就需要手动干预事件分发。ArkUI 的手势系统提供了onTouch和gesture绑定能力你可以通过监听 TouchEvent 的action类型来主动控制容器是否消费事件。一个实践过的方案外层 ArkUI Scroll 的onTouch回调里维护一个标志位判断手指按下的位置是否落在内层 RN 列表的区域如果是就把外层滚动的可用状态临时关闭。Scroll() { // 内容 } .onTouch((event: TouchEvent) { if (event.type TouchType.Down) { // 通过坐标判断按下的位置是不是在内层列表的范围内 this.allowOuterScroll !this.isTouchInInnerList(event.touches[0].x, event.touches[0].y); } }) .enabled(this.allowOuterScroll)这个方案的缺点是需要你自己维护“内层列表区域”的坐标范围如果页面布局动态变化坐标范围也要实时更新。但优点是可控性最强适用于协议无法生效的复杂场景。3.3 路径 C自定义手势互斥判定更高级一点的做法是彻底放弃系统默认的手势识别在 ArkUI 侧使用GestureGroup或者自定义手势判别逻辑。比如你可以给外层容器绑定一个 PanGesture 而不是使用 Scroll 内置手势然后在 PanGesture 的触发条件里加上方向判断。如果手指的移动方向是纵向且当前焦点在内层列表上则 PanGesture 不激活把事件漏给内层否则激活。PanGesture({ direction: PanDirection.Vertical, distance: 5 }) .onActionStart((event: GestureEvent) { // 如果手指起点在内层列表范围内不处理 if (this.isTouchInInnerList(event.offsetX, event.offsetY)) { // 标记不消费事件 } })但这里有一个大坑ArkUI 的手势系统一旦某个手势识别器激活事件就不会再转发给内层 RN 视图。所以“不消费”并不是通过返回 false 实现的而是要让这个手势识别器永远不激活或者在激活之前就判定为失败。你需要非常熟悉GestureEvent的各个字段以及 ArkUI 手势系统的“失败/成功”状态机否则很容易写成“假装解决了实际上更卡”。3.4 路径 D让 RN 放弃手势改由 ArkUI 统一管理这是最彻底、也是最“物理”的方案不让 RN 原生侧处理滚动而是关闭 RN 列表的触摸滚动能力把滚动事件的源头全部放到 ArkUI 容器上。具体来说RN 页面里把 FlatList 的scrollEnabled设为 false然后由 ArkUI 外层容器接收触摸手势再通过 Bridge 把滚动位移同步给 RN 列表由 RN 列表的scrollToOffset来执行滚动。这个方案能 100% 消解手势冲突因为整个事件链路上只有 ArkUI 在监听触摸。但它引入了一个新问题RN 列表的scrollToOffset是 JS 层指令需要经过 Bridge 转发滚动性能会有明显损耗。我实测在低端设备上快速滚动时scrollToOffset的指令频率根本跟不上手指速度会出现掉帧和滞后。所以这个方案只适合滚动数据量很小、页面结构简单的场景。复杂列表业务不建议直接用可以作为兜底方案。4. 工程化落地从 ArkTS 侧到 RN 侧的一整套配置方案理论讲完给一套我实际跑通过的可复现配置。以最常见的“外层 ArkUI Scroll 包内层 RN FlatList”为例从环境准备到最终验证逐步说。4.1 项目环境和依赖准备我的测试环境是这样的项值OpenHarmony SDKAPI 10 及以上RN 版本0.72适配 OH 的版本RN-OH 适配层react-native-oh-turbo 或自研接入层目标设备OpenHarmony 4.0 真机 / x86 模拟器先说一个坑如果你用的是 x86 电脑版 OpenHarmony现在不少人因为开发方便直接在电脑虚拟机里跑 OH滚动冲突的表现和真机有时不一致尤其是惯性阶段。x86 模拟器上慢速滑动的问题能复现快速滑动的跳变问题往往复现不出来。所以最终验证一定要上真机x86 模拟器只用来做功能联调。依赖方面确保你的 RN-OH 适配层支持nestedScroll属性的透传。如果适配层没有把这个属性暴露给 ArkUI 原生的 Scroll 容器你在 ArkTS 里写了nestedScroll也不生效。我在公司项目里就遇到过适配层版本太旧ArkTS 侧配置写好了但真正渲染时被适配层过滤掉了排查了整整两天才发现。建议先从适配层的源码或 issue 列表里确认这一个点。4.2 ArkTS 容器侧的关键配置ArkTS 侧的关键代码我最终用的是SELF_FIRST方案Entry Component struct PageContainer { State innerListWidth: number 0; State innerListHeight: number 0; build() { Scroll() { Column() { // 头部区域 HeaderComponent() // RN 页面容器通过XComponent或者RNSurface挂载 RNSurface({ width: this.innerListWidth, height: this.innerListHeight, }) } } .nestedScroll({ scrollForward: NestedScrollMode.SELF_FIRST, scrollBackward: NestedScrollMode.SELF_FIRST }) .edgeEffect(EdgeEffect.None) .scrollBar(BarState.Off) .onAreaChange((oldValue: Area, newValue: Area) { this.innerListWidth newValue.width as number; this.innerListHeight newValue.height as number; }) } }注意SELF_FIRST的方向选择。scrollForward指的是滚动内容向前、视口相对向后移动的方向手指向上滑scrollBackward是相反的滚动方向手指向下滑。如果内层列表需要先响应滚动到边界后再交给外层页面通常两个方向都用SELF_FIRST。但内容头部高度很大时这个配置会出现一个问题内层列表把外层 Scroll 的滚动范围完全占用外层头部永远滑不出去。这时候你需要在 RN 侧配合处理下面会讲到。4.3 RN 页面侧应该怎么写RN 侧最关键的一点不要嵌套使用 RN 自己的 ScrollView 包 FlatList。在 Android 上很多人为了兼容某些老逻辑会在外层套一个ScrollView里面放FlatList然后设置nestedScrollEnabled。在 OH 上这么做Edge 事件和手势冲突会成倍放大。正确做法是RN 侧只暴露一个纯的 FlatList外层滚动全部交给 ArkUI 容器。import { FlatList, type NativeSyntheticEvent, type NativeScrollEvent } from react-native; export const InnerList ({ onNearBottom }: { onNearBottom?: () void; }) { const handleScroll (event: NativeSyntheticEventNativeScrollEvent) { const { contentOffset, layoutMeasurement, contentSize } event.nativeEvent; if (contentOffset.y layoutMeasurement.height contentSize.height - 50) { onNearBottom?.(); } }; return ( FlatList data{data} keyExtractor{(item) item.id} renderItem{({ item }) ItemView item{item} /} onScroll{handleScroll} scrollEventThrottle{16} nestedScrollEnabled / ); };这里有一个细节容易被忽略nestedScrollEnabled在 Android 上控制的是 NestedScrolling 协议但在 OH 上它控制的是是否允许这个列表作为“子滚动容器”参与 ArkUI 的嵌套协商。设置为 true 之后RN 列表会主动向 ArkUI 父容器上报自己的滚动边界。RN 侧第二个关键点不要监听 Android 平台的onTouchStart / onTouchEnd来干预事件。OH 上 RN 触摸事件的到达顺序和 Android 完全不同如果你在onTouchStart里通过 setState 去控制某个状态很可能会触发整个列表重渲染导致滚动 concurrency 问题。4.4 真机验证和性能数据配置完成后我拿一台 OpenHarmony 4.0 真机跑了一个 500 条数据的 FlatList外层 ArkUI Scroll 头部高度 200vp。验证通过的判断标准是手指在内层列表上纵向滑动列表先滚动滚到列表顶部或底部后外层页面才开始滚动。快速 fling 时惯性动画连续没有跳变和回弹。外层头部滚动到吸顶位置后内层列表的滚动偏移不被重置。实测数据低端开发板慢速跟手性良好帧率稳定在 55~60 帧快速 fling 后数据加载时会有 2~3 帧掉帧但整体可接受。相比不配置 nestedScroll 时的“内层滚不动、外层乱跳”体验是质变。5. 踩过的坑与排查链路从偶发卡顿到手势被吞技术方案说完了但你在实际项目中大概率会遇到一些看起来“不应该发生”的问题。我把踩过的三个坑和一个通用排查链路整理出来供你少走弯路。5.1 坑点一x86 模拟器上偶发滑不动现象是代码逻辑完全一致在 x86 模拟器上运行偶尔会出现整个页面滑不动的状态重启应用后恢复。这个问题在真机上几乎不出现在 x86 模拟器上出现的概率大约 10%。排查过程先怀疑是 x86 指令集下 ArkUI 手势识别器的默认阈值不同但查文档没有相关说明。后来又怀疑是模拟器的触摸事件采样频率不稳定导致手势识别器判定失败。最终定位到是模拟器的“触控板模拟”模式导致的——x86 模拟器默认用鼠标拖拽模拟触摸鼠标的快速位移会产生大量离散事件ArkUI 的手势识别器在这种高频离散事件下会误判为“非滚动手势”从而丢弃整个手势序列。处理办法很简单在 x86 模拟器的设置里把触摸输入方式改成“触摸模拟”或者连接实体触摸屏。没有相关选项的话不要用在模拟器上联动手势逻辑直接上真机验证。5.2 坑点二禁用父容器滚动后RN 内部列表也失灵我最初尝试过一条看起来很有道理的路径在 RN 列表区域按下时直接设置外层 ArkUI Scroll 的.enabled(false)松手再恢复 true。结果发现外层 Scroll 被禁用后RN 内部列表的滚动也失灵了。排查后发现ArkUI 的.enabled(false)不只是禁用外层自己的手势响应它会把整棵子树的事件响应都链接中断。RN 容器作为子组件挂在被禁用的 Scroll 下收到的触摸事件直接就被系统过滤掉了RN 列表根本拿不到事件。这个坑的教训是不要试图通过禁用某些祖先组件来“让出”事件ArkUI 的 enabled 是子树级别的不是单组件级别的。想按区域区分事件只能靠手势条件判定或嵌套协议不能靠启用/禁用。5.3 坑点三快速滑动一段后页面闪跳现象是慢速滚一切正常快速 fling 后页面闪跳一下回弹到前一个位置。这个坑在真机上偶发在 x86 模拟器上基本必现。根因分析RN 的 FlatList 在快速滚动进入惯性阶段后会不断通过 Bridge 回调onScroll事件。而 ArkUI 外层 Scroll 的嵌套协议里SELF_FIRST模式下内层滚动到边界后会通知父容器接管。问题就出在“通知”这个动作上——RN 适配层实现边界通知时传递的滚动 offset 在 Bridge 传输过程中可能丢失精度或者出现时序不一致导致外层容器接管后立刻回滚了一小段距离。排查链路先在 ArkTS 侧给外层 Scroll 的onScrollBegin和onScrollEnd打日志确认接管时机再到 RN 侧给 FlatList 的onMomentumScrollEnd打日志看事件到达先后。我的日志比对结果是外层onScrollEnd先触发内层onMomentumScrollEnd后触发说明 RN 适配层的边界通知是提前发出的跟外层接管时机存在时序错位。处理方案RN 侧降低scrollEventThrottle的值把事件回调频率降低到每 32ms 一次减少 Bridge 传输频次。虽然牺牲了一点实时性但解决了闪跳问题。如果你的业务对 onScroll 实时性要求高就不要用SELF_FIRST改用PARENT_FIRST重新设计交互。5.4 通用排查链路综合几次踩坑我总结出一套通用排查链路按这个顺序走能避免很多无头苍蝇式的瞎试先确认滚动链路上有几层容器每一层是 ArkUI 组件还是 RN 原生视图。画一棵树。逐层验证哪一层吞了事件。方法是在 ArkUI 的onTouch上打日志看 Down/Move/Up 事件分别被哪些层拿到。区分是“事件没到”还是“事件到了但没消费”。前者是手势识别阶段的拦截后者是滚动逻辑年号的拒绝。如果是“没到”优先查 ArkUI 手势识别优先级和nestedScroll配置如果是“到了但没消费”查 RN 侧scrollEnabled、nestedScrollEnabled、内容大小是否小于容器。最后做真机验证不要依赖模拟器。这套链路解决了我 80% 以上的滚动问题。剩下 20% 是纯业务交互设计的问题比如“手指滑到列表顶部后再下拉应该刷新还是滚动外层”这类问题没有标准答案只能看你产品的具体需求。6. 一个容易被忽略的配套问题RN 与 OH 原生能力互调滚动问题告一段落后紧接着往往是一个看起来不相干、但实际上会影响滚动手感的问题RN 页面在 OpenHarmony 上调用系统原生能力时如果走的是阻塞式 Bridge会让主线程卡顿进而导致滚动掉帧。最典型的就是调用电话功能。之前在社区里看到有人问“rn 怎么调用电话功能”在 Android 上你可能直接Linking.openURL(tel:xxx)就完事了。但在 OH 上这个调用链路完全不一样。你需要自己写一个原生模块通过ohos.telephony.telephony去拨打号码。如果你的实现是同步Promise桥接并且在滚动动画期间里调用卡顿几乎是必然的。处理滚动和原生调用之间的耦合我建议做到以下三点所有原生能力调用统一走异步队列不要在 JS 线程同步等待返回。涉及 UI 状态更新的调用在返回后使用InteractionManager.runAfterInteractions延迟执行让滚动动画先结束。对频繁调用的能力比如判断是否有电话权限做内存缓存避免每次滚动都触发一次 Bridge 往返。这虽然看起来和 NestedScroll 无关但在实际项目中很多“滚动卡顿”根本不怪滚动容器而是滚动过程中乱七八糟的 Bridge 调用把主线程给占了。排查滚动性能问题时别忘了顺手看一下你的原生调用频率。最后再分享一个我自己验证过的小技巧调试 NestedScroll 时强烈建议先在 ArkTS 侧把外层 Scroll 的edgeEffect设成None再把scrollBar关掉。这两项配置会减少默认的物理反馈动画降低干扰变量。等核心的滚动冲突解决后再打开边缘回弹和滚动条你会发现有些“看起来是冲突”的问题其实只是边缘反馈动画和嵌套协议叠加出来的视觉异常。另外如果你手头的业务允许优先用一个扁平化的 ArkUI 容器来承载所有滚动而不是在 RN 内部再搞多层滚动嵌套。OpenHarmony 的 ArkUI 滚动体系在单层滚动场景下非常流畅但多层嵌套时的手势协商能力目前仍然比 Android 原生 NestedScrolling 弱。能在 ArkUI 层解决的交互就不要把 RN 拉进来参与手势博弈。滚动冲突这个问题说大不大说小不小。本质上就是两套框架对“谁来滚动”这件事没有达成共识。理解了这一点再去看 ArkUI 的nestedScroll、手势绑定、事件分发思路就清晰多了。希望这篇内容能帮你少走几个我走过的弯路。