OpenHarmony+React Native滚动冲突全解析：从NestedScroll原理到工程实践

搞了两年多 OpenHarmony 上的 React Native 应用，说实话，踩得最深、查得最头疼的坑，就是滚动冲突。尤其是 NestedScroll 这种“既想内外都能滑，又不想互相打架”的需求，初次接触的人十有八九会在手势分发里转晕。这篇文章我直接结合一次真实项目的优化过程，把 OpenHarmony 原生侧和 RN 侧的滚动冲突原理、判断流程、可复现方案全拆开讲透，争取让你看完就能套用到自己的页面上。

先说清楚这句话：在 OpenHarmony 上做 RN 应用，滚动冲突并不只是“RN 内部 ScrollView 互相嵌套”的问题，还有“RN 容器嵌入原生 Scroll/List”的跨端混合嵌套问题，这两类必须分开看，处理思路也完全不同。文章主体会围绕一个典型场景——外层是 ArkUI 的 Scroll，内层嵌了一个 RN 的 FlatList，并且要求内外都可以独立滚动，同时在边界处联动——逐步还原从现象到方案的完整过程，顺带给出能直接用的代码片段和避坑记录。

1. 滚动冲突的根因：OpenHarmony 与 RN 的手势分发不是同一套逻辑

1.1 ArkUI 滚动容器的工作方式

在 OpenHarmony 原生侧，ArkUI 的滚动容器（Scroll、List、Grid 等）底层都依赖一套统一的滚动判定机制。你在 Scroll 里放一个 Column，Column 高度超过视口后，手指在屏幕上滑动，事件会先经过 ArkUI 框架的 HitTest 命中测试，找到你手指触摸到的那个子组件，然后从子组件开始向父组件逐级冒泡，同时滚动容器内部的 Scrollable 会监听这些触摸事件，进行位移计算。

这里最关键的一个点在于：ArkUI 原生滚动容器对手势的响应不是“谁先声明谁就赢”，而是有一套基于 Axis 方向、滚动边界和手势识别状态的竞争逻辑。比如外层是竖直滚动，内层也是竖直滚动，手指向上滑，内层先接到事件，如果内层没有滚动到顶（处于边界区域），内层会消费这次滑动；如果内层已经到顶了，事件才会冒泡到外层，外层继续响应。这就是最基本的“子优先、父兜底”策略。

但这个策略在嵌套场景下有个很容忽视的细节：如果外层是竖直滚动，内层是横向滚动，那手指的斜向滑动（既有横向分量又有纵向分量）在命中测试后，移动方向轴不同时，两个滚动容器会同时尝试消费事件。ArkUI 内部有 PanGesture 的方向识别来处理这种“斜向冲突”，可一旦内层变成了 RN 的 ScrollView，原生侧的这套逻辑就失效了，因为 RN 的手势响应体系是独立跑在 JS 层的。

1.2 RN 侧手势响应体系的核心逻辑

RN 的 ScrollView / FlatList 在 OpenHarmony 上并不是直接走 ArkUI 的 Scrollable，而是通过 RNOH（React Native OpenHarmony）适配层，把 RN 的手势响应系统落地到 ArkUI 的能力上。手势事件从屏幕触发后，会经过 ArkUI 分发给 RN 的 RootView，再进入 RN 的 JS 层 Gesture Responder System，由 JS 侧判断该由哪个 RN 子组件成为 responder。

这套流程多了“跨桥”和“跨语言”的成本，而且最要命的是：RN 的 ScrollView 在滚动时会调用 setNativeProps 或者请求原生的 scrollTo 接口，这与 ArkUI 原生容器的手势识别是两条并行管线。当 RN 的 FlatList 嵌套在 ArkUI 的 Scroll 里时，一次手指滑动会同时进入 ArkUI 的手势识别流程和 RN 的 JS 手势响应流程，两个流程都会尝试成为这场滑动的主导者。

