企业官网建设流程全解析

最近手头有个跨平台阅读应用项目，技术栈选了 React Native，后期把鸿蒙端也跑通了。项目核心功能不算多，就是书籍展示、分类筛选、搜索排序，但这些模块一旦组合起来，状态管理如果设计得不好，很容易变成一团乱麻。我司这套方案从书架卡片渲染到筛选排序联动，再到鸿蒙端的兼容适配，整体跑下来比较顺畅，把过程中的设计思路和踩坑经验整理出来，希望对正在做RN跨端应用的朋友有帮助。

1. 项目定位与技术选型

1.1 为什么是 React Native + 鸿蒙

先说结论：我们团队本身已经有一定 React 技术积累，选 React Native 可以让前端同学快速上手，同时把 iOS、Android 和鸿蒙三端的业务代码复用率拉到 90% 以上。刚开始团队内部也有人提议用 Flutter，但考虑到我们现有组件库和一些原生能力需要渐进式接入，RN 的桥接机制更符合现状。

鸿蒙端的接入并不是从零开始，而是基于社区提供的适配层，将原有 RN 代码映射到鸿蒙原生组件上。实际使用中，大部分 JS 层代码无需修改，主要改的是原生工程配置和少量设备兼容样式。这套方案的价值在于：业务迭代速度可以跟上，而不是单独维护一套鸿蒙原生应用。

1.2 技术栈与基础架构

整体技术栈如下：

• React Native 0.7x 版本，使用新架构（Fabric + TurboModule），新架构在启动性能和触发动效上改善明显，后面在鸿蒙端也更容易做桥接优化。
• 状态管理用 Zustand。选它是因为轻量、API 简单，没有 Redux 那样繁琐的模板代码。项目里需要管理的状态集中在书籍列表、筛选条件、搜索词、排序方式，Zustand 的 selector 机制能很好控制渲染范围。
• 网络请求使用 axios，配合请求拦截器统一加鉴权和错误处理。
• 数据缓存用 AsyncStorage，存放历史搜索、书架记录、用户偏好。
• 列表渲染用 FlatList，图片加载用 react-native-fast-image，避免自带 Image 在长列表中的性能瓶颈。

鸿蒙端的环境搭建需要注意：适配层版本必须和 RN 主版本对应，否则会出现编译期错误或者运行闪退。我们在搭建时先对照官方兼容表确认版本，再初始化原生工程，跑通一个空标签页后才逐步接入业务代码。

1.3 数据模型设计

在写状态管理之前，先定义书籍模型和相关枚举。一个书籍对象包含以下核心字段：

