企业官网建设流程全解析

接手这个需求的时候，我以为这就是个“随手加两个 useState”的活：一个管底部导航切到哪个 tab，另一个管首页目标列表里点开了哪个目标。结果页面跑起来之后我才发现，真正需要想清楚的不是“用不用 useState”，而是两个状态变量怎么分工、详情弹层怎么关、切 tab 之后 selectedGoal 要不要保留，以及这套在 React Native 里写好的状态逻辑，到了鸿蒙端会不会因为运行环境不同而变味。这篇文章就围绕 selectedGoal 和 activeTab 这两个状态，把页面状态管理的完整设计思路、代码写法和鸿蒙端实测体验一起梳理清楚。适合正在做 React Native 跨平台、或者正准备把 RN 项目适配到鸿蒙的开发者参考。

1. 从一个小页面看 React Native 的状态设计思路

先说下这个页面长什么样：底部是一条导航栏，三个 tab，分别是首页、分类、我的。首页里有一组目标列表，用户点击某个目标之后，希望以浮层形式展示目标详情，并且支持关闭。整页的状态需求拆开看就是标题里的两个变量：selectedGoal表示“当前选中/查看的目标”，activeTab表示“底部导航当前激活的是哪个 tab”。

页面结构本身不复杂，但状态设计最忌讳的就是“因为简单就随手写”。如果你一开始就把所有状态塞进一个大对象里，比如useState({ activeTab: 'home', selectedGoal: null })，等页面功能多起来之后，每次更新都要小心翼翼地把旧状态展开再合并，漏一个字段就是线上事故。所以我会先明确一个原则：按状态变化的频率和语义拆分，而不是按“它们同属于一个页面”来合并。

1.1 两个状态变量怎么分工

selectedGoal和activeTab虽然都在同一个页面组件里，但它们服务的对象完全不同：

• activeTab决定的是页面内容区：当前该渲染首页、分类还是我的。它是整个页面容器的“一级路由状态”。
• selectedGoal决定的是页面之上的一层浮层：首页列表内部有没有一个目标处于“展开详情”的状态。它是页面内某个区块的“二级交互状态”。

用代码写出来就是这样：