我举个更直白的例子：RN 的 FlatList 处于竖直滚动状态，外面套一个 ArkUI 的 Scroll（也是竖直方向）。手指上滑，ArkUI 的 Scroll 想滚动，RN 的 FlatList 也想滚动。这时两边都会收到 touchmove，差别在于 ArkUI 的滚动容器会在 OnTouchMove 里做位移换算，RN 的 FlatList 会通过 onTouchMove 通知 JS 侧更新滚动位置。两边同时更新，视觉上就出现了“页面跳一下、回一下、最后卡住”的典型冲突。

1.3 为什么 NestedScroll 在混合场景下必须显式声明关系

在纯 OpenHarmony 原生开发里，你可以用 nestedScroll 接口来告诉父容器和子容器：在什么边界条件下，事件由谁来消费。比如父容器 scrollForward 设置为 PARENT_FIRST，子容器 scrollBackward 设置为 SELF_FIRST，这样可以控制折叠屏常见的“Sticky Header + 列表联动”场景。

但是在 OpenHarmony + RN 的混合架构里，不存在“ArkUI 内直接声明 RN 组件的 nestedScroll 子节点”这种天然关系。RN 组件在 ArkUI 侧就是一个自定义组件（RNCView），它的内部手势处理和 ArkUI 原生滚动容器之间没有内置的协调器。你在 ArkUI 侧写的 nestedScroll 只能约束 ArkUI 组件之间的嵌套，约束不到 RN 组件内部的手势响应。

这也是很多开发者第一次排查时的迷惑点：明明把原生套件的 nestedScroll 写对了，RN 内部的 FlatList 还是乱跳。因为 RN 那层压根不走这套接口，需要你在 JS 侧也做一层“事件感知”，让 RN 的滚动器知道外面原生容器现在处于什么滚动状态。这类跨环境的状态同步，才是 NestedScroll 冲突处理的核心难点，也是后面所有解决方案绕不开的共同基础。

2. 冲突场景自测：先判断你遇到的是哪类问题

2.1 同向嵌套：两个竖直滚动容器叠在一起

同向嵌套是最常见也最头疼的。典型结构是外层 ArkUI Scroll，里面塞了一个 RN 的 FlatList，而且两个都是竖直方向。这种布局的初衷一般是：外层负责整页的 Header 和 Footer，中间区域的 RN FlatList 负责动态数据列表。

它的直接表现就是文章开头说的“卡一下回一下”。其实拆分来看，这背后有两个独立的问题点：

第一个是初始滚动方向判定冲突。手指刚落下时，ArkUI 和 RN 都会开启“疑似滑动”的监测，两边的判定阈值和响应延迟不一样（ArkUI 默认的 pan 判定阈值与 RN ScrollView 的 minPressDuration、minDist 并不一致），导致有时候手势还没被判为滚动，两边的状态就乱了。

第二个是边界信息不互通。RN FlatList 滚到顶部后，继续上滑，按常规预期应该让外层 ArkUI Scroll 接管，以便用户能继续往上看到 Header 区域。但 RN FlatList 作为子组件，并不知道自己该把事件“交出去”；而外层 ArkUI Scroll 也在同时等待成为 responder。两边都在等对方让位，于是出现“死锁”。

2.2 跨轴嵌套：方向和分区导致的部分冲突

跨轴嵌套相对温和一些，但也不是完全没有问题。比如外层 ArkUI Scroll 是竖直方向，内层 RN ScrollView 是水平方向，这种结构在大部分情况下能正常工作，因为 ArkUI 和 RN 在手势方向判定上都会“偏向”自己负责的轴。

但注意“大部分情况”这个词。真实的用户操作不是标准的水平滑动或竖直滑动，而是带有弧度的、混合的轨迹。当手指轨迹的起始段是斜向的，两边的方向识别器都会进行“抢选”，一旦某一边先抢到了 responder，另一边就完全不响应了。这个在 iOS 原生里也有，但原生有一套完善的 UIScrollView 嵌套协调机制，而 OpenHarmony + RN 没有。

