这个标题里写“半年磨一剑”，不是包装话术，是真花了半年。我有一个高频刷新的长列表页面，数据量从几百条涨到上万条之后，List 组件的性能开始撑不住：快速滑动白屏、帧率掉到 30 以下、滑动与点击事件偶发冲突。后来我把整页迁到了 RcList 组件，从头把它的数据懒加载、节点复用和事件处理机制摸了一遍，期间踩了不少坑，也沉淀出一套相对完整的用法。这篇文章就把我这半年的实践整理出来，重点讲清楚 RcList 组件的事件处理机制到底是怎么回事，以及在实际项目中怎么写、怎么避坑，给准备接 RcList 或者正在 RcList 里面挣扎的开发者做个参考。
RcList 是 ArkUI 递归容器系列里的列表组件，和 List 最大的区别在于它本质上是“按需实例化”的：数据不会一次性全部创建成节点，只有滚动进入可视区附近的内容才会被真实渲染，超出缓存范围的节点会被回收。正因为这套渲染机制，它的事件处理逻辑和传统 List 完全不是一个思路。如果你还是拿 List 的那套“全部节点都在，事件随便挂”的思维来写 RcList，大概率会遇到点击索引对不上、事件不触发、回调刷屏之类的问题。这篇文章会先拆解组件底层机制，再逐个讲事件类型和注册方式，最后给一个完整的消息中心示例，把点击、滑动删除、滚动监听、加载更多都串起来。
刚开始接触 RcList 的开发者，我建议先把基础概念过一遍；已经用了但频繁出问题的，可以直接跳到第 5 节踩坑记录与排查思路对着症状找答案。文章里所有代码我都在模拟项目 X 的工程里跑过，可以放心参考。
1. 先说说这个项目的来龙去脉
1.1 为什么从 List 迁到 RcList
我手上的页面是一个消息中心，一开始数据量几百条，List 完全扛得住。后来接入了系统通知、运营推送、用户互动三类消息，单账号最多能积攒上万条未读记录。问题就来了：List 是“全量渲染”的模型，不管数据有没有显示在屏幕上，它都会为每条数据创建对应的组件节点。一万条数据就是一万个节点，即使不做复杂布局，光节点的创建、测量、布局、绘制就够主线程忙一阵了。
我用性能工具抓过数据，List 在 3000 条数据时，滑动帧率开始跌破 45；到 8000 条时，快速滑动肉眼可见地一顿一顿，而且内存占用持续走高，因为所有节点都活着，即使离开屏幕也不销毁。这在低内存设备上尤其明显，应用后台切换回来甚至会出现卡死。
换到 RcList 之后，同样一万条数据，内存基本稳定，快速滑动帧率能维持在 55 以上。这里面的差距就是渲染模型决定的。RcList 的做法是：视口里能看到的 item 才创建，视口外再额外缓存一小批，超出缓存范围的节点回收销毁。数据量从几百到上万，对 RcList 来说只是“有没有更多数据可以懒加载”的区别，而不是“要创建多少节点”的区别。
我在迁移前做了个简单的对比测试，结论很直观：
| 对比项 | List | RcList |
|---|---|---|
| 渲染模型 | 全量创建节点 | 可视区 + 缓存区懒加载 |
| 10000 条数据内存占用 | 持续增长，明显偏高 | 稳定在视口 + 缓存所需水平 |
| 快速滑动帧率 | 3000 条时明显下降 | 10000 条仍相对稳定 |
| 节点回收 | 不回收 | 超出缓存范围自动回收 |
| 事件模型 | 全部节点可响应事件 | 只有已实例化节点可响应事件 |
当然，RcList 也不是银弹。它要求开发者对“懒加载”有正确的认知，尤其是事件这块，很多从 List 迁过来的人碰到的问题，本质都是把旧思维带到了新组件上。
1.2 半年时间都花在了哪里
这半年我大致分成了三个阶段。
第一个阶段是接入期，主要解决“怎么把 List 换成 RcList 并且跑起来”。这阶段其实不难，RcList 的写法和 List 很像，把List换成RcList，包一层ListItem，数据量用dataCount告诉组件，基本就能跑。真正的难点在第二阶段，也就是事件期。我开始在页面上加点击事件、滑动删除、滚动加载更多，结果问题一个接一个：点了 A 位置的数据，拿到的却是 B 的索引；滑动删除按钮偶发点不中；快速滚动时整个列表直接不响应点击。这些问题让我意识到，必须把 RcList 的事件处理机制彻底搞清楚，不能靠试错。
第三阶段才是沉淀期。我把组件的事件注册方式、触发时机、与其他手势的优先级全部整理成文档，形成了一套“先看是否实例化，再看事件类型，最后考虑手势冲突”的排查方法。这套方法论后来我用在团队里其他几个页面上，基本都能快速定位问题。这篇文章就是把这套方法论和具体案例结合起来的产物。
2. 核心机制：懒加载与节点复用是事件机制的地基
理解 RcList 的事件机制之前，必须先理解它的渲染机制。这两者强耦合，不先讲清楚地基，后面所有“为什么”都解释不通。
2.1 数据懒加载与可视区渲染
RcList 使用时要传入dataCount，这个值代表数据源的总条数。组件拿到总数之后，并不会真的创建这么多节点，而是根据当前滚动位置，只创建“视口内可见的 item + 视口外少量缓存 item”。
举个例子，如果手机屏幕能完整显示 8 条 item，你设置了cachedCount: 3，那么 RcList 在初始状态下大约只会创建 11 个左右节点：8 个在屏幕内，上方和下方各预留几个（具体策略与实现版本有关，但思路一致）。你往下滑的时候，新的 item 进入缓存区才开始实例化，同时滑出很远的节点会被回收。
这套机制对应到事件上，会产生一个非常重要的结论：RcList 里的事件不是注册在“数据”上，而是注册在“节点”上。一条数据如果没有对应的节点存在，它是不可能接收到任何点击或触摸事件的。所以你在处理事件回调时，永远要假设“当前存在的事件节点是有限的、动态变化的”，任何基于“全部数据都存在”的写法都会出问题。
2.2 节点复用与状态保持
RcList 的节点回收机制并不复杂，但“节点复用”的逻辑需要特别留意。当一条 item 滚出缓存区后，它的节点会被销毁或回收，之后另一条数据滚入可视区时，可能会复用刚才那个节点。
这种情况下，组件里如果存在“跟数据无关的临时状态”，比如某个 item 的展开/收起状态、某个输入框的未提交内容、某个开关的临时开合状态，就很容易丢失或者串数据。我在实际开发中遇到过用户反馈“我把第 3 条消息展开了，滚走再滚回来，它变成收起了”，这就是节点回收导致状态丢失的典型案例。
处理办法也很简单直接：一切 UI 状态都跟着数据走。不要在 item 组件内部用@State保存业务状态，而是把状态字段放进数据模型里，通过数据绑定驱动 UI。比如“是否展开”就用isExpanded字段，点击时修改这个字段，通知组件刷新。这样即使节点被回收再重建，重新读取数据时状态也还在。
> 注意：这是 RcList 开发里最重要的一条原则，没有之一。状态放数据里，索引显式绑定，这两点做到位，后面大部分事件问题都不会发生。
2.3 缓存参数对事件感知的影响
cachedCount不只是一个性能调优参数，它还直接影响“事件能感知的范围”。缓存区里的 item 虽然没有完全显示在屏幕上，但它们已经实例化了，是可以响应事件的。
我在调这个参数时发现一个现象：如果cachedCount设得很大，比如 10，那么快速滑动时事件响应的灵敏度会提高，因为更多的节点已经提前准备好，用户点下去时目标节点已经存在。但如果设得太大，内存和节点创建的开销会上升，反而可能拖慢首屏和滑动性能。
我的经验是cachedCount设成“单屏可见 item 数量 + 2”左右比较合适。假设一屏稳显 8 条，cachedCount设 10 到 12 就行。这个值不需要非常精确，但别设成 3 以下，否则快速滑动时容易出现空白占位，节点还没来得及实例化，滚动就过去了，视觉上会有一种“提前量不足”的生硬感。
3. 摸清 RcList 的事件处理机制
RcList 的事件体系可以粗略分成三类：滚动类事件、点击触摸类事件、以及组件自身的节点滚动监听框架。这三类事件的触发逻辑和适用场景都不同，一个一个拆开讲。
3.1 滚动类事件：onScrollIndex 与 onScrollVisibleContentChange
滚动类事件是 RcList 日常开发中最高频使用的，主要就是两个：
onScrollIndex会在滚动时上报当前显示区域第一条和最后一条 item 的索引，需要注意这里的索引是 RcList 内部的数据索引，从 0 开始。它适合做“当前滚动到哪了”的粗粒度监听，比如显示顶部返回按钮、记录阅读位置这类需求。
onScrollVisibleContentChange更加强大，它会在可视区内容发生变化时回调，携带可视区 item 的具体信息，比如起始索引、结束索引、当前可视区和总内容区的关系等。这个事件适合做精细化业务判断，比如“有没有滚到底部”“当前可视区有没有包含某一条数据”。
我实际项目里用这两个事件做了两件事：一是用onScrollVisibleContentChange判断滚动位置接近底部时触发加载更多，二是在阅读消息详情后返回列表时，用scrollToIndex把列表精确地定位到之前阅读的位置。
RcList({ dataCount: this.totalCount, cachedCount: 8, scrollOptions: { itemHeight: 100 } }) .onScrollIndex((start: number, end: number) => { // 记录当前可视区首尾索引 this.currentStartIndex = start; this.currentEndIndex = end; }) .onScrollVisibleContentChange((visibleInfo) => { // 判断是否接近底部，比如结束索引接近总数 - 5 时触发加载 if (visibleInfo.endIndex >= this.totalCount - 5) { this.loadMore(); } })这里有个细节：scrollOptions.itemHeight最好给上。RcList 需要知道 item 的高度才能精确计算滚动位置、滚动条长度以及目标索引对应的偏移量。如果 item 高度不固定，至少给一个估算值或常见值，否则快速滑动时的索引跳变会非常吓人，事件回调里的索引和实际看到的内容对不上。
3.2 点击触摸类事件：onClick 与 onTouch
ListItem上可以直接挂onClick和onTouch。
onClick是语义化的点击事件，适合处理“用户点了一下某个 item”的场景。它的触发条件相对严格：按下和抬起都要落在同一个节点上，且没有发生明显的滑动位移。onTouch则更加底层，按下、移动、抬起都会回调，能拿到事件坐标、压力、时间戳等信息。
我在做消息中心时，onClick用来处理“点击消息跳转详情”，onTouch用来实现自定义滑动删除逻辑。需要注意的是：如果某个 item 上同时有onClick和onTouch，触摸事件会先触发，然后系统根据手势判断是否满足点击条件，再决定是否触发onClick。如果你在onTouch里做了一些和滑动相关的操作，比如推动一个按钮显现，那么这次手势大概率不会被识别为“点击”，onClick就不会触发，这是符合预期的，不用觉得奇怪。
> 提示：判断该用哪个事件时，先想清楚需求是“想感知手指的物理动作”还是“想感知一次语义化的点击”。前者用onTouch，后者用onClick。混用时要明确它们不是互斥的，而是有先后关系的。
3.3 事件优先级与消费顺序
RcList 本身是一个可滚动的容器，它有自己处理手势的逻辑，比如垂直滑动、惯性滚动。如果你在ListItem上挂的onTouch或者onClick与滚动手势发生冲突，系统的处理原则是：先让容器判断这是不是一个滚动手势，如果是，就交给滚动逻辑处理，子节点的事件会被压制；如果不是滚动，才会分发给子节点。
这个逻辑从体验上讲非常合理。用户快速上下滑动列表时，手指下的 item 不应该把“滑动”误判成“点击”，否则列表会变得很难用。但在实际开发中，有些需求偏偏要在滑动过程中感知 item 的触摸，比如“滑动经过时高亮”这种交互。这种场景下，直接在ListItem上挂onTouch往往拿不到完整的移动轨迹，因为一旦系统判定这是滚动，触摸事件就会被容器接管。
我的解决办法是：在RcList外层包一个Stack或Column，在上面挂onTouch，通过事件坐标自行计算当前滑到了哪个 item。这个方案虽然要做坐标换算，但能绕开容器对子节点事件的接管逻辑，拿到完整的事件流。代价是计算量稍大，需要自己做索引命中判断。具体要不要这么干，得看产品需求的优先级。
3.4 节点滚动监听框架 nodeScrollListener
RcList 还提供了一套挂在组件上的滚动监听框架，可以用来注册滚动开始、滚动中、滚动停止等回调。从事件精细度来看，它比onScrollIndex更接近底层，适合做与滚动动画、位置精确计算相关的功能。
我主要用它来做三个事情：
- 滚动停止后统一收起已经展开的滑动删除按钮；
- 滚动过程中实时更新某个悬浮组件的偏移位置，做一个“跟随列表但又有自己固定逻辑”的复杂头部；
- 区分“用户手动滚动”和“代码调用滚动”，避免在代码滚动的过程中误触发业务逻辑。
private nodeScrollListener = { onWillScroll: (event) => { // 滚动即将开始，可以在这里做拦截或记录 }, onDidScroll: (event) => { // 滚动中持续回调，可以拿到实时偏移量 }, onScrollStart: (event) => { // 滚动开始 this.isScrolling = true; }, onScrollStop: (event) => { // 滚动停止，收起所有展开的删除按钮 this.isScrolling = false; this.closeAllSwipeButtons(); } }这套监听框架和onScrollIndex的使用场景有重叠但不冲突，onScrollIndex更偏向“数据层面的可视区变化”，监听框架更偏向“物理滚动层面的实时反馈”。
4. 应用示例：消息中心实战
这一节我把前面讲到的机制串起来，做一个完整的小项目示例。场景是“某跨平台系统”的消息中心：有三类消息，支持点击查看详情，支持左滑出现删除按钮，支持滚动到底部自动加载更多。
4.1 场景定义与数据模型
先定义消息数据模型。注意我前面说的原则：状态跟着数据走，所以数据模型里除了业务字段，还需要放一些 UI 状态字段，比如isDeleteMode这种。
interface MessageItem { id: string; type: 'system' | 'operation' | 'interact'; title: string; content: string; timestamp: number; isRead: boolean; isShowDelete: boolean; }isShowDelete控制当前 item 是否展示删除按钮。这个状态放在数据里，才能保证节点回收重建后状态不丢失。
然后准备数据源，用一个普通数组维护，初始给 50 条模拟数据。真实项目里这些数据通常来自接口，但核心逻辑一致。
4.2 基础页面与懒加载配置
接下来是最核心的部分：搭一个 RcList 页面，配好数据、缓存、滚动事件。
@Entry @Component struct MessageCenterPage { @State messageList: MessageItem[] = []; @State totalCount: number = 0; private pageIndex: number = 1; private scroller: Scroller = new Scroller(); aboutToAppear(): void { // 初始化数据 this.messageList = this.generateMockData(0, 50); this.totalCount = this.messageList.length; } private generateMockData(startIndex: number, count: number): MessageItem[] { let result: MessageItem[] = []; for (let i = 0; i < count; i++) { result.push({ id: `msg_${startIndex + i}`, type: i % 3 === 0 ? 'system' : (i % 3 === 1 ? 'operation' : 'interact'), title: `消息标题 ${startIndex + i}`, content: '这是一条模拟消息内容，用于演示 RcList 组件的事件处理机制。', timestamp: Date.now() - i * 1000, isRead: false, isShowDelete: false }); } return result; } build() { Column() { RcList({ dataCount: this.totalCount, cachedCount: 10, scrollOptions: { itemHeight: 90 } }) { ForEach(this.messageList, (item: MessageItem) => { ListItem() { MessageRow({ item: item, index: this.messageList.indexOf(item), onItemClick: (index: number) => this.onMessageClick(index), onDeleteClick: (index: number) => this.deleteMessage(index) }) } }, (item: MessageItem) => item.id) } .onScrollIndex((start: number, end: number) => { this.currentStart = start; this.currentEnd = end; }) .onScrollVisibleContentChange((visibleInfo) => { // 可视区末尾接近数据末尾时加载更多 if (visibleInfo.endIndex >= this.totalCount - 5) { this.loadMoreData(); } }) } .width('100%') .height('100%') } private onMessageClick(index: number): void { // 点击消息，标记已读并跳转详情 this.messageList[index].isRead = true; // 模拟跳转逻辑 } private deleteMessage(index: number): void { // 删除指定索引的消息 this.messageList.splice(index, 1); this.totalCount = this.messageList.length; } private loadMoreData(): void { if (this.isLoadingMore) return; this.isLoadingMore = true; // 模拟异步加载 setTimeout(() => { let newData = this.generateMockData(this.messageList.length, 30); this.messageList = this.messageList.concat(newData); this.totalCount = this.messageList.length; this.isLoadingMore = false; }, 500); } }这段代码看着简单，里面有几个关键点要单独说一下。
第一，ForEach的第三个参数，也就是 key 生成器，我用了item.id。RcList 的节点复用和 diff 更新都依赖 key 的唯一性，如果 key 不稳定，比如用数组下标，删除一条数据后后面所有 item 的索引都会变，很容易出现 UI 错乱和事件错位。只用 id 作为 key 比较稳。
第二，onScrollVisibleContentChange里做加载更多判断时，我用的是“结束索引距离总数还剩 5 条”的触发条件，这是为了避免用户已经滚到底部时还要再多滑一下才能触发。触发后要用isLoadingMore做防重，否则回调触发频率很高，很容易发重复请求。
第三，dataCount必须和messageList.length保持同步。这个值告诉 RcList“一共有多少个 item 可以懒加载”，如果新增了数据却不更新dataCount，滚到底部也不会渲染新数据；反过来，如果删除数据后dataCount没减，组件会认为后面还有数据，滚动位置会非常诡异。
4.3 子组件中的事件绑定
列表项我拆成了子组件MessageRow，这样方便组织点击、滑动删除等逻辑。子组件里接收item和index，注意index一定要从父组件显式传过来，不要在子组件内部通过遍历或计算去推。原因很简单：RcList 懒加载时，子组件实例和数据的对应关系是通过当前渲染周期决定的，如果子组件内部再自行计算索引，很容易跟数据源脱节。
@Component struct MessageRow { item: MessageItem; index: number; onItemClick: (index: number) => void = () => {}; onDeleteClick: (index: number) => void = () => {}; build() { Stack({ alignContent: Alignment.End }) { // 删除按钮层 Row() { Button('删除') .onClick(() => { this.onDeleteClick(this.index); }) } .width(80) .height('100%') .justifyContent(FlexAlign.Center) .backgroundColor('#FF3B30') .visibility(this.item.isShowDelete ? Visibility.Visible : Visibility.Hidden) // 内容层 Row() { Column() { Text(this.item.title) .fontSize(16) .fontWeight(FontWeight.Medium) Text(this.item.content) .fontSize(14) .fontColor('#666666') .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) } .alignItems(HorizontalAlign.Start) .layoutWeight(1) Text(this.formatTime(this.item.timestamp)) .fontSize(12) .fontColor('#999999') } .width('100%') .height(90) .padding({ left: 16, right: 16 }) .backgroundColor(this.item.isRead ? '#FFFFFF' : '#F0F7FF') .onClick(() => { this.onItemClick(this.index); }) .onTouch((event: TouchEvent) => { this.handleTouch(event, this.index); }) } .width('100%') .height(90) } private handleTouch(event: TouchEvent, index: number): void { // 简化逻辑：根据触摸横向偏移判断是否展开删除按钮 if (event.type === TouchType.Move) { // 记录横向位移，超过阈值后设置 isShowDelete } else if (event.type === TouchType.Up) { // 判断是否需要收起 } } private formatTime(timestamp: number): string { // 格式化时间显示 return new Date(timestamp).toLocaleTimeString(); } }这里我把删除按钮的显隐直接绑定到item.isShowDelete，而不是用子组件自己的@State，这样节点被复用和回收时状态不会乱。
还有一个值得注意的细节：内容层的onTouch会在用户横向滑动时被触发，但系统在判定为滚动后，这个事件可能被容器接管，导致handleTouch里的 Move 回调不全。如果要做真正流畅的滑动删除，最好是结合手势系统，比如用PanGesture绑定到内容层，自行管理横向偏移。示例里我为了保持代码简洁，用的是简化写法，真实项目里建议用 Pan 手势接住横向动作，避免和 RcList 的垂直滚动互相干扰。
> 注意：PanGesture绑定到ListItem上时，要先明确手势的方向限制。垂直滑动手势留给 RcList 做列表滚动，横向滑动手势做删除交互，两者通过方向区分，能同时存在而不打架。
4.4 滚动监听与加载更多
加载更多的触发我在基础页面里已经写了，这里补充一个细节：onScrollVisibleContentChange的回调频率很高，只要可视区有任何变化就会触发。如果你的加载更多逻辑里做了比较重的操作，比如网络请求前的参数组装、列表排序、数据去重，建议加一层防抖。我的做法是设置一个“是否正在加载”的标志位，再加一个“上次触发时间”，距离上次触发不足 1 秒就不再触发。
private loadMoreData(): void { if (this.isLoadingMore) return; const now = Date.now(); if (now - this.lastLoadTime < 1000) return; this.lastLoadTime = now; this.isLoadingMore = true; // 模拟异步加载数据 }滚动事件里还有一个常见的坑：如果在滚动回调里直接修改messageList，比如重置数组、大量插入数据，页面会立刻重新计算全部可视区 item，容易造成滚动位置跳动。我的建议是滚动回调里尽量只做“标记”和“记录”，真正的数据操作放到滚动停止事件里做，比如在nodeScrollListener.onScrollStop里再执行加载逻辑。这样既不会打断用户的滚动节奏，也减少了滚动过程的计算压力。
5. 踩坑记录与排查思路
半年下来踩过的坑不少，这里按“症状→原因→解决方案”的格式整理成速查表，再挑几个典型的展开讲。
5.1 高频踩坑：点击索引与预期不一致
症状：点击屏幕第 3 条消息，拿到的索引却是 0 或 10，跳转详情时打开的是完全不相干的数据。
原因：大概率是在子组件里用“数组下标”或者“遍历时序号”作为事件回调参数，没有把真实的数据索引显式传进来。RcList 懒加载后，节点和数据的对应关系是动态的，某个节点可能先渲染了第 10 条数据，随后被复用为第 20 条数据，如果回调里的 index 写死或者从其他途径推算，就会错。
方案：数据源数组是唯一的真相，索引必须在渲染每条 item 时从父组件显式传入，而且确保传入的索引和数据在数组中的实际位置一致。删除操作过多时，还要小心索引漂移——建议每次都根据item.id去定位数据，而不是依赖之前保存的索引。
5.2 高频踩坑：滚动后事件不响应
症状：页面稳定显示时点击正常，但快速滚动后立刻点击，前几次点击没反应，或者要按两次才触发。
原因：滚动停止后，RcList 还在进行节点的回收和重新实例化，你点下去的位置可能刚好是一个刚被回收、还没来得及重建的节点区域。此时该处没有真实的 item 节点，事件自然没有接收者。
方案：在onScrollStop之后设一个极短的延迟再恢复交互，或者给cachedCount适当加大，让更多节点提前准备。前者是产品层规避，后者是机制层优化。我个人偏向后者，一屏 8 条时cachedCount给 10 以上，快速滑动后立刻点击的响应率会明显提高。
5.3 高频踩坑：回调刷屏导致帧率下降
症状：滚动过程中onScrollVisibleContentChange或nodeScrollListener.onDidScroll频繁触发，回调里又做了数组遍历、样式修改等操作，滑动开始变得卡顿。
原因：滚动事件回调天生高频，如果回调里存在重操作，比如每次都对全量数据进行过滤、排序或触发@State变更，就会在滚动过程中产生大量布局计算。
方案：明确区分“滚动中”和“滚动停止”能做的事。滚动中只允许记录偏移量、索引等轻量状态；涉及数据操作、网络请求、复杂计算的逻辑，一律放到onScrollStop或防抖函数里。如果某个状态必须在滚动中实时更新，比如悬浮头部的位置，可以考虑用无状态的方式直接改组件的偏移属性，避免触发整棵树的重新渲染。
5.4 高频踩坑：删除多条后列表位置跳动
症状：连续删除几条消息后，列表会突然跳到顶部，或者滚动位置看起来“少了几个身位”。
原因：这是因为删除后dataCount更新了，但滚动位置还在原来的偏移量上，组件会基于新的数据总量重新计算可视区，导致视觉上的跳动。
方案：删除时记录当前可视区第一条数据的 id，数据更新后再用scrollToIndex定位到原来的位置。注意这里不能用索引定位，因为删除后索引已经变了，要用 id 先找出新的索引，再滚动。
5.5 高频踩坑：item 高度不一致导致滚动位置漂移
症状：每条消息内容长短不一，高度从 80 到 140 不等，快速滑动时列表位置和滚动条位置对不上，scrollToIndex定位不准。
原因：scrollOptions.itemHeight给了固定值，但实际 item 高度并不固定，估算值和真实值的偏差会在滚动距离上不断累积。
方案：要么给 item 一个固定高度，内容超出后做截断，保证每条 item 高度一致；要么做高度动态测算，在数据加载后逐个测量并缓存。后者的实现成本更高，除非业务强制要求展示完整内容，否则我更推荐统一高度加截断的方案，性能和稳定性都好很多。
6. 关于这套机制，我的最后一点体会
踩了无数个坑之后，我最大的感受是：RcList 的事件机制并不是设计得很复杂，它只是把“节点可能存在，也可能不存在”这个特性贯彻得非常彻底。所有的问题，只要能记得“事件是挂在节点上的，节点是动态回收的”，基本都能找到合理的解法。
一个很实用的习惯是：在写任何ListItem内部的事件回调之前，先问自己三个问题——这条数据有没有对应的真实节点？如果节点被回收重建，状态还在不在？回调里拿到的索引是不是数据源中的真实索引？三个问题全部过一遍，大部分隐患在写代码阶段就能排除。
如果你正准备接手一个 RcList 页面，我给的建议是不要一上来就抄网上零散的用法，先花半小时把组件的渲染模型和事件模型在脑子里过一遍，再开始动手。RcList 的学习成本比 List 高，但一旦把它的事件处理逻辑理顺，后面做长列表性能优化、复杂交互扩展会顺手很多。我现在这个消息中心页面跑了半年，稳定性和流畅度都符合预期，这套方法论也应用到了团队里其他几个长列表场景，整体反馈还不错。
