企业官网建设流程全解析

1. 项目背景与需求拆解

1.1 OpenHarmony上的RN开发到底处于什么状态

先说结论：在OpenHarmony上用React Native做复杂交互组件，是完全可行但不太省心的一件事。

很多人听到“OpenHarmony支持RN”，第一反应是“那不就等于在鸿蒙上写Android吗”。这个理解偏差挺大的。OpenHarmony的RN支持，本质是通过一套C++桥接层把RN的渲染管线映射到ArkUI的组件体系上，JS侧大部分代码逻辑能复用，但凡是依赖平台私有API、原生UI组件、以及特定滚动容器行为的交互，都得重新验证一遍。换句话说：业务页面、数据流、状态管理这些东西，RN开发者可以无痛迁移；但像CollapsibleTab这种重度依赖手势协调和滚动事件的组件，就得做好“用RN思维重新实现一遍”的心理准备。

我这个项目就是从这种预期开始的。团队里有一个现成的电商App，React Native版本已经跑了两三年，其中一个核心页面是“品牌店铺首页”——顶部是店铺Banner和品牌信息，下面是分类Tab和商品列表，用户上滑时Banner区域折叠、Tab吸顶。在iOS和Android上这个效果很成熟了。但公司要求出一版OpenHarmony的原生应用，业务方又不希望为鸿蒙单独维护一套代码，于是就有了“把RN页面原样搬到OpenHarmony”的需求。

我当时的判断是：页面能搬，但CollapsibleTab这个组件大概率要单独处理。因为它在Android上是基于原生CoordinatorLayout的行为写的，在iOS上基于UICollectionView的自定义Layout，而RN在OpenHarmony上能把滚动事件稳定抛出来就不错了，更别提第三方库内部引用的那些原生依赖。

1.2 CollapsibleTab的真实交互拆解

在动手之前，我先把CollapsibleTab的交互细节拆成了四个独立问题，因为每个问题的实现难度和风险完全不一样：

• 头部区域的高度折叠：Banner区随着列表上滑逐步收缩，从原始高度（比如260dp）收缩到只保留Tab栏的高度（比如56dp）。
• 折叠的力学过程：不是只有“展开”和“折叠”两个状态，而是中间过程要跟随手指位移，松手后根据位置决定弹回或吸顶。这个边界条件特别容易踩坑。
• Tab吸顶与内容联动：Tab栏吸顶后，下方内容区域要切换到对应Tab的商品列表，同时列表有自己的滚动逻辑。
• 页面切换时的状态保持：用户滑到某个Tab第30个商品的位置，切走再切回来，滚动位置和头部状态都得恢复。

这四个问题里，第1和第2个是视觉与手势核心，第3个是数据层，第4个是最容易被忽略的兜底逻辑。我见过很多开源方案是实现了1和2就宣布完工，结果一切换Tab，头部“哐当”一下弹回顶部——在Demo里可以接受，在真实业务里是会被测试提单的。

另外还要注意一个OpenHarmony特有的细节：RN在OpenHarmony上的ScrollView/FlatList滚动事件，并不一定严格保证每个帧都回调。在Android上，滚动事件的回调在绝大多数情况下和UI刷新同步；在OpenHarmony的适配层上，某些API级别下的滚动事件会有合并或延后的情况。这意味着动画驱动如果设计成“每个事件都同步更新UI”，在某些版本上会看到卡顿或跳跃。这个我在后文会细说。

2. 技术路线选型：为什么我没有直接上第三方库

2.1 主流折叠标签页库在鸿蒙上的适配现状

RN生态里最知名的折叠标签页方案是react-native-collapsible-tab-view（以下简称RNCollapsibleTabView）和react-native-tab-view配合自定义Header。我在Android和iOS上用过前者，功能确实全：支持吸顶、多Tab、Lazy加载，内部基于react-native-pager-view和Reanimated实现，手感平滑。

但到了OpenHarmony上，这套方案的适配风险非常大。依赖链是：RNCollapsibleTabView → react-native-pager-view（原生ViewPager的封装）→ RN在OpenHarmony上的原生组件注册和桥接能力。OpenHarmony的RN适配层目前对原生组件的支持还在逐步完善，ViewPager这种“一个容器管多个页面手势分发”的组件，天然就对桥接层的底层实现敏感。我在项目里做了两次技术预研：