还有分区冲突的情况：比如外层是一个横向滚动的 ArkUI Tabs，内嵌多个 Tab 页，其中某个 Tab 页内部有 RN 的竖直 FlatList，这时候横向翻页与竖直滚动在斜向滑动时也会发生竞争。Tabs 组件内部对横滑的判定非常敏感，容易把用户的竖向滑动误判为翻页，属于一个隐蔽的低频 bug。

2.3 混合嵌套进阶形态：ArkUI 页面承载多段 RN 组件

还有一种很容易被忽略的场景：一个 ArkUI 页面里同时放了两个及以上彼此独立的 RN 容器，每个容器内部有自己的纵向滚动需求，它们之间没有直接嵌套，但都嵌在同一个外层 ArkUI 滚动容器里。这时候滚动冲突不是发生在“父子”层面，而是发生在“兄弟”层面。

这种情况的冲突形式是：当手指先触发第一个 RN 容器的滚动，然后手指还没离开屏幕就移向第二个 RN 容器，或者快速滑动跨越两个区域时，两个 RN 容器的 responder 没有顺利交接，导致第二个容器停止响应，甚至出现闪烁。排查这种问题的时候，如果只盯着单个容器的嵌套关系，永远找不到根因，需要从“页面级手势调度”的视角去看待。

2.4 表现、原因、定位手段速查

这里整理了一个我经常用来快速自测的对照表，拿到滚动冲突问题可以先按这个思路过一遍：

这个表里每一行我都实际踩到过，其中“页面偶发闪烁、滚动位置回跳”最坑，因为它不是必现，尤其在低端设备上，事件上报频率不一致时会放得更明显。后面我会讲我最终是如何通过“状态同步 + 事件决策”双重手段压掉这个问题的。

3. 可落地的解决路径：从原生拦截到 JS 联动

3.1 方案一：ArkUI 侧手势拦截，用 PanGesture 控制外层 Scroll 的响应时机

如果你不想改太多 RN 业务代码，最快的方案是在 ArkUI 外层拦截手势事件。思路是这样的：外层不用默认的 Scroll 直接包 RNCView，而是给外层 Scroll 挂一个我们自定义的 PanGesture，并且在 GestureGroup(GestureMode.Exclusive) 里控制手势的识别优先级。

下面是一个精简示例，先说明角色：outerScroller 是外层 ArkUI Scroll 的控制器，innerScrollLock 是一个用 @State 标记的变量，用来指示当前手势是否应该由外部接管。

typescript复制// ArkUI 侧：外层容器的手势控制
@State innerScrollLock: boolean = false;
private outerScroller: Scroller = new Scroller();

build() {
  Scroll(this.outerScroller) {
    Column() {
      // 这里是 RN 容器 RNCView
      this.rnView()
    }
  }
  .gesture(
    GestureGroup(GestureMode.Exclusive,
      // 当内部需要滚动时，通过回调把锁打开，外层就不再响应
      GestureGroup(GestureMode.Sequence,
        PanGesture()
          .onActionStart((event: GestureEvent) => {
            if (this.innerScrollLock) {
              // 内部锁定了，外层直接结束，把事件让给子组件
              return;
            }
          })
          .onActionUpdate((event: GestureEvent) => {
            if (!this.innerScrollLock) {
              this.outerScroller.scrollBy(event.offsetY, 0);
            }
          })
      )
    )
  )
}

你要问了：直接用 gesture 包了一层，原来 Scroll 自身的滚动逻辑还会生效吗？答案是不会了，因为 GestureMode.Exclusive 意味着这个 gesture 是排他性的，外层内置的“滚动响应”会被覆盖，滚动完全由你自定义的 PanGesture 驱动。这种做法的好处是逻辑最透明，你想让外层滚就滚，想锁就锁，完全代码可控；缺点是需要自己维护滚动偏移量和边界逻辑，处理起来比自带 Scrollable 更繁。

