React Native 在鸿蒙上跑阅读应用这件事，我前后折腾了大半个月。从脚手架搭起来到真机跑通，中间踩的坑比预想的多，但最后把书籍展示、分类筛选、搜索排序这一整套流程理顺之后，感觉整个方案还是相当值得沉淀下来的。这篇文章不聊虚的，直接把我最终落地的实现方案拆开讲，包括状态管理怎么设计、数据筛选在哪一层做、列表渲染怎么优化，以及鸿蒙适配绕不开的那几个坑。想用 React Native 做鸿蒙跨平台应用的朋友，或者正在为阅读类 App 的筛选排序逻辑头疼的开发者，这篇应该能帮你省不少时间。
1. 为什么是 React Native：鸿蒙生态下的跨平台选型逻辑
先交代一下选型背景。我们团队同时要覆盖 Android、iOS 和鸿蒙三个平台，阅读应用的核心功能其实非常清晰：书城展示、分类浏览、搜索、排序、阅读器。这类应用的特点是业务逻辑集中、页面结构相对规整，但列表多、筛选条件多、数据流复杂。选跨平台方案的时候，我重点考虑的是业务代码的复用率和状态管理的地基稳不稳。
1.1 阅读应用的技术诉求与 React Native 的契合点
阅读类 App 跟电商、社交这类重交互的应用不太一样。它最核心的交互是“浏览-筛选-点击-阅读”，本质上是一堆列表页和详情页的组合。这类场景下，React Native 的声明式 UI 和组件化开发方式非常合适，页面状态的切换、筛选条件的叠加、排序规则的变化，本质上都是数据到视图的映射关系。用 React 的心智模型来组织这些逻辑，比命令式的原生开发要顺手得多。
再一个关键点是热更新。阅读应用的内容运营非常频繁，书城首页的运营位、分类的排序、推荐书的权重，这些经常要调整。用 React Native 意味着这些变动可以走脚本更新，不需要每次发原生包，这对一个小团队来说节省的发布成本非常可观。
1.2 两条跨平台路线的对比：React Native 与 ArkTS 原生
鸿蒙生态目前的应用开发路线主要有这么几条：一是直接用 ArkTS 写原生应用，二是用 Flutter 跨端，三是用 React Native。我们当时重点对比了 React Native 和 ArkTS 原生这两条路。
ArkTS 原生的优势是跟系统能力结合最紧密，性能天花板最高，动画、滚动、底层 API 调用都没有中间层损耗。但问题是代码只能在鸿蒙上跑，如果团队还要维护 Android 和 iOS，那就得维护三套代码，人力成本直接翻倍。
React Native 的路线是业务代码一套复用，鸿蒙端通过适配层的桥接机制跑起来。性能上虽然比不上纯原生，但阅读应用不是游戏，也不是重动画应用，列表滚动和页面切换这种体量的需求，React Native 完全扛得住。实测下来，在鸿蒙设备上长列表滚动流畅度虽然比原生略低，但在用户可接受范围内，不会出现明显掉帧。
1.3 能力边界：哪些模块能用 React Native，哪些必须走原生桥接
这里必须说清楚，React Native 在鸿蒙上不是万能药。我们踩了一圈之后，明确了能力边界。业务页面，比如书城、分类、搜索、详情、书架，这些全部用 React Native 写，没有任何问题。导航、网络请求、本地存储、图片加载，也都有对应的适配方案。
但有些模块得走原生桥接。比如阅读器的翻页手势优化，我们想实现类似仿真翻页的效果，用 React Native 的手势系统做会有些吃力，最终这部分是用原生组件封装后嵌入的。再比如某些机型上的状态栏沉浸式适配，也需要原生侧配合。
所以我的结论是：React Native 在鸿蒙上做阅读应用是可行的，但前提是做好能力边界规划，不要试图把一切都塞进跨平台层，合理混编才是务实的做法。
2. 工程搭建与鸿蒙适配：接入 react-native-harmony 的完整链路
工程搭建是整个项目最开始也是坑最多的一步。React Native 跑在鸿蒙上，靠的是开源社区提供的鸿蒙适配层支持，把 JS 引擎、渲染层、原生模块桥接都映射到了鸿蒙系统上。这一步如果版本没对齐，后面根本跑不起来。
2.1 从脚手架到真机运行的完整步骤
我按实操顺序把步骤理一下。首先要有一个标准的 React Native 工程，用官方脚手架初始化，然后在工程目录里接入鸿蒙适配层的原生工程。具体操作是：
先安装适配相关的依赖包，这里要注意版本对应关系。我使用的是社区维护的 react-native-harmony 版本，它要求 React Native 的版本必须匹配到指定大版本，否则编译阶段就会报错。
npm init -y npm install react-native npm install @react-native-community/hooks npm install react-native-harmony然后初始化鸿蒙原生工程。这一步会把 ArkTS 工程和 RN 工程关联起来，生成的鸿蒙工程里会自动配置好兼容层的依赖。需要注意的是初始化命令会在指定目录生成一个完整的鸿蒙工程，如果你之前已经有鸿蒙工程了，会存在合并冲突的风险，我建议直接用生成的目录来维护鸿蒙侧代码。
接下来把 JS 侧的入口文件配置好。在鸿蒙工程中找到对应的配置文件，把 bundle 的加载路径指到 RN 的入口。调试阶段可以走本地开发服务器，发布时改成加载本地 bundle 文件。
最后就是编译和真机调试。鸿蒙工程的编译用 DevEco Studio 来构建，构建完成后安装到真机上，然后启动开发服务器。
npm start真机上需要配置开发服务器的地址，这样才能在开发阶段实现热更新调试。
2.2 版本选型与依赖锁定：最容易翻车的环节
这是整个项目里最容易出问题的地方。React Native、鸿蒙适配层、ArkTS SDK、DevEco Studio 这几个版本必须严格对齐。我在一开始没注意锁版本，结果编译报错报得完全看不懂，后来一个一个排查才发现是版本错位。
我的经验是，选定一套经过验证的版本组合后就锁死，不要轻易升级。当时我固定下来的组合是 React Native 某一个稳定版本，鸿蒙适配层对应这个版本的发布版本，开发工具用当时最新的稳定版。升级必须经过完整回归，否则你就分不清是新功能的问题还是版本兼容的问题。
还有一个细节是建议把依赖版本写死，不要用带尖号的范围版本。
{ "dependencies": { "react": "18.2.0", "react-native": "0.72.5", "react-native-harmony": "0.72.5" } }这样做的原因是 React Native 的生态对版本极其敏感，一个 minor 版本的差异可能导致原生模块的接口对不上。
2.3 真机调试与热更新验证
真机调试有两个验证点。第一是热更新链路是否通，即 JS 代码改动后，鸿蒙应用能否从开发服务器拉到最新 bundle 并刷新。这一条通了，开发效率才有保障。第二是原生模块和 JS 侧的通信是否正常，简单的验证方式是调用一下鸿蒙原生提供的系统信息接口，看能不能正确返回数据。
有一个容易忽略的问题是真机需要跟开发电脑在同一个局域网，而且鸿蒙系统对网络权限有一些默认限制，需要在工程配置里开启网络访问权限，否则开发服务器连不上，页面会一直卡在加载界面。
我建议在工程文档里把这一整套版本组合、初始化步骤、调试配置写成 README，因为在鸿蒙生态还不像 Android 那么成熟的阶段，这些配置信息遗忘之后重新排查的成本非常高。
3. 数据层先行：书籍数据模型与 API 层的设计
阅读应用的核心是数据。我在动手写 UI 之前，先把数据模型和 API 层定了。这个决定在后面写筛选、排序功能的时候帮我省了很多事，因为数据源的结构稳定，上层所有的过滤逻辑都建立在清晰的数据契约之上。
3.1 书籍数据模型的字段设计与扩展性
书籍数据的字段设计，我花了不少时间思考。因为阅读应用后续要做的运营功能非常多，比如推荐位、书单、完本标记、评分体系，这些如果一开始没有预留，后面加字段要改一堆页面。
我的基础模型长这样：
interface Book { id: string; title: string; author: string; coverUrl: string; category: string; subCategory?: string; status: 'serializing' | 'completed'; wordCount: number; rating: number; description: string; tags: string[]; updatedAt: number; isVip: boolean; }这个模型里，category 是主分类，subCategory 是二级分类，tags 是运营标签。这三个字段的组合，基本可以覆盖绝大多数筛选场景。rating 和 wordCount 是排序的核心依据。isVip 和 status 是运营过滤条件。
设计模型时有一点要注意：就算服务端目前还没有返回某些字段，也要在类型定义里预留好，UI 层先按完整结构写好。这样后端字段上线时前端不用改结构，只需要联调即可。
3.2 本地 Mock 与远程 API 的切换策略
开发阶段我没有依赖后端接口，而是自己搭了一套本地 Mock 数据。这套 Mock 不是简单地在代码里写死一个数组，而是模拟了完整的网络请求链路。
我封装了一个请求层，内部根据环境变量切换数据来源：
const isMock = process.env.API_MODE === 'mock'; async function fetchBooks(params: BookQuery): Promise<Book[]> { if (isMock) { return mockFetchBooks(params); } const res = await request.get('/api/books', { params }); return res.data; }mockFetchBooks 内部会模拟网络延迟，并且真的根据传入的查询参数进行过滤和排序。这样做的好处是，前端的所有筛选逻辑在开发阶段就已经被完整地验证过了，联调时只需要确保接口的返回结构一致。
3.3 请求层的封装：比 axios 多了什么
阅读应用的请求层，我在 axios 的基础上做了一层封装，主要是三个考量。
第一是响应结构的统一。我们的后端接口约定的返回结构是统一的，即包裹一层 data 字段，错误码在业务层面单独定义。请求层直接把 data 解出来返回给调用方，页面代码里不用到处处理统一的外层结构。
第二是错误处理的统一。网络错误、业务错误、超时这三类情况，请求层统一转换成业务异常类型，并处理 toast 提示逻辑。这样页面代码中处理请求异常就只需要一个 catch。
第三是取消请求的能力。搜索功能的输入防抖非常依赖取消请求。每次用户输入关键字，如果上一次请求还没返回，应当直接取消，避免响应乱序导致的结果错乱。
class RequestManager { private abortController: AbortController | null = null; async request(config) { this.abortController?.abort(); this.abortController = new AbortController(); return axios({ ...config, signal: this.abortController.signal }); } }数据层稳定之后，上层功能写起来就非常顺了。这也是我认为整个项目中投入产出比最高的一个环节。
4. 状态管理方案：为什么选择 Zustand 而不是 Redux
状态管理是整个阅读应用的中枢。标题里强调的“通过清晰的状态管理实现数据筛选与排序”，核心就是指这块。我在对比了 Redux、MobX、Zustand 之后，选了 Zustand，主要原因跟这个应用的具体场景高度相关。
4.1 需求拆解：这个应用真正需要管理哪些状态
先把状态盘清楚。阅读应用需要共享的状态，不像是购物车那种类型，但也绝不是只有一组列表那么简单。我拆解之后发现是这四类：
第一是书籍列表数据。书城首页、分类页、搜索结果页，虽然各自展示的书籍集合不同，但它们都来自同一份原始数据源，状态管理需要区别维护。
第二是筛选条件。当前选中的分类、标签、状态等，这些条件在页面跳转后依然要保持。比如用户在分类页选了一个分类，点进详情页再返回，筛选条件不能丢。
第三是排序方式。默认排序、人气排序、更新排序、评分排序，这个状态需要全局共享，并且切换排序时数据要重新排列。
第四是搜索关键字和搜索历史。搜索框输入的内容、搜索结果的缓存、最近搜索记录，这些也是全局共享的。
4.2 store 结构设计：books、filter、sort、search 各司其职
基于上面的拆解，我把 store 划分成四个独立的模块，但用一个统一的数据流贯穿。注意这里说的是逻辑上的模块划分， Zustand 可以支持多个 store，也可以合在一个 store 里用切片的方式管理。我用的是单 store 加切片的方式，这样状态流转链路的全局视图更清晰。
核心结构长这样：
interface ReaderState { books: Book[]; filter: FilterState; sort: SortKey; search: SearchState; filteredAndSortedBooks: Book[]; setBooks: (books: Book[]) => void; setFilter: (filter: Partial<FilterState>) => void; setSort: (sort: SortKey) => void; setKeyword: (keyword: string) => void; }filteredAndSortedBooks 是一个计算属性，它不直接存在于数据源中，而是通过 books、filter、sort、search 这四个状态推导出来的。这有个很大的好处：更新的入口是明确的，凡是改 filter 或者 sort，最终列表一定会同步更新，不会出现 UI 层数据不一致的问题。
4.3 selector 机制与订阅粒度的性能考量
Zustand 的 selector 机制是我选它的决定性因素之一。在 React Native 的长列表页面中，如果整个页面因为某个状态变化就全部重新渲染，性能开销会很大。Zustand 允许组件只订阅自己关心的那部分状态。
比如书籍卡片组件，它只关心自己那本书的数据，那就只订阅该数据，不要订阅整个数组。这样每次 setBooks 更新时，只有数据变化的那张卡片重新渲染。我在列表页的实际项目里，把每行的数据选择器精确到书本 ID，效果非常明显，滚动时的卡顿明显减少。
这里有一个要特别注意的点：selector 返回的如果是新对象，会导致组件每次都重新渲染。用 Zustand 时，对需要派生数据的场景，要么用 store 里预计算好的字段，要么用 useShallow 做浅比较，否则会有性能陷阱。
4.4 数据流闭环：从 Actions 到 UI 渲染的完整路径
这个数据流的闭环值得画出来讲清楚，因为它是理解这个方案的关键。
当用户在界面上操作时，比如点击了“完本”筛选按钮，UI 层 dispatch 一个 action，即 setFilter。这个 action 会更新 filter 状态，Zustand 内部触发状态变更通知。与此同时，store 中订阅了相关状态的组件会被通知重新渲染。由于 filteredAndSortedBooks 是一个基于 filter、sort、search、books 四者的派生值，在 filter 变化后，这个派生值也会被重新计算。列表页面订阅的正是 filteredAndSortedBooks，因此页面会展示最新的筛选结果。
这套闭环的好处是单向数据流非常清晰：UI 操作到 action 到 state 到 派生数据 到 UI 渲染。调试时只需要确认 action 是否正确，状态是否正确更新，根因基本就能定位到。
5. 核心功能模块拆解：书籍展示、分类筛选、搜索与排序
数据层和状态管理的地基打好了，接下来就是功能模块的逐层实现。这一章我把五个核心模块逐个拆开，每一步都给出实际的实现逻辑和选择理由。
5.1 书架与书城首页：从数据到书籍卡片的渲染链路
书城首页的定位是运营流量入口，展示逻辑是“运营位 + 推荐列表”。我用的做法是：首页先请求书籍数据列表，把数据放入 store。页面组件通过 selector 订阅 store 中的书籍数组，然后用 FlatList 渲染卡片列表。
书籍卡片的渲染逻辑是这个页面的核心。卡片布局是封面图、书名、作者、分类信息、简介摘要，如果是连载中会加一个连载角标。这里我用 Bloom Filter 的逻辑思路做了一个快速判断：卡片渲染时根据书籍的 status 字段决定是否展示角标，根据 isVip 字段决定是否展示会员标，这些都是纯展示逻辑，不涉及数据过滤。
渲染链路里有一个值得注意的性能点：书籍数据列表的每一项数据都是固定结构的对象，在渲染大量卡片时不要用展开对象的那种写法，保持数据的引用稳定，配合 React.memo 包裹卡片组件，能有效减少无效渲染。
5.2 分类筛选的实现：多维度筛选条件的叠加逻辑
分类筛选最核心的问题是条件的叠加。用户可能同时选了一个主分类、一个二级分类、一个“连载中”状态、一个包含特定 tag 的标签条件。这些条件不是互斥的，而是叠加的。
我实现的过滤逻辑是一个纯函数，输入是所有书籍和当前的筛选条件，输出是符合条件的书籍子集：
function filterBooks(books: Book[], filter: FilterState): Book[] { return books.filter((book) => { if (filter.category && book.category !== filter.category) return false; if (filter.subCategory && book.subCategory !== filter.subCategory) return false; if (filter.status && book.status !== filter.status) return false; if (filter.tag && !book.tags.includes(filter.tag)) return false; if (filter.isVipOnly && !book.isVip) return false; return true; }); }这样写的好处是每个条件之间是独立判断的，增加或减少一个筛选条件都很简单，不会影响其他条件。UI 层就是分类选择面板，面板中点击选项就调用 setFilter 更新对应字段。
分类数据的来源我建议直接由服务端下发，因为分类是一个相对稳定的树形结构，做成配置数据比硬编码在代码里要灵活得多。服务端调整分类层级时，客户端不需要发布新版本。
5.3 搜索排序：关键字防抖与排序算法的选择
搜索这块有两个技术点：防抖和排序。
防抖是为了防止用户每敲一个字就发一次请求。我用的是自定义 hook 来做防抖，在用户停止输入 300ms 后，才真正更新搜索关键字的状态：
function useDebouncedValue(value: string, delay = 300) { const [debouncedValue, setDebouncedValue] = useState(value); useEffect(() => { const timer = setTimeout(() => setDebouncedValue(value), delay); return () => clearTimeout(timer); }, [value, delay]); return debouncedValue; }当 debouncedValue 变化时，就会触发搜索请求，并把结果更新到 store 中。这一步同时配合请求层的取消逻辑，能够确保连续输入关键字不会产生请求乱序。
排序这边，我把排序选项定义成枚举类型：默认排序、更新时间排序、人气排序、评分排序。前端拿到书籍数据后，用数组的 sort 方法来处理。需要注意的点是排序规则最好统一收敛到一个纯函数里，不要散落在各个页面。
function sortBooks(books: Book[], sortKey: SortKey): Book[] { const sorted = [...books]; switch (sortKey) { case 'updatedAt': sorted.sort((a, b) => b.updatedAt - a.updatedAt); break; case 'rating': sorted.sort((a, b) => b.rating - a.rating); break; case 'popularity': sorted.sort((a, b) => b.popularity - a.popularity); break; default: break; } return sorted; }这里我用了 [...books] 拷贝一次，是为了避免 sort 方法在原数组上直接修改。因为原数组是 store 中的状态，直接修改就破坏了不可变更新的原则。
5.4 书籍详情页与阅读器的页面跳转与参数传递
列表页点击书籍卡片后，跳转到详情页。详情页的路由参数是书籍 ID，页面根据 ID 从 store 中取书籍数据。如果 store 里没有这本书，可能是在线搜索出来的结果，那就通过 ID 调用详情接口。
详情页展示的是书籍的完整信息，包括封面、标题、作者、分类、简介、评分、字数和状态。页面上最关键的操作是“开始阅读”按钮，点击后跳转到阅读器页面。
阅读器页面我前面提到过，仿真的翻页效果是用原生组件实现的，通过 React Native 的原生视图桥接能力嵌入。阅读器内部维护了当前页码、字体大小、背景颜色等阅读偏好，这些偏好是本地持久化的，存在本地存储中。阅读进度的记录我用了两个维度：一是当前书籍的阅读进度百分比，二是最后阅读时间。这样下次进入阅读器时可以直接恢复到上次的位置。
参数传递这一块有一个细节需要注意：不要在路由参数中传递大对象，比如整本书的数据。这样会导致路由栈的数据冗余，也无法保证数据的实时性。正确做法是只传 ID，数据统一从 store 或接口获取。我在开发初期犯过把整个 Book 对象塞进路由参数的错误，结果页面刷新之后参数丢失，还得重新做数据恢复逻辑。
6. 性能优化：列表渲染与数据过滤的取舍
阅读应用最吃性能的场景就是长列表。书籍列表动辄几百上千条，筛选条件的每一次变更都会重新走一遍过滤和排序的逻辑，再加鸿蒙端的适配层开销，如果不做优化，用户的体感会非常糟糕。
6.1 FlatList 在鸿蒙上的配置优化
FlatList 是 React Native 渲染长列表的基础组件。在鸿蒙端，它底层映射到鸿蒙的高性能滚动容器，但一些关键的配置参数要主动设置好，否则默认行为会拖累性能。
我的标准配置是：
<FlatList data={filteredAndSortedBooks} keyExtractor={(item) => item.id} renderItem={renderBookCard} initialNumToRender={10} windowSize={7} maxToRenderPerBatch={10} updateCellsBatchingPeriod={50} removeClippedSubviews={true} getItemLayout={getBookItemLayout} performanceMode="high" />initialNumToRender 控制首屏渲染条数，设为 10 意味着用户打开页面后首屏只渲染 10 条，减少白屏时间。windowSize 控制渲染窗口大小，设为 7 表示在当前屏幕可视区域之外再多渲染几屏。maxToRenderPerBatch 和 updateCellsBatchingPeriod 控制渲染的批量频率。
removeClippedSubviews 设为 true，会让滚出屏幕区域的子视图直接移除，这在鸿蒙上对内存占用有明显改善，尤其是当列表数据量非常大的时候。
getItemLayout 是很重要的一项优化，它告诉 FlatList 每一行的精确高度，使得滚动时可以跳过动态测量，直接计算出列表的偏移量。前提是列表每一项高度是固定相同的，比如书城列表卡片都是等高的。我在设计卡片 UI 时特意保证了固定高度，就是为了用上这个优化。
6.2 数据过滤的两种策略：全量过滤与分页加载
筛选排序这块有两种实现策略，它们的取舍很关键。
第一种是全量过滤。客户端一次性拿到服务端下发的所有书籍数据，筛选和排序都在本地做。优点是非常灵活，用户切换筛选条件、切换排序方式时，不需要重新请求网络，即时响应。缺点是数据量大的时候，首次加载耗时长，而且内存占用高。
第二种是服务端过滤加分页。筛选和排序的参数传给服务端，服务端只返回符合条件的一页数据。优点是最初的加载速度快，内存压力小。缺点是用户每一次切换筛选或排序，都要发一次网络请求，有延迟，而且体验上会有一个加载态。
我在书城首页采用的策略是这两者的结合。基础数据分页从服务端加载，当前已加载的数据在本地做筛选和排序。筛选条件变动时，如果当前数据已经满足条件，就直接本地过滤；如果发现数据量不足或条件匹配不到，再向服务端发起分页请求补充数据。
这个结合策略的核心逻辑是：本地优先，远端兜底。用户在筛选面板切换条件时，最理想的情况是秒出结果。只有本地数据不够时，才走网络请求。这样既保证了响应速度，又避免了全量加载的资源浪费。
6.3 图片资源的懒加载与缓存策略
阅读应用视觉上最重的资源是书籍封面图。一个书城页面几十本书，如果首屏同时加载所有封面，带宽和内存都扛不住。
React Native 的 Image 组件本身支持懒加载的策略配置。我的做法是给列表页的封面图统一加上快速加载预览图，即先加载一张很小的模糊占位图，大图在滚动到可视区域附近时才开始真正加载。这里利用了 Image 组件的 resizeMethod 和缓存控制。
鸿蒙端的图片缓存机制和 Android 不完全一样。我的经验是手动维护一个封面图的磁盘缓存，对于已经加载过的封面图，优先从缓存读取，避免重复请求网络。这块在鸿蒙端没有现成的库直接可用，建议封装一个简单的图片组件，内部处理缓存读取、网络加载、失败占位这些逻辑。
还有一点值得注意：封面图的 URL 往往会带一些无法预料的参数，比如有防盗链后缀或者带时间戳。图片组件的缓存 key 需要自己定义，不然同一张图因为 URL 变了每次都要重新下载，这在列表滚动时会让人明显感觉到图片一闪一闪地加载。
7. 踩坑实录：鸿蒙适配过程中最值得记录的几个问题
最后这一章专门讲坑。React Native 跑在鸿蒙上，兼容层毕竟还不是百分百无感，有些问题你可能搜遍全网都找不到现成答案。下面这几个是我实际调试过程中遇到的，分享出来供参考。
7.1 导航库的兼容性问题
React Native 生态里最常用的导航方案在鸿蒙适配层上并不是开箱即用的。我试了社区常用的几种导航库，最稳定的组合是使用兼容层工程内置的导航能力，而不是依赖社区导航库的完整功能。
具体问题是某些导航库依赖的原生侧动画库在鸿蒙上没有被翻译，导致页面切换时直接白屏或者卡死。我最终的方案是让页面跳转全部走兼容层提供的最基础导航能力，复杂的手势返回、转场动画这些全部砍掉，或者用最简单的淡入淡出。这换来了一个极其稳定的导航链路，代价是动画效果没那么花哨。
对于阅读应用来说，页面切换的稳定大于动画的炫酷，这个取舍我建议做在前面。
7.2 字符编码与字体渲染的差异
鸿蒙系统的字体渲染和 Android 有明显的差异。中文标点符号的宽度、数字与英文混排时的间距、特殊符号的显示，在鸿蒙上都有可能出现跟其他平台不一致的表现。
我遇到最典型的问题是阅读器里的章节内容，某些冷门字体在鸿蒙上缺字，导致显示成方框。排查过程是逐条比较阅读器内容的字符编码范围，最后定位到自定义字体文件在该机型的兼容性问题。解决方案是把自定义字体降级为系统字体，并做了一层字体回退机制，即在自定义字体无法显示时自动切换到系统默认字体。
做阅读应用的一定要提前验证字体渲染，特别是正文阅读页。这个页面是用户停留时间最长的页面，任何显示异常都会被放大。我建议在项目初期就专门做一个字体渲染的兼容性测试页面，用各种生僻字、标点、数字组合去跑真机。
7.3 状态栏与底部安全区域的适配
鸿蒙设备很多都有类似 iPhone 的底部横条区域，也有打孔屏、胶囊屏等异形屏。React Native 应用在这类设备上如果不做安全区域适配，底部导航栏会被遮挡，或者顶部内容会顶到状态栏里。
我的做法是封装一个全局的 SafeAreaView 组件，在应用底部和顶部都预留安全区域的 padding。这个组件的安全区域高度来自原生侧的真实测量值，而不是硬编码。不同机型的底部横条高度不一样，硬编码适配出来的效果在不同设备上看起来会忽高忽低。
另外还有一个跟键盘相关的问题：搜索页面输入框聚焦时，鸿蒙的软键盘弹出逻辑和 Android 不完全一样，在部分设备上会出现键盘遮挡输入框的情况。我最终的处理方式是监听键盘高度变化，手动调整输入框的位置。这个逻辑虽然有点土，但在鸿蒙上实测是最可靠的。
7.4 刷新机制与下拉刷新的手势冲突
列表页的下拉刷新和滚动这两个手势，在鸿蒙上的联动有一些微妙的问题。如果你同时启用了 FlatList 的 RefreshControl 和页面级的 ScrollView 滚动，当列表在顶部继续下拉时，手势判定容易产生冲突，表现为页面轻微抖动或者刷新动画不触发。
调试之后我发现原因是 Fusion 层的手势响应优先级和原生不完全一致。我的解决思路是不要同时承载无限滚动和下拉刷新两个手势方向。具体做法是把无限滚动加载更多和下拉刷新分成两个独立手势区域，底部加载更多交给 FlatList 的 onEndReached 机制，顶部下拉刷新单独处理。
这个坑比较隐蔽，因为模拟器上不明显，换到真机上之后才能复现。遇到类似诡异的手势问题时，可以先猜是手势优先级冲突，再逐层排查。
用 React Native 做鸿蒙跨平台阅读应用这个方案，说到底是一次“在限制条件下做最优选择”的工程实践。业务代码一套复用、状态管理走清晰的数据流、筛选排序收敛在数据层，这些设计带来的收益在整个开发流程中会持续放大。而鸿蒙适配层的那些坑，只要提前做好能力边界规划、严格锁版本、多跑真机，大部分都是可以通过规范流程规避的。
我在整个项目里最深的体会是：跨平台方案核心不在于你选择了哪个框架，而在于你愿不愿意在数据模型和状态管理上多下功夫。数据层和状态层稳了，上层功能和平台适配的复杂度都会成倍下降。如果后续有机会，我打算把阅读器的原生能力封装做得更通用一些，把这个跨平台方案进一步打磨成一套可复用的阅读应用脚手架。
最后分享一个小技巧：如果你的团队也要从零搭鸿蒙端的 React Native 工程，第一周宁可什么都别写，先把“脚手架 + 导航 + 数据层 + 真机调试”这条链路完整跑通，再开始写任何业务页面。这条链路不通，后面写再多代码都返工。链路通了，后面每个功能模块都只是在这个稳定的地基上砌砖而已。