第一次尝试直接把RNCollapsibleTabView跑起来。结果在OpenHarmony的调试模式下，页面能渲染，但横向滑动切Tab的手势识别很模糊，经常被FlatList的纵向滚动“吃掉”。而且RNCollapsibleTabView内部对Android原生的SwipeRefreshLayout联动依赖很强，OpenHarmony上没有对应实现，下拉刷新一触发整个折叠逻辑就崩了。

第二次我尝试换思路：用react-native-tab-view做Tab切换，自己写折叠头部的动画。react-native-tab-view不依赖原生ViewPager，它内部用PanResponder自己处理横向手势，桥接层的依赖少很多。这一步倒是能跑通，但问题变成了我需要在FlatList和TabView之间维护一个共享的滚动状态，而这个组件库并不关心滚动偏移量的外部控制，从数据流通往上看始终是“两层皮”。

两轮预研之后我做了个决定：第三方的“大而全”方案不适合这条技术路线，至少当前版本不适合。问题的本质不在于库本身写得好不好，而在于这种第三方库的抽象层在Android上建立了一套“系统级”假设，一旦底层系统换了，假设全部作废。而OpenHarmony的RN生态还处在“能把基础组件跑稳”的阶段，承受不起这种高阶假设。

2.2 手写方案的优势与代价

既然大而全的库不能直接搬，剩下的路就是自己实现一个精简版。我当时评估了三条子路线：

路线A：基于FlatList的ListHeaderComponent + 滚动监听。让FlatList的ListHeader是“头部+Tab栏”，通过监听滚动偏移量，把Banner区域的高度压缩成一个动画值。这个方案最贴近RN核心，不引入任何额外依赖，缺点是要自行处理吸顶、Tab切换、状态缓存，工作量大。

路线B：头部固定、内容区平移。把Banner和Tab栏放在FlatList外面的View里，内容区向下偏移头部高度，滚动时内容区在头部下方滑动。这个方案实现起来更简单，但头部无法“真实折叠”，只表现为内容区从头部下方滑出，视觉上不够自然，业务方大概率不认可。

路线C：基于Reanimated v2的手写方案。Reanimated在OpenHarmony上已经有了初步适配，可以跑起来，但版本匹配很苛刻，且升级路径不清晰，一旦Reanimated更新可能导致整个工程不可用。

我最后选了路线A的变种：不依赖Reanimated，只用RN自带的Animated API驱动折叠动画。理由很直接——Animated API是RN核心自带能力，OpenHarmony适配层对它支持最完整，不依赖第三方原生模块。代价是：吸顶逻辑和切换缓存必须自己写得足够严谨。

2.3 方案对比与最终选型对照表

表格里最后一列是我最终的选择。手写方案看起来复杂，但每个环节可控，出了问题不需要把一个第三方库的源码翻半天。下面进入具体实现。

3. 核心实现原理与关键参数设计

3.1 折叠的本质：一个动画值驱动的布局变化

CollapsibleTab的视觉核心，其实是一个线性映射问题：滚动偏移量 → 头部高度变化。

假设展开状态时头部总高度是260（单位是dp，下同），其中Banner区域高度是204，Tab栏高度是56。当用户向上滚动列表时，FlatList的滚动偏移量从0开始增长，我们希望Banner区的高度从204逐渐变成0，也就是整个头部从260收缩到56。这里的对应关系是：

• Banner高度 = 204 - scrollY（当scrollY小于204时）
• Banner高度 = 0（当scrollY大于等于204时）
• Tab栏的吸顶位置：scrollY >= 204时，Tab栏固定在最顶部

用Animated API表示：

const HEADER_EXPANDED_HEIGHT = 260; const HEADER_COLLAPSED_HEIGHT = 56; const TAB_BAR_HEIGHT = 56; const BANNER_EXPANDED_HEIGHT = HEADER_EXPANDED_HEIGHT - TAB_BAR_HEIGHT; const scrollY = useRef(new Animated.Value(0)).current; const bannerHeight = scrollY.interpolate({ inputRange: [0, BANNER_EXPANDED_HEIGHT], outputRange: [BANNER_EXPANDED_HEIGHT, 0], extrapolate: 'clamp', }); const headerHeight = scrollY.interpolate({ inputRange: [0, BANNER_EXPANDED_HEIGHT], outputRange: [HEADER_EXPANDED_HEIGHT, HEADER_COLLAPSED_HEIGHT], extrapolate: 'clamp', });

这里有两处关键设计。