{ id: string, title: string, author: string, category: string, // 分类标识 coverUrl: string, rating: number, // 评分 0-5 popularity: number, // 热度，用于排序 publishTime: number, // 时间戳，用于"最新"排序 description: string, // 简介，用于搜索匹配 }

分类筛选需要一份分类列表，用常量定义：

const CATEGORIES = [ { key: 'all', label: '全部' }, { key: 'novel', label: '小说' }, { key: 'history', label: '历史' }, { key: 'tech', label: '科技' }, { key: 'psychology', label: '心理' }, ];

排序方式定义：

const SORT_OPTIONS = [ { key: 'latest', label: '最新' }, { key: 'rating', label: '评分最高' }, { key: 'popularity', label: '最热' }, ];

这里把数据模型单独建了一个types.js文件，所有页面引用同一个类型定义，避免出现字段命名不一致的隐性问题。后期如果有服务端字段变更，也只改一处。

2. 书籍展示模块：从书架到详情

2.1 页面组件拆解

阅读应用的展示层分为四个页面：书架页、分类页、搜索页、详情页。为了快速搭建，书架页和分类页共用同一个书籍卡片列表组件，区别只是顶部标题和请求参数。

书架页负责展示"我的书架"，数据来自本地存储和用户操作，不需要走服务端接口。这一步的状态管理主要是同步书架增删操作：加书、移除、更新阅读进度。

分类页则从服务端拉取全量书籍，初期数据量大概在几千条，放在前端做筛选完全够用。如果未来数据量增长，再切换成请求参数让服务端处理。

详情页接收书籍 id，在 store 中查找对应书目，或者发起一次详情请求。考虑到阅读应用的用户会频繁切页，详情页数据尽量缓存到 store 中，避免重复请求。

2.2 列表渲染的细节

书籍卡片组件长这样：

const BookCard = ({ book, onPress }) => { return ( <Card onPress={onPress} style={styles.card}> <FastImage source={{ uri: book.coverUrl }} style={styles.cover} /> <View style={styles.info}> <Text numberOfLines={1}>{book.title}</Text> <Text numberOfLines={1}>{book.author}</Text> <Text>{book.rating.toFixed(1)} 分</Text> </View> </Card> ); };

FlatList 渲染时，几个关键参数必须设好。windowSize控制在 5 左右，maxToRenderPerBatch设为 10，getItemLayout能计算就计算，因为卡片高度固定为 180，直接返回偏移量，滚动条位置估算会更准，长列表首屏渲染速度有明显提升。

图片加载使用 FastImage，但要注意鸿蒙端对具体图片格式的支持。我们在测试时发现某些 WebP 动图在鸿蒙上显示异常，后来统一转为 JPG 或 PNG 格式。网络图片的域名也需要在鸿蒙配置文件里加入白名单，否则图片会被拦截。

2.3 状态管理在展示层的作用

展示层需要的状态有：书籍列表数据、加载状态、错误信息。用 Zustand 定义一个 store：

const useBookStore = create((set) => ({ books: [], loading: false, error: null, fetchBooks: async () => { set({ loading: true, error: null }); try { const res = await api.get('/books'); set({ books: res.data, loading: false }); } catch (e) { set({ error: e.message, loading: false }); } }, }));

页面组件通过 selector 获取数据：

const books = useBookStore((s) => s.books); const loading = useBookStore((s) => s.loading);

这样每个组件只订阅自己关心的部分。书架页不需要的字段不会引起重渲染，整个应用状态更新时的范围很可控。

3. 状态管理核心：筛选、搜索、排序如何优雅地搅在一起

3.1 需求梳理

阅读应用的筛选搜索排序集中出现在分类页和搜索结果页。用户可能同时进行三个操作：

• 选择一个分类（比如"科技"）
• 输入搜索词（比如"深度学习"）
• 选择排序方式（比如"评分最高"）

最终展示的结果是：科技分类中，标题/作者/简介包含"深度学习"的书籍，并且评分高的排前面。这三个条件不是互斥的，而是叠加的，所以状态设计必须把原始数据和筛选条件分开，通过派生数据来计算结果，而不是每次操作都直接修改书籍列表。

3.2 状态结构设计

我们把筛选条件单独管理在 store 中：

const useFilterStore = create((set) => ({ category: 'all', // 当前选中分类 searchQuery: '', // 搜索关键词 sortBy: 'latest', // 当前排序方式 setCategory: (key) => set({ category: key }), setSearchQuery: (query) => set({ searchQuery: query }), setSortBy: (key) => set({ sortBy: key }), reset: () => set({ category: 'all', searchQuery: '', sortBy: 'latest' }), }));

为什么不用把计算结果放 store？因为计算结果完全依赖于books和筛选条件，属于派生状态。如果每次都把筛选结果存起来，同步逻辑会冗余，而且容易出现两个 store 中的数据不一致。更好的做法是保留单一数据源，在组件层用useMemo计算。

3.3 筛选排序的具体实现

在分类页组件中，这样计算最终列表：

const books = useBookStore((s) => s.books); const category = useFilterStore((s) => s.category); const searchQuery = useFilterStore((s) => s.searchQuery); const sortBy = useFilterStore((s) => s.sortBy); const filteredBooks = useMemo(() => { let result = books; // 分类过滤 if (category !== 'all') { result = result.filter((book) => book.category === category); } // 搜索匹配 if (searchQuery.trim()) { const q = searchQuery.trim().toLowerCase(); result = result.filter((book) => { return ( book.title.toLowerCase().includes(q) || book.author.toLowerCase().includes(q) || book.description.toLowerCase().includes(q) ); }); } // 排序 switch (sortBy) { case 'latest': result = [...result].sort((a, b) => b.publishTime - a.publishTime); break; case 'rating': result = [...result].sort((a, b) => b.rating - a.rating); break; case 'popularity': result = [...result].sort((a, b) => b.popularity - a.popularity); break; default: break; } return result; }, [books, category, searchQuery, sortBy]);

这段代码是整个模块的核心。有几个要点：

• 排序前必须[...result]拷贝数组，否则会改变原始books数组的顺序。这是新手最容易犯的错。
• 搜索匹配时统一转小写，避免大小写影响搜索结果。
• 搜索条件分别匹配标题、作者、简介，基本覆盖了用户找书的路径。
• useMemo的依赖数组写全，否则筛选结果不会随条件刷新。

3.4 用户交互的细节

搜索输入框是一个高频操作。搜索时每次按键盘都会改变searchQuery，如果实时计算，数据量大时会有明显卡顿。加一层防抖处理：

const [input, setInput] = useState(''); const setSearchQuery = useFilterStore((s) => s.setSearchQuery); useEffect(() => { const timer = setTimeout(() => { setSearchQuery(input); }, 300); return () => clearTimeout(timer); }, [input, setSearchQuery]);

这样输入过程中 store 不会频繁更新，只有停止输入 300ms 后才触发筛选计算。实际体验下来，列表刷新不会跟手冲突，也不会丢失用户输入的连贯感。

分类切换时，因为筛选条件变了，跳转回第一页比较自然，否则用户停留在列表靠下位置，容易误以为结果没刷新。需要在切换回调里调用列表的 scrollToOffset：

const listRef = useRef(null); const handleCategoryChange = (key) => { setCategory(key); listRef.current?.scrollToOffset({ offset: 0, animated: false }); };

排序按钮通常做成一个弹出底部菜单，选完立即生效。这里不需要额外防抖，因为是一次性点击，但要注意排序后数组是重新生成的，FlatList 的extraData需要绑定排序结果，否则可能不更新。

4. 实操记录：鸿蒙端的适配与关键问题排查

4.1 鸿蒙端适配踩坑

跨平台方案最怕的就是系统差异。这套 RN 代码在 iOS 和 Android 上表现一致，但在鸿蒙端还是遇到几个问题，记录下来给大家参考。

首先是安全区域。鸿蒙部分设备有底部手势条，页面底部内容会被遮挡。处理方式是在根组件中根据设备环境动态添加 padding：

import { useSafeAreaInsets } from 'react-native-safe-area-context'; const insets = useSafeAreaInsets(); <View style={{ paddingBottom: insets.bottom || 16 }}>...</View>

其次是字体缩放。鸿蒙的无障碍字体调节对部分 RN 组件生效，导致文本溢出卡片。我们给关键文本设置maxFontSizeMultiplier，限制字体缩放倍数：

<Text maxFontSizeMultiplier={1.2} numberOfLines={2}>{book.title}</Text>

另一个问题是 FlatList 在鸿蒙端滚动时偶尔出现空白块，尤其在快速滚动时。排查后确认是removeClippedSubviews在鸿蒙适配层表现不稳定。这个属性在 iOS 上表示移除视口外的视图，但在鸿蒙端适配不完整，关掉后问题消失。由于列表数据量不算大，关掉后内存占用增加可忽略。

4.2 常见问题速查表

我把实际操作中遇到的问题整理成表格，方便快速对照：

以上问题大多属于跨端适配的边界情况。遇到类似情况，建议先检查是不是组件属性在不同端表现不一致，再考虑是否由系统版本差异引起。

4.3 性能优化记录

阅读应用对列表滚动的性能要求比较高。我在优化过程中做了三件事：

第一，减少重渲染。筛选条件和列表数据分别存储，列表组件只订阅books和筛选条件，卡片组件用memo包裹。这样切换分类时，未变化的卡片组件不会重新渲染。

第二，图片缓存策略。FastImage 设置了source后会自动缓存，但需要给图片 URL 增加版本号。封面图片更新后 URL 不变会导致显示旧图，我在请求封面时带上?v=时间戳，强制刷新。

第三，发布前检查 re-render 次数。在开发模式下打开 React Native 的调试工具，录制页面交互，观察高亮区域。如果整个列表都高亮，说明 selector 没写好，某个组件订阅了不相关的状态。我们实际排查过一次：某个公共 Header 组件订阅了loading，导致加载时整个页面范围重绘，改成只订阅error后高亮区域明显缩小。

5. 几个值得分享的实践心得

状态管理这块，我最大的感受是：先把数据流画清楚，再动代码。这个项目在一开始就区分了服务端状态（书籍列表）和 UI 状态（筛选条件、排序方式），后续添加功能时基本不需要改动 store 结构。

另外，筛选条件最好能够持久化。用户在分类页选好条件后，切换到书架页再回来，条件不应该丢失。我们因为 store 是全局的，所以天然满足。如果想要支持深链分享，可以把筛选条件同步到 URL 或路由参数中，这是后续可以继续扩展的方向。

还有一点建议：不要为了状态管理而状态管理。像"当前打开的是哪个 Tab"这种短暂 UI 状态，用组件 state 就行，不需要塞进全局 store。全局 store 保存的应该是跨页面共享、需要在应用生命周期内保持的数据。

最后回到项目本身，React Native 跨平台阅读应用的方案在鸿蒙端跑通后，团队已经把这套筛选排序模式复用到其他内容类应用上了。从实际交付效果看，只要状态管理边界清晰，跨端开发的效率优势非常明显。如果你正在做类似的内容展示类应用，可以按这套思路先搭一个最小可用版本，再逐步迭代。