这个方案的重点在于 innerScrollLock 在什么时候开、什么时候关。实际项目中，我是在 RN 侧通过 onScroll 事件上报边界状态：内层到达顶部或底部时，通知原生把锁打开；内层离开边界时，把锁关上。这里要解决的是“通信延迟”，后来我改成在 RN 侧用 scrollEventThrottle + onScrollBeginDrag / onScrollEndDrag 组合判断，响应速度才真正跟得上手指。

3.2 方案二：ArkUI 原生侧的 nestedScroll 配置（适用于纯 ArkUI 子容器）

如果你的内层不是 RN 容器，而是 ArkUI 自带的 List 或 Scroll，那最标准、最推荐的做法就是使用 nestedScroll 接口，不需要自己造轮子。

typescript复制Scroll(this.outerScroller) {
  Column() {
    List({ space: 10 }) {
      // 列表项
    }
    .nestedScroll({
      scrollForward: NestedScrollMode.SELF_FIRST,
      scrollBackward: NestedScrollMode.PARENT_FIRST,
    })
  }
}

这里的属性含义直接记住两个方向词：scrollForward 和 scrollBackward。SELF_FIRST 表示优先自己消费滚动事件，撑不住了（到了边界）再交给父组件；PARENT_FIRST 表示父组件优先消费，父组件不消费了才轮到子组件。

为什么 PARENT_FIRST 和 SELF_FIRST 要组合用？因为在真实交互里，手指向上滑和向下滑对应的语义不一样。手指上滑时，通常希望子列表优先滚动，直到子列表滚到顶部（不能再向上），然后才让外层的 Header 滚出屏幕；手指下滑时，则希望先让外层 Header 恢复显示，外层的 Header 完全展开后，再开始滚动子列表。所以 scrollForward 用 SELF_FIRST，scrollBackward 用 PARENT_FIRST，正好覆盖这两种预期。

关于 NestedScrollMode 的详细取值，工程里常用的还有 PARENT_FIRST、SELF_FIRST、PARALLEL（父子同时滚动）。如果你想让外层和内层同时滚动而不是依次接管，可以用 PARALLEL，但这种模式在“内层是 List 且需要回收复用”的场景下性能很一般，因为每一帧都要同时计算两边的偏移量，实际体验反而容易掉帧。

3.3 方案三：RN 侧手势接管替代 ScrollView / FlatList

如果你在 RN 侧已经把页面结构写成一个 ScrollView 嵌套一个 FlatList 这种经典冲突结构，有一个治本思路：把内层 FlatList 替换为 ScrollView，再配合 nestedScrollEnabled 这个属性来控制。

之所以不推荐直接同向嵌套两个 ScrollView/FlatList，是因为 RN Android 侧的同轴嵌套本身就需要 nestedScrollEnabled，到了 OpenHarmony 侧，RNOH 对这个属性的支持跟 Android 语义并不完全一致，你写了不一定生效，会对排查造成很大困惑。

一个更稳妥的 RN 侧方案是引入 react-native-gesture-handler（后面简写 RNGH），它的 ScrollView 会自定义封装手势识别，不会与默认的响应器绑定。在 OpenHarmony 的 RNOH 版本里，RNGH 对滚动事件的处理比内置组件更可控：

tsx复制// RN 侧：用 RNGH 的 ScrollView 替代内置组件
import { ScrollView } from 'react-native-gesture-handler';

const InnerFlatList = () => {
  return (
    <ScrollView
      nestedScrollEnabled
      onScroll={onInnerScroll}
      scrollEventThrottle={16}
    >
      {/* 列表项 */}
    </ScrollView>
  );
};

这里要强调一下 nestedScrollEnabled 在 RNGH 里的角色：它更强依赖于父容器对子容器“边缘状态”的感知。但 OpenHarmony 侧 RNGH 的底层还是基于 ArkUI 的手势事件封装，所以你依然需要保证外层容器不会过度拦截子容器的手势。我的做法是：外层 ArkUI Scroll 不设置任何自定义 gesture，保持默认行为；内层 RNGH ScrollView 设置 nestedScrollEnabled，让 RNGH 自己处理边界的抛事件。实测下来，简单的两层嵌套场景，这样配是够用的。