第一，“inputRange”的终点不取260而取204，原因是204之后Banner已经消失，头部高度就不该继续变化了，否则电影效果的“惯性滚动”阶段头部会缩成负数。很多人第一次写这类动画时会顺手把终点设为头部最大高度，结果滚动超过204后会发现头部高度还在变，看起来整个页面被“压缩”了。

第二，interpolate的extrapolate必须设为clamp，否则列表快速回弹时，头部高度会瞬间出现负值或者超过最大值的突变。

高度驱动的方式有很多细节：headerHeight仿真在Animated上用起来是顺畅的，因为Animated.Value生成后，JavaScript线程只跑一次interpolate逻辑，后续更新是通过原生驱动完成的。但这里有个很隐蔽的坑：Animated的“使用原生驱动”是有限制的，不能用它驱动height属性变化。原因是原生驱动（useNativeDriver）只支持transform和opacity这类不需要重新布局的属性，height属性变化必须回流到阴影树（Shadow Tree）布局，一旦走了JS线程的帧循环，性能和稳定性都会大打折扣。

我当时在真机上的体验：直接给头部外层View的height绑定动画值，在OpenHarmony上滚动时会感觉到明显的“头部高度变化晚半拍”的延迟感。排查后发现是驱动模式问题。所以我的最终方案是：Banner区域的容器不直接变高度，而是用transform的translateY和scaleY组合来模拟折叠效果，这样可以直接开启原生驱动。

3.2 手势事件协调的关键细节

折叠动画只是UI表现，真正容易翻车的是手势协调。CollapsibleTab的手势事件本质上涉及三个方向的竞争：

• 垂直方向上，列表内容滚动
• 垂直方向上，头部折叠（与列表滚动同源，但需要过滤）
• 水平方向上，Tab切换

当用户的触摸起点在Tab栏区域时，水平滑动应该切换Tab，垂直滑动应该滚动下方内容列表。当触摸起点在Banner区域时，垂直滑动应该同时驱动内容列表滚动和头部折叠。这里要处理的核心问题是：RN的FlatList在OpenHarmony上默认只响应一个ScrollView的手势，而Tab切换如果用横向ScrollView实现，两个ScrollView在同一个页面上会互相抢手势。

我的处理方式是：Tab切换不用横向ScrollView，而是用三个FlatList实例，通过组件的状态切换显示哪一个。Tab栏上只做点击切换，不响应滑动切换。这样横滑手势就根本不存在了，手势冲突直接消失。

这个取舍在交互上有细微差别：用户不能通过“左右滑动Tab栏”来切换页面，只能点击。业务方一开始要求保留横滑，但评审时我给了两个选择：要么保留横滑（同时接受实现风险翻倍），要么牺牲横滑（换稳定性和交付时间）。业务方选了后者。这是技术决策推动产品决策的典型案例。

3.3 滚动事件的采集与降频处理

RN中监听滚动偏移量最直接的方式是在FlatList的onScroll上调用Animated.event：

<FlatList onScroll={Animated.event( [{ nativeEvent: { contentOffset: { y: scrollY } } }], { useNativeDriver: true } )} />

这里有个参数值得特别关注：scrollEventThrottle。它决定滚动事件回调的节流频率，单位是毫秒。默认值在Android上通常够用，但在OpenHarmony上我发现默认参数会导致滚动事件丢失，尤其是快速滑动时，Banner折叠的动画会“跟不上手指”。我最终把它显式设为16（也就是接近60帧的间隔）：

<FlatList scrollEventThrottle={16} onScroll={Animated.event(...)} />

为什么是16而不是更小？因为16ms约等于一帧的间隔。RN的事件循环本身还有开销，如果设为4或8，滚动的每一帧事件都会进入JS线程处理，会导致JS线程过载，反倒让列表渲染卡顿。16是一个在大多数平台上验证过的平衡值，OpenHarmony上实测也合适。

3.4 Tab切换与滚动位置缓存

Tab切换后，每个Tab页都有自己独立的滚动偏移量。如果只是简单切换FlatList实例，用户切走再切回来，会发现列表回到顶部，头部也自动展开——这种体验是绝对不能接受的。

我当时的做法是为每个Tab页维护一个scrollY快照。在FlatList的onScroll回调里，除了更新Animated.Value，还把当前偏移量写入对应Tab的ref：