import React, { useState } from 'react'; import { View } from 'react-native'; export default function HomeScreen() { const [activeTab, setActiveTab] = useState('home'); const [selectedGoal, setSelectedGoal] = useState(null); // 渲染底部导航和内容区 }

这两个状态是独立的，变化的场景也不一样：用户连续切换 tab 时只有activeTab在变，selectedGoal不需要跟着动；反过来用户不断打开不同目标详情时，只有selectedGoal在变，内容区不用重新渲染。拆成两个useState之后，React 也能更精准地只重渲染受影响的部分，避免无关组件被带着刷一遍。

有人可能会问：那页面上还有别的状态怎么办，比如列表加载中的loading、下拉刷新的refreshing？我的习惯是继续拆，每个语义独立的状态一个useState。并不是说用一个useState存对象就一定是错的，而是你要在更新、读取、传递时始终记得维护整体结构。状态拆得越细，心智负担越小，这是 React 页面开发里最值得养成的一个习惯。

1.2 页面状态其实只有两组：页面级和区块级

很多初学者会把“页面状态”当成一个大筐，什么状态都往里扔。实际上对于selectedGoal和activeTab这个组合，我们可以把状态分成两个层级来看待。

activeTab是页面级状态，它控制的内容区是整个页面最大的一块区域，切换 tab 本质上是“换了一屏内容”。selectedGoal是区块级状态，它只影响首页列表区块，点击列表项时弹出的详情层属于“当前这一屏内部的交互反馈”。这个层级关系想清楚之后，很多问题就能迎刃而解：比如切 tab 时要不要把selectedGoal清空，本质上就是在问“区块级状态要不要跟随页面级状态一起重置”。

我自己习惯在动笔之前先把状态画成一张简单的思维导图：哪些状态是页面的、哪些是区块的、状态之间的联动关系是什么。想清楚再写代码，后面基本不用返工。这一步准备工作花不了十分钟，但能帮你少加好几个小时的班。

2. selectedGoal：目标详情查看的状态设计与数据流

selectedGoal这个状态从名字上看很清楚，就是“当前选中的目标”，但实际代码里有两个容易踩坑的点：详情用什么载体展示、状态里存整个对象还是只存 id。这两个点直接决定了用户从点击到看到详情之间的体验。

2.1 点击目标之后，详情用什么载体展示

点击列表项之后要展示目标详情，常见做法有三种：RN 自带的Modal组件、页面内条件渲染的浮层、路由跳转到独立页面。三种方案我在不同项目里都用过，给你一张对比表：

对于标题里这种“在首页列表里点目标、看详情”的需求，我更推荐前两种。因为路由跳转会把简单问题复杂化：你要定义一个详情页路由，传参过去，详情页返回时还得考虑怎么通知首页刷新状态。而用Modal或者页面内条件渲染，selectedGoal状态本身就是唯一的“详情数据源”，打开和关闭都只操作一个状态变量。

我的写法是这样：

{selectedGoal && ( <GoalDetail goal={selectedGoal} visible={!!selectedGoal} onClose={() => setSelectedGoal(null)} /> )}

当selectedGoal为null时什么都不渲染，用户点某个目标后把它设成目标对象，详情浮层出现；关闭时设回null，详情浮层销毁。这其实就是“以状态驱动 UI”最典型的表达：UI 只是状态的投影。

2.2 selectedGoal 粒度：存整个对象还是只存 id

这是我在评审代码时经常问别人的一个问题。selectedGoal存整个目标对象还是只存目标 id，直接影响到详情浮层能不能秒开。

如果列表数据已经把目标的完整字段都拉回来了，比如标题、描述、进度、截止时间都在列表接口里，那就直接把整个对象塞进selectedGoal。详情浮层拿到对象后同步渲染，不需要额外请求，体验是最快的。

如果列表接口只返回了概要字段，详情里的内容要靠id再请求一次，那selectedGoal就只存 id，详情组件内部useEffect监听selectedGoal变化去拉详情数据。这种情况下一定要在详情组件里处理加载中状态，否则用户点击之后界面上什么都没发生，很容易误以为点错了没反应。

判断标准很简单：详情展示的字段在列表数据里是否都有？都有就传整个对象；只有摘要字段就传 id 去拉详情。不要一刀切。

2.3 关闭详情时的状态收敛

setSelectedGoal(null)这行代码看起来简单，但它是整个状态设计最容易出 bug 的地方。很多人只想着“关闭详情就是把 selectedGoal 置空”，却忘了问一句：详情组件内部的临时状态要不要一起清理？

我之前踩过一个坑：目标详情里有一个备注输入框，用户在输入框里打到一半，不小心关掉了详情，再点开同一个目标，输入框里居然还残留着没打完的字。原因就是详情组件一直保留在内存里，它内部的状态没有被重置。

后来我改成通过visible的变化来做内部状态重置：

useEffect(() => { if (visible) { setRemarkText(''); setScrollOffset(0); } }, [visible]);

这样每次打开详情都是干净的初始状态。状态收敛不止是把自己定义的 useState 归零，还要考虑子组件内部可能存在的临时状态。这是 Modal 类交互中很容易被忽略的一环。

3. activeTab：底部导航切换背后的状态与组件化

activeTab这个状态本身不复杂，真正值得展开的是它驱动的 UI 结构，以及切换 tab 时跟selectedGoal的联动关系。底部导航看起来是个 “自带功能” 的东西，实际上自己写一遍之后，你对状态驱动的理解会比用第三方库深得多。

3.1 为什么自己写 TabBar 而不是直接上第三方库

React Native 生态里最常用的底部导航方案是 react-navigation 的 bottom-tabs，但它在这个场景里有一个很现实的问题：鸿蒙适配。react-native-harmony是社区维护的 RN 鸿蒙实现，对 react-navigation 的兼容一直不算完美，动画卡顿、手势栈失效、页面切换异常这些情况我都遇到过。

所以在这个项目里，我直接自绘了一个 TabBar。自绘的成本其实很低：一个底部容器、几个可点击按钮、一个activeTab驱动高亮样式。核心逻辑就这三样，依赖少、可控性强，到了鸿蒙端也不用担心导航库的原生模块不兼容。

const tabs = [ { key: 'home', title: '首页', component: HomePage }, { key: 'category', title: '分类', component: CategoryPage }, { key: 'mine', title: '我的', component: MinePage }, ]; {/* 底部导航栏 */} <View style={styles.tabBar}> {tabs.map(tab => ( <Pressable key={tab.key} onPress={() => setActiveTab(tab.key)} style={[styles.tabItem, activeTab === tab.key && styles.tabItemActive]} > <Text style={activeTab === tab.key ? styles.tabTextActive : styles.tabText}> {tab.title} </Text> </Pressable> ))} </View>

3.2 配置化驱动：tab 数组 + activeTab 渲染

自绘 TabBar 之后，内容区的渲染我采用了配置化写法：tab 定义放在数组里，页面组件和标题都挂在这个配置上，内容区根据activeTab从数组里找到对应的组件去渲染。

const currentTab = tabs.find(tab => tab.key === activeTab); const ActivePage = currentTab.component; return ( <View style={styles.container}> <View style={styles.content}> <ActivePage goal={selectedGoal} onSelectGoal={setSelectedGoal} /> </View> <View style={styles.tabBar}> {/* TabBar 渲染逻辑 */} </View> </View> );

这种写法的好处是：以后要新增一个 tab，只需要往tabs数组里加一项，渲染逻辑和样式逻辑完全不用动。配置化思想在这个小页面上可能看不出多大优势，但页面和 tab 数量多起来之后，它能让代码量增长曲线变得非常平缓。

3.3 切换 Tab 时，selectedGoal 状态要不要保留

这个问题没有标准答案，但必须在动手之前想清楚，因为它影响的是用户的操作预期。

如果首页的详情浮层只是首页内部的交互，切换 tab 意味着用户已经离开了首页这个上下文，那我的建议是：切换 tab 时主动把selectedGoal清空。否则用户切到分类、再切回首页，发现详情还挂在屏幕上，这种“被打断的未完成交互”会很奇怪。

实现方式也很简单，在setActiveTab之前做一次联动清理：

const handleTabChange = (key) => { if (key !== 'home') { setSelectedGoal(null); } setActiveTab(key); };

反过来，如果需求明确要求“详情是全局浮层，不管切到哪个 tab 都继续展示”，那selectedGoal就不应该跟随activeTab变化，而是把详情组件放在 TabBar 和内容区之上的顶层位置。两种方案都可以，关键是一开始就定好selectedGoal的归属层级，代码就不容易写成“这里清一下、那里留一下”的混乱状态。

4. 鸿蒙端适配的实际体验与踩坑记录

标题里的“鸿蒙”两个字是这个项目最需要实测的部分。React Native 的纯 JS 逻辑，比如useState，在不同平台上语义没有差异；但是自定义组件、Modal、键盘避让、导航栈这些与原生层相关的部分，在鸿蒙端往往需要单独踩一遍坑。

4.1 RN 项目跑上鸿蒙的基本路径

把 React Native 项目跑到鸿蒙端，目前主流方案是使用react-native-harmony这个开源适配方案。大致路径是：在 RN 工程里通过脚手架添加鸿蒙工程目录，安装鸿蒙适配依赖，然后用 DevEco Studio 打开工程，构建hap包，装进鸿蒙模拟器或真机。

这里面最容易出问题的点是版本匹配：RN 版本、react-native-harmony 版本、DevEco Studio 版本、HarmonyOS SDK 版本，四者要匹配得上才能顺利构建。我的建议是先看 react-native-harmony 官方仓库的版本支持表格，照着支持矩阵选一套稳定的组合，别逞强上最新版。我刚开始就是用了最新的 RN 版本，结果原生模块编译报错，花了一晚上查才发现是版本不兼容。

4.2 启动白屏和页面挂载的关系

热词里那个“react native 启动白屏”，在鸿蒙端出现频率确实不低。但要注意，白屏和useState一点关系都没有。白屏的本质是 JS Bundle 没有加载完成，或者加载失败，页面容器是空白的，你的状态代码根本没有执行。

我当时排查白屏的步骤是：

1. 打开 DevEco Studio 的日志输出，看有没有 Bundle 加载成功的日志。
2. 确认 Metro 是否在运行，如果打的是 release 包，确认 hap 里是否包含了打好的 release Bundle。
3. 在 RN 入口代码里加一个最基础的console.log，如果日志没打出来，说明 JS 压根没跑起来。

排查到最后发现是 Metro 的 dev server 地址配置不对，导致真机连不上。这个和状态管理八竿子打不着，但很多人在白屏时会下意识怀疑“是不是我的 useState 写错了”，结果折腾半天方向全错。遇到白屏先查加载链路，别往业务代码里钻。

4.3 状态更新在鸿蒙端没有差异，差异在原生组件

useState的运行时行为在鸿蒙端和其他平台是完全一致的，因为执行它的还是 JS 引擎，无非是 Hermes 或者 JavaScriptCore。状态更新、重渲染、组件卸载这一整套 React 机制，跟底层是 Android、iOS 还是鸿蒙没有关系。

真正的差异出在原生控件渲染层。我在鸿蒙模拟器上实测时遇到过几个具体问题：

• RN 的Modal组件在visible切换时偶尔出现白色闪块，关掉了动画之后问题消失。
• 自定义 TabBar 里的Pressable点击效果，在鸿蒙端部分版本上反馈偏“肉”，按下去没有 Android 那么跟手。
• 键盘弹出时，详情浮层的位置没有正确避让，会顶掉输入框。

这些问题的共性是：它们都发生在 UI 表现层，而不是状态逻辑层。所以我给团队的建议是：凡是用了系统原生组件的场景，都要在鸿蒙模拟器和真机上单独点一遍，甚至要把“点击目标详情 -> 键盘弹出 -> 切换 tab”这种连续操作完整走一遍，才能保证体验不出问题。

4.4 热重载与状态保留的坑

开发阶段我用 Metro 做热更新，在鸿蒙端偶尔会遇到一种现象：一次快速刷新之后，页面状态被重置了，activeTab回到了 home，selectedGoal回到了 null。一开始我以为是代码有问题，后来才发现是鸿蒙端的热重载机制会重新挂载根组件，导致所有页面状态初始化了一遍。

遇到这种情况，我的建议是先区分“开发态重置”和“生产态 bug”。开发态重置是热重载机制的副作用，不代表你的状态设计有问题；真正要关注的是打出来的 hap 包在生产环境是否出现状态错乱。判断方法很简单：切到 release 模式打一个包，在真机上跑一遍完整流程，如果状态保留和切换都正常，那开发态的重置可以暂时不管，最多在开发时记住“热重载后要手动切回目标 tab”。

5. 什么时候该从 useState 升级到全局状态管理

标题里明确写了 “useState”，但很多读者可能已经见过“useState 和 zustand 怎么选”这类面试题。一个看起来很简单的问题：既然useState就能搞定selectedGoal和activeTab，为什么还要有 Redux、Zustand 这些东西？答案只有一个：当状态的作用域超出了当前页面的边界。

5.1 useState 解决不了的问题：跨页面共享

useState的状态天生归属于某个组件，它只能通过 props 一级一级往下传。所以当你发现“另一个 tab 也要读取当前选中的目标”时，问题就来了：首页里定义的selectedGoal，怎么传给分类页？

最常见的做法是把selectedGoal提升到页面容器组件，然后把状态和更新函数作为 props 传给每个 tab 的子组件。但这会引入一个新问题：prop drilling。中间层组件如果不需要这个状态，也得帮忙传下去，页面一多就变成传 props 传到手软。

我个人的判断标准是：如果同一个状态要被超过两层以上的组件共享，或者要被不同路由页面共享，这时候就该认真考虑全局状态管理了。如果只是标题这个页面的规模，用useState是完全合理的。

5.2 从 useState 平滑迁移到 zustand

如果你在写完useState版本之后，发现业务扩展导致状态确实要跨页面共享了，也不用慌。Zustand 的迁移成本极低，它不像 Redux 那样要写一堆 action、reducer，而是把状态和修改方法写在一个create里：

import { create } from 'zustand'; const useAppStore = create((set) => ({ selectedGoal: null, activeTab: 'home', setSelectedGoal: (goal) => set({ selectedGoal: goal }), setActiveTab: (key) => set({ activeTab: key }), }));

页面里取状态的方式也非常直接：

const selectedGoal = useAppStore((state) => state.selectedGoal); const setSelectedGoal = useAppStore((state) => state.setSelectedGoal);

我在实际项目中做过一次类似的迁移，整个过程大概花了半天。先写useState版本把页面跑通，确认交互没问题后，再把状态逻辑整体搬进 store，页面组件只需要把useState的取值替换成useAppStore的选择器。这种“先本地、后全局”的演进思路，比一上来就引入状态管理库要务实得多。

下表是我在选型时参考的判断框架：

5.3 代码组织：把状态逻辑收进自定义 Hook

即使不升级到 zustand，我建议你也把selectedGoal的逻辑从页面组件里抽出来，封装成自定义 Hook。这样做的价值不是多写了几句代码，而是把状态职责内聚到了一个独立函数里，页面组件只管“渲染”和“调用”，不再关心状态具体怎么变。

拿这个项目举例，我可以把目标详情的状态逻辑抽成这样：

function useGoalDetail() { const [selectedGoal, setSelectedGoal] = useState(null); const openGoal = useCallback((goal) => { setSelectedGoal(goal); }, []); const closeGoal = useCallback(() => { setSelectedGoal(null); }, []); return { selectedGoal, openGoal, closeGoal }; }

页面里调用的时候，状态逻辑就非常干净：

const { selectedGoal, openGoal, closeGoal } = useGoalDetail();

这个自定义 Hook 的好处在我后面迁移 zustand 时体现得很明显：页面组件对外调用的还是openGoal和closeGoal，只要 Hook 内部把useState换成useAppStore的调用，页面层几乎不用改。好的抽象能帮你把重构成本压到最低，这是我从这个小项目中收获最大的经验之一。

这个项目做完，我最大的体会是：useState并不是一个“只有新手才用的简陋工具”，它最大的价值在于把状态的读写范围限定在最小半径里，让页面的心智负担降到最低。踩过几次坑之后，我现在写页面状态之前都会先花十分钟把状态画出来：哪些是页面级的、哪些是区块级的、状态之间会不会相互影响，然后再决定用useState、Context 还是 zustand。如果让我给后来者一个建议，我会说：先别急着上状态管理库，把useState用明白，把状态逻辑收进自定义 Hook，比任何架构都更能让你睡个好觉。最后再分享一个小技巧：凡是setState依赖旧值的地方，尽量用函数式更新，比如setSelectedGoal(prev => ...)，能省掉很多闭包陷阱带来的奇怪 bug。