3.4 方案四：跨端状态桥接，ArkUI 与 RN 的联合滚动

如果前面几个方案都满足不了你的复杂交互（比如折叠头部 + 多段子列表 + 锚点定位），那最终方案一定是“跨端联合滚动”。核心思路是：让 ArkUI 侧和 RN 侧共享一个滚动位置状态，由一侧主导，另一侧跟随。

我实际落地的是一个“单驱动——单跟随”模式：外层 ArkUI Scroll 作为主导驱动者（Driver），内层 RN 容器作为跟随者（Follower）。每当外层滚动偏移量变化时，通过 emit 把最新的 scrollY 传给 RN 侧；RN 侧收到后设置内部列表的 contentOffset。反向则反过来，当用户在 RN 内部滚动时，RN 通过事件把滚动位置同步给外层，让外层更新 Header 的位置。

这个模式的实现需要借助 OpenHarmony 的 NativeEventEmitter 和事件总线来打通原生与 JS 侧。RN 侧代码大致如下：

tsx复制// RN 侧：监听原生事件，同步外层滚动位置
import { NativeEventEmitter, NativeModules, DeviceEventEmitter } from 'react-native';

useEffect(() => {
  const emitter = new NativeEventEmitter(NativeModules.MyBridgeModule);
  
  const subscription = emitter.addListener('onOuterScrollSync', (data) => {
    const { scrollY } = data;
    // 注意这里要判断当前是否是用户在内层滚动造成的回调，避免死循环
    if (!isInnerScrollingRef.current) {
      innerListRef.current?.scrollTo({ y: scrollY, animated: false });
    }
  });

  return () => subscription.remove();
}, []);

反向通知原生侧时，可以借助 NativeModules 接口，也可以是 ArkUI 侧给 RN 组件传一个回调函数。这里最容易踩的坑就是“递归同步”：外层滚 -> 通知内层 -> 内层 scrollTo 触发内层 onScroll -> 内层再把事件回传给外层 -> 外层再更新……形成无限循环。我当时的解法是引入 isInnerScrollingRef 标志位，只有在用户真实触摸内层滚动时才允许回传外层，代码触发的 scrollTo 一律不同步。

4. 实战过程：一次商品详情页从卡顿到丝滑的完整排查

4.1 环境信息与页面结构

先交代一下项目的实际背景，方便大家对照。设备是一台 OpenHarmony 4.0 的测试机，开发框架用的 API 9 以上，RN 侧用的 RNOH 0.72 左右的适配版本，页面是一个商品详情页。

页面结构自上而下是：顶部图片轮播区（ArkUI）、标题与规格区（ArkUI）、商品详情长图文（RN WebView 或 RN ScrollView）、推荐商品列表（RN FlatList）。整体希望的效果是：页面作为一个整体在竖直方向滚动，当用户进入推荐列表区域时，推荐列表可以独立滚动，并且列表滚动到顶部时继续上滑，页面整体可以继续向上滚，从而显示底部其他内容。

我这样一描述，你应该能想象出那个结构：外层一个 ArkUI Scroll，内部塞了一个“RN 容器”组件。这个页面早期版本是纯 RN 实现的，但后续为了优化首屏速度和承载更多原生组件，平台侧要求把页面骨架迁到 ArkUI，RN 只负责局部业务模块，这就形成了混合嵌套。

4.2 冲突复现与日志分析

首次测试时，问题非常明显：进入推荐列表区域后，向上滑，推荐列表偶尔会滚，但一下子整页跳到了最底部；继续向上滑，页面卡住不动，大概半秒后突然又恢复。最夸张的一次，快速滑动时推荐列表来回窜动，像被两个力量拉扯。