const scrollOffsets = useRef({}).current; const handleScroll = (tabKey: string, y: number) => { scrollOffsets[tabKey] = y; scrollY.setValue(y); // 统一的折叠驱动值 };

切换Tab时，根据目标Tab的缓存偏移量，手动设置scrollY的初始值，避免头部状态错乱。这里有个细节：切换Tab后，新的FlatList挂载时，要把contentOffset设为缓存的偏移量。RN的FlatList支持通过contentOffset属性设置初始滚动位置，但前提是页面必须在挂载时知道这个值，不能等渲染完成后再去scrollTo。实测中发现，如果页面的列表数据是异步加载的，等到数据到了再去scrollTo，视觉上会先闪烁一次顶部内容。

我的解决方法是：把每个Tab的内容区域拆成一个独立的组件，Tab切换时先渲染一个占位容器，测量高度后用FlatList的scrollToOffset恢复位置，再在onContentSizeChange里做二次校准。这样虽然代码多一点，但视觉上不会有明显跳动。

4. 从零搭建可复现的折叠标签页

4.1 工程准备与基础依赖

动手之前，先把工程基础打牢。我用的开发环境是DevEco Studio（某版本的IDE工具）配合OpenHarmony SDK，通过某开源适配组件把RN实例跑在原生Ability上。这里的核心依赖只有两个：RN的核心库（react和react-native）和鸿蒙适配层对应的RN模块。额外还引入了@react-native-community/hooks用来做视图尺寸测量，其余依赖为零。

需要说明，我整个方案刻意避免引入任何涉及手势库或动画库的依赖。原因在于，OpenHarmony上的RN适配层功能完善度是跟OpenHarmony API Level强相关的：在某个API Level下能用的原生能力模块，可能在另一个版本里行为有变化。依赖越少，版本波动导致的兼容性问题越少。一个组件消耗的开发时间里，三分之一是业务逻辑，三分之二是排查兼容性问题，这句经验放在鸿蒙上特别应验。

4.2 构建核心折叠头部组件

折叠头部的UI结构拆成两层：外层容器（高度是动态的），内层Banner区域（高度从204压缩到0），Tab栏在头部高度收缩到最后56时保持原位。

type Props = { bannerHeight: Animated.Value; tabBar: React.ReactNode; banner: React.ReactNode; }; export const CollapsibleHeader = ({ bannerHeight, tabBar, banner }: Props) => { return ( <Animated.View style={[ styles.headerContainer, { height: headerHeight }, ]} > <Animated.View style={[ styles.bannerWrapper, { height: bannerHeight, opacity: bannerHeight.interpolate({ inputRange: [0, 100], outputRange: [0, 1], extrapolate: 'clamp', }), }, ]} > {banner} </Animated.View> <View style={styles.tabBarWrapper}>{tabBar}</View> </Animated.View> ); };

上面代码里的headerHeight和bannerHeight，都来自我前面说的interpolate映射。注意opacity的处理：当Banner高度压缩到接近0时，如果还留着透明度100%，用户会看到一个“文字挤成一团”的帧，很难看。所以我这里让透明度从100开始逐渐变0，等于在高度100到0之间做了淡出。

这有一处细节值得说明：bannerWrapper的height属性，我最终用Animated.View的JS驱动来跑（不开启useNativeDriver），而外层headerContainer的高度也一样。之所以这里不用translateY替代，是因为Banner内部的商品title、促销文案在高度压缩时会发生换行和间距变化，这些效果的动画性质是“布局型”的，只能用height驱动。在实际中，我发现只要高度动画只作用于头部组件本身，不涉及FlatList大列表的布局重排，性能还是可以接受的。以后如果有版本升级，Reanimated的布局动画能力是个更优雅的替代，但目前不碰。

4.3 集成FlatList与吸顶逻辑

吸顶逻辑的核心是：当滚动偏移量超过Banner可折叠区间时，Tab栏要从头部内部“粘”到屏幕顶部。我的方式是利用FlatList的stickyHeaderIndices特性。把ListHeaderComponent拆成两部分：Banner区 + Tab栏，当FlatList滚动到Tab栏接触顶部时，stickyHeaderIndices把它钉住。

<FlatList data={productList} renderItem={renderProduct} keyExtractor={(item) => item.id} scrollEventThrottle={16} onScroll={Animated.event( [{ nativeEvent: { contentOffset: { y: scrollY } } }], { useNativeDriver: true } )} ListHeaderComponent={ <CollapsibleHeader bannerHeight={bannerHeight} tabBar={renderTabBar()} banner={renderBanner()} /> } stickyHeaderIndices={stickyIndices} />

stickyHeaderIndices的取值需要算准：因为ListHeaderComponent整体被视为索引0，如果Tab栏位于头部组件内部的第二个子元素，它在FlatList层面的索引比较复杂。我在实现了第一个版本后发现，直接把Tab栏做进ListHeaderComponent里再配合stickyHeaderIndices，在OpenHarmony上会导致吸顶瞬间出现“闪烁”——Tab栏先消失一下再出现在顶部。排查原因是：sticky的实现依赖对ListHeader子元素的裁剪，OpenHarmony的RN适配层在这个裁剪行为上跟Android不完全一致。

最终我改用了一个更朴素但稳的方案：Tab栏在视觉上可以不放进ListHeaderComponent，而是把Banner和Tab放在FlatList外的外层View里。列表滚动时，Banner区域随着列表滚上去（其实是滚出视口），Tab栏组件本身一直在屏幕顶部，只是视觉效果等同于吸顶。这个“假吸顶”方案的体验跟真吸顶差距极小，但避开了对stickyHeaderIndices的依赖。

结构变成：

<View style={{ flex: 1 }}> <Animated.View style={{ height: headerHeight }}> <Animated.View style={{ height: bannerHeight }}> {renderBanner()} </Animated.View> </Animated.View> <View style={{ height: TAB_BAR_HEIGHT }}> {renderTabBar()} </View> <FlatList // 列表内容，滚动区域扣除头部和Tab栏高度 /> </View>

这里列表的滚动区域不是从屏幕顶部开始，而是从Tab栏下方开始。Banner区的“跟随滚动折叠”效果通过Animated高度实现，Tab栏永远固定在顶部。这个方案的吸顶是天然的，不需要额外处理，而且滚动偏移量和头部折叠的联动关系没有改变。代价是：头部折叠动画的滚动位移感要额外处理，否则看起来像是Banner自己缩没了，而不是被列表顶上去的。

我在两个方案间犹豫了很久，最终选择了“假吸顶”。原因是：在真实业务中，Banner区上方通常还有状态栏和安全区，列表内容的第一屏会有一部分被头部挡住，这种遮罩关系在假吸顶方案里更容易控制。真吸顶方案在数据量小、快速滚动时，偶尔会出现Tab栏卡在中间位置的情况，不好排查。

4.4 在OpenHarmony原生工程中接入组件

RN工程的部分跑通后，还需要解决的是怎么把它装进OpenHarmony应用里。大致流程是：

• 使用某开源适配层提供的原生组件宿主能力，创建一个承载RN页面的Ability。
• 在工程中配置RN的资源路径和bundle入口，让原生应用加载RN页面。
• 通过RN实例的组件注册表，把CollapsibleTab包装成可复用的页面组件。
• 在原生侧通过ArkUI的插件机制把RN容器放置到指定页面位置。

这里面我唯一想提醒的是：把RN页面的bundle打进HSP时，要确认JS bundle的压缩方式和资源路径在加载时没有大小写不匹配的问题。由于OpenHarmony的文件名规范大小写敏感，而RN在生成资源目录时默认使用小写命名，一旦HSP里某个资源名有大写字母，就会发现页面白屏且日志里报“找不到资源”。这个坑我在第一次打包时踩过，当时排查了很久。

5. 真机调试中踩过的坑和排查方法

5.1 动画突然失效，头部直接跳到折叠态

现象：连续快速滚动时，Banner区域偶尔表现为高度从204直接变0，中间的动画过程没有了。

排查过程：日志里发现了ScrollView的滚动事件丢失的特征。原因是FlatList在快速滚动的“惯性阶段”，onScroll事件的回调频率大幅下降，Animated.Value的setValue跳过了中间的插值点。这里的本质不是动画被截断，而是事件源本身不够“密”。解决办法有两个层面：

第一，把scrollEventThrottle从默认值调小到16，确保惯性阶段也有足够的采样频率。

第二，对Animated.Value的更新做“补间”：当检测到连续两个滚动事件之间的偏移量差值大于一个阈值（比如200）时，直接在Animated.Value上面调用setValue做一次中间补值，而不是等待下一个事件。补间代码如下：

const onScroll = (event) => { const y = event.nativeEvent.contentOffset.y; const delta = y - lastYRef.current; if (delta > 100) { // 跳变过大，补一个中间值，避免头部瞬移 scrollY.setValue(lastYRef.current + delta * 0.5); requestAnimationFrame(() => scrollY.setValue(y)); } else { scrollY.setValue(y); } lastYRef.current = y; };

这个方法不完美，但在OpenHarmony上实测有效，能明显减少快速滚动中头部“跳帧”的概率。

5.2 列表滚动时Tab栏被“带上去”

出现这个问题的场景是：用户正在商品列表里快速下滑，手指松开的瞬间，Tab栏会有一个轻微的向上位移。原因在于，Tab栏在假吸顶方案里是固定定位的，但在快速滚动时，列表内容（即商品卡片）的位移会通过缩放或透明度变化间接影响Tab栏的渲染——虽然布局上不存在父子关系，RN在OpenHarmony上会把多个浮层合并到同一个渲染管线里，某些渲染状态下会触发浮层重排。

排查后我用了一个粗暴的方案：给Tab栏容器加上elevation（在OpenHarmony对应属性是shadow）来提升层级。这个属性本身用于阴影，但在OpenHarmony上它同时会影响渲染分层的优先级，加上之后Tab栏稳定性明显提升。这个发现我记在了项目备注里：鸿蒙的渲染管线和Android Pixel布局逻辑有差异，不该用Android的经验去推断所有显示问题。

5.3 切换Tab后头部状态错乱

现象：在Tab A滚动到头部折叠状态（scrollY=203），切换Tab B，Tab B的列表加载后头部展开，但用户手指刚开始滑动时头部“勉强折叠一下又弹回去”。

排查后发现根因在于：切换Tab时，我直接把旧的scrollY setValue放到了新页面的滚动联动里，但新FlatList挂载初期，它的滚动事件还没开始触发，所以scrollY的值被新页面的默认0覆盖了一次，又立即被缓存的旧值覆盖回来。这一来一回之间，UI短暂抽搐。

修复方式：切换Tab时，先把Animated.Value“冻结”，即将它和当前滚动事件的联动断开（重置为0），等新FlatList完成首次布局后，再通过一次setValue把缓存值灌入。具体代码上没有多复杂，难的是要在整个组件生命周期里维护好一个“当前TabKey”的引用，以及每次切换时的状态机转换。

5.4 问题排查速查表

我把这次项目里遇到的关键问题整理成一个排查表，后续如果你们也做类似组件，可以直接对照：

6. 更容易被忽略的细节与优化空间

6.1 首帧加载体验

第一次进入页面时，如果Banner图片还没加载好，头部区域会出现一块空白的色块，折叠动画也显得很“秃”。我在CollapsibleTab里加了一个图片预加载逻辑：页面初始化时调用Image.prefetch把Banner图拉进缓存，同时给Banner容器一个默认底色。这样首屏即使图片没到，视觉上也有一块渐变的底层填充，不是白屏。

6.2 与搜索栏的联动

如果店铺首页顶部还有搜索栏，折叠逻辑会更复杂一些：搜索栏通常在头部折叠后会缩小为一个圆形按钮。这个交互我一开始没做，业务Review时被提出来。实现上并不难，把搜索栏也作为头部内层的一个Animated.View，宽度和高度的插值范围与Banner一致就行。但要注意的是，搜索栏里如果有输入框，折叠后的圆形状态下需要禁用输入，否则用户会看到一个尺寸很小但还能focus的输入框。

6.3 后续扩展：支持图片视差

折叠头部里嵌入的商品主图，在未来的迭代中可以加入视差效果：主图的高度不变，但通过translateY的动画让图片在折叠过程中缓慢上移，形成“图片跟随滚动”的感觉。这是在电商页面里很常见的高级视觉效果。代码上就是给Banner内部图片单独加一个Y轴的动画插值，范围稍小于Banner高度压缩区间即可。这个扩展点我已经验证过可行性，等有时间会在正式项目里上线。

个人实际使用体验总结

这次项目让我对OpenHarmony上的RN支持有了一个更切实际的判断：把它当成一个“基础设施齐全但是生态偏早期”的平台，抱着“所有功能都要自己验证一遍”的心态去开发，反而比依赖第三方库更稳。

CollapsibleTab这个组件在Android上确实有很多现成方案，但鸿蒙生态里目前没有一个库能像原生平台那样稳定。最开始的几天总是在怀疑是不是自己代码写错了，后来跳出框架、自己动手写核心逻辑之后，对RN的动画管线、事件分发和渲染层级的理解反而更清晰了。

如果你们也在面对同样的问题，我的建议是先做技术预研时不要急着写业务代码，而是花两天时间在真机上反复跑最核心的三个交互：头部折叠跟手、Tab切换稳定、状态恢复不跳。这三个点只要验证通过，组件就成功了一大半。剩下的都是细节，但细节决定了上线后用户真正拿到的体验。