为了定位根因，我把 ArkUI 外层 Scroll 的 onScroll 事件和 RN 内层 FlatList 的 onScroll 事件都加了日志。然后用 hilog 观察事件顺序，发现以下典型模式：

• 手指开始上滑：ArkUI onScroll 先触发，offsetY 增长；随后 RN onScroll 也触发，contentOffset.y 增长。两边都有响应，但节奏不一致。
• 手指继续上滑：ArkUI onScroll 停止触发，RN onScroll 继续触发。这时候内层列表开始动了，但是外层页面整体没有移动。
• 手指反向滑动：RN onScroll 立即反向；但 ArkUI onScroll 在 RN 滚动变更之后才开始响应，两者存在明显的时序错位。

从这个日志模式能清晰看到，去掉嵌套带来的“抢事件”，最根本的问题是“两边都在独立地响应手势，但彼此完全不知道对方的存在”。在这种情况下，无论怎么调 nestedScroll 属性，都只能治标不治本，必须引入状态同步或事件接管。

4.3 最终实施步骤：双状态机 + 有限状态机决策

考虑到项目工程里已经集成了 RNGH，我没有走自定义 PanGesture 的路线，而是设计了一个轻量的“有限状态机”，状态机由两侧共享的桥接事件驱动。

状态定义如下：

• IDLE：初始状态，没有手指触摸。
• OUTER_ACTIVE：外层 ArkUI Scroll 正在滚动。
• INNER_ACTIVE：内层 RN FlatList 正在滚动。
• DRAG_START：手指刚按下，暂未判定方向。

决策逻辑：

• 手指按下：进入 DRAG_START，此时两边都暂停滚动，等待一定距离的滑动。
• 滑动距离超过阈值：根据滑动方向、内外层当前滚动位置和边界信息，决定进入 OUTER_ACTIVE 还是 INNER_ACTIVE。
• 处于 OUTER_ACTIVE 时，内层 FlatList 所有滚动请求直接拒绝或置为 contentOffset = 0。
• 处于 INNER_ACTIVE 时，外层 Scroll 的滚动请求被 scrollTo 冻结，只有在内层上报“已到达边界”时才允许切换到 OUTER_ACTIVE。
• 手指抬起：状态回到 IDLE，同时恢复两边的滚动能力。

这个流程看着复杂，实际上落地只需要三步。第一步，在 ArkUI 外层 Scroll 上通过 onTouch 事件监听手指状态：

typescript复制Scroll(this.outerScroller) {
  // ...内嵌 RN 容器
}
.onTouch((event: TouchEvent) => {
  if (event.type === TouchType.Down) {
    scrollStateMachine.changeState('DRAG_START');
  } else if (event.type === TouchType.Up || event.type === TouchType.Cancel) {
    // 通知 RN 侧抬起
    scrollStateMachine.changeState('IDLE');
  }
})

第二步，在 RN 侧用 PanResponder 或者 RNGH 的 Gesture.Pan() 监听内部滚动手势，判断是否进入内部滚动，并实时上报边界信息。

第三步，写一个桥接模块，ArkUI 侧在进入 OUTER_ACTIVE 时同步一个标志，RN 侧在主线程读取该标志，对内部滚动做条件放行。

一个需要注意的细节是：不要在每次 touchmove 时都去走桥接通信，那样延迟太高。我们的方案是只在状态切换的瞬间通信一次，滚动过程中两边各自维护自己的滚动状态，不持续互发消息，实测卡顿从此消失。

4.4 边缘情况：回弹、惯性、快速反转

状态机解决的是“有意识的滚动切换”，但还有一些边缘情况需要单独处理。

回弹。ArkUI 的 Scroll 默认支持回弹（edgeEffect），RN 的 FlatList 也有 bounces 属性。当内层列表滚到顶部时，如果你继续上拉，RN 侧会出现一个橡皮筋效果；同时外层若还在边界，ArkUI 也会产生回弹效果。两边同时回弹，视觉上是页面顶部和底部来回拉伸，非常奇怪。我的解法是，把内层 FlatList 的 bounces 设置为 false，把回弹能力完全交给外层 ArkUI Scroll 统一处理，避免嵌套回弹的叠加效应。

惯性。当你在内层快速滑动后松手，内层会进入惯性滚动阶段，但外层容器此时可能感知不到“内层还在滚动”，导致用户立刻再次触摸并进行反向操作时，外层的状态判断发生错乱。为了解决这个问题，我在 RN 侧监听 onScrollBeginDrag 和 onScrollEndDrag，分别在惯性开始和结束的时候向原生同步一次状态，确保 ArkUI 侧知道“当前内层正处于惯性期”，不会贸然接管。

快速反转。用户快速向上滑动后立即向下滑动，这种场景下状态机如果响应得太慢，会出现先被外层接管、又被内层抢回的情况。我的经验是，不要在状态机中对快速反转做专门优化，因为真实设备的触摸采样和桥接通信延迟决定了你做不到“时刻精确追随”。更稳妥的做法是在手感上接受“丢弃一小段输入”——具体就是让状态机在 DRAG_START 状态多停留 30ms 左右，用这个窗口期观察手势的主方向，再做出最终决策。这个 30ms 在体感上几乎不可感知，但能极大减少方向误判。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

这里整理一份我从答疑群里收集和亲身踩过的高频问题，按“现象 -> 原因 -> 解法”的结构列出来，方便你遇到问题时直接查。

5.2 避坑经验：三个“不要”和两个“一定要”

不要用 console.log 来观察滚动事件。滚动事件频率极高，尤其在低端设备上，打日志会严重影响帧率，导致你观察到的事件顺序完全失真。要用原生侧的 hilog 或 RN 侧的 debug 工具离线缓冲，然后再分析。

不要在外层 Scroll 上既设置默认滚动又挂自定义 PanGesture。这会造成事件被重复消费，绝大多数滚动闪烁问题都源自这种配置。要么完全交给默认滚动逻辑，要么完全接管，没有折中方案。

不要为了“内外都能滚”而给内层 FlatList 同时开启 nestedScrollEnabled 和外层 nestedScroll。一旦这条链路超过三层，状态传播会指数级复杂，调试成本极高。宁可重构页面结构，也不要保留超过两层的滚动嵌套。

一定要在 RN 侧测量真实的 contentOffset 和布局高度，不要只在 ArkUI 侧判断子组件的滚动边界。RN 的 FlatList 高度可能是动态计算的，与 ArkUI 侧拿到的高度不一致，容易导致边界判断失误。

一定要在正式上线前用设备性能监控工具跑一遍。如果只是真机手测没问题，低端机可能完全扛不住，因为滚动冲突对性能的消耗主要集中在每帧的事件分发和状态计算上。实测下来，双状态机方案在部分中端机上帧率稳定在 55 帧上下，而早期一边滚一边两边都响应的情况下，低端机直接掉到 30 帧。

5.3 我的经验心得：冲突不只是技术问题，更是产品决策问题

最后说点我自己最深的体会。NestedScroll 滚动冲突处理到最后，往往不是在“技术方案”里做选择，而是在“交互预期”里做取舍。你需要先明确一个问题：这个页面到底希望用户优先滚外层还是优先滚内层？不同产品可以给出完全不同的答案——优先外层意味着用户从任何位置滑动手势，页面总是先整体滚动，直到外层到边界后才让内层接管；优先内层则相反，用户进入列表区域后，就默认在内部滚动，直到内层到边界后才把手势“移交”给外层。

我之前带过的一个业务方就一直纠结“推荐列表在页面上方还是下方”这种问题，其实核心逻辑都一样，只是优先级的差异。一旦决定了优先级，后面的状态机、边距判定、通信时机都围绕这个优先级展开，整个实现会顺畅很多。如果你现在正被 OpenHarmony + RN 的滚动冲突折磨，我强烈建议你先停下来，把这个“谁优先”的问题和产品对齐，再去看代码，你会发现能少走很多弯路。