企业官网建设流程全解析

刷 B 站的时候，刷到过一个切片标题叫“【Derapchu/熟切】react to wifies新arg破防5分钟实录（雾”，第一反应这是某个视频区 Up 主对 Wi-Fi 相关新剧情做的反应合集，评论区大概还会飘过一片“哈哈哈哈”和“泪目”。

但如果把“react to wifies”换个断句，重新读一遍，你会发现这其实是一个特别适合前端开发者拿来当梗的标题：React to Wi-Fi。

换句话说，这不是视频切片，而是很多 React 开发者的日常——项目跑得好好的，Wi-Fi 突然抽风；依赖装好了，启动却白屏；React 18 都更新迭代这么多轮了，还有人因为状态没立即更新而破防。这篇文章不聊切片，聊真正的 React：从基础概念到 React 18 的批处理机制，从路由选型到 React Native/Taro 的多端开发，从 GitHub 建仓到 AI Agent 里的 ReAct 模式，一次梳理清楚 React 学习与实战中最容易让人破防的那些点。

先说一个明确判断：React 的根本价值不是“函数式组件 + Hooks”这些表面 API，而是一整套围绕“状态与视图同步”的心智模型。你掌握了这套模型，React 18、React Native、Taro、甚至 AI Agent 里的 ReAct，都会变得顺理成章；反之，只看 API 不建模型，面试题背得再多，遇到线上问题还是会破防。

1. 这篇文章真正要解决的问题

我见过很多初学者学 React 的方式是：先看一遍文档，再跟着视频敲一个 Todo List，然后开始刷面试题。表面上看是“React 入坑成功”，但真正进入项目后，第一个需求就把人打懵了。

比如下面这些场景：

1. 点击按钮后连续调用两次 setState，结果页面只渲染了一次，于是怀疑 React “吞了更新”。
2. 用 React Router 写了一个二级页面，部署到服务器后刷新直接 404，完全不知道是 Nginx 配置问题还是路由问题。
3. 听说 React Native 能一套代码跑两端，结果 iOS 还好，Android 启动直接白屏。
4. 用 Taro 写小程序，以为自己会 React 就等于会 Taro，结果被编译器的各种限制折磨到怀疑人生。
5. 去面试造火箭，被问到“Fiber 是什么”“React 18 批处理做了什么优化”，嘴上能说几句，但心里其实不确定。

这些问题背后不是某个 API 没记住，而是对 React 的核心运行机制缺少结构化理解。所以这篇文章要解决的不只是“某个具体 bug 怎么修”，而是帮你建立一张 React 技术地图：核心概念、版本机制、生态选型、工程实践、常见排错路径，以及面试中真正重要的问题。

如果你已经写了一阵子 React，但总觉得知识是碎片化的，这篇文章很适合你；如果你正准备从 Vue 转 React，或者在 React Native、Taro、可视化项目里踩了坑，这篇文章也会给你一个相对完整的参照体系。

2. React 到底是什么，为什么它让人又爱又恨

2.1 官方定义与核心概念

React 是一个用于构建用户界面的 JavaScript 库。注意，它是“库”而不是完整的“框架”，这意味着 React 本身只关心 UI 层面的“组件渲染”和“状态更新”，路由、状态管理、请求库、构建工具这些都需要在社区生态里自己选型。

入门 React 必须理解以下几个概念：

2.2 为什么 React 会让人“破防”

React 的“反直觉”之处在于，它强制你接受一种全新的数据流思维方式：视图是状态的函数。你不再像 jQuery 时代那样命令式地操作 DOM，而是声明式地描述“当状态是什么样时，页面应该是什么样”。

听起来很简单，但实际开发中经常出现以下三类破防瞬间：

1. 状态更新不同步。setState 之后立刻读取 state，拿到的还是旧值。这不是 React 的 bug，而是“更新是异步的 / 批处理的”这个核心机制没学透。
2. 组件渲染次数不受控。没有正确设置 useEffect 依赖数组，导致请求被无限发送，页面崩溃，后台请求列表刷屏。
3. 调试困难。React 会通过组件树传递数据，项目一大，props 层层传递很难维护，于是出现“prop drilling”（属性透传）的问题，最后只能引入状态管理库。

这些破防点恰恰是 React 的设计取舍。理解了它的设计动机，你就从“会写 React”进化到了“理解 React”。

2.3 React 与 Vue 的核心差异

很多人会在 React 和 Vue 之间纠结。把两者的差异放在一张表格里看会更清楚：

没有绝对的好坏。如果你的项目需要严格的组件边界和跨端能力，React 更合适；如果你需要快速开发中后台页面，Vue 更轻快。无论如何，“React 和 Vue 路由差异”是面试里常被追问的点，下面我单独展开。

3. React 18 更新批处理机制：最容易被误解的“破防点”

3.1 批处理是什么

批处理（Batching）是 React 内部的一种性能优化策略。它的核心思想是：React 会在一次事件循环中，把多次状态更新合并成一次重新渲染。

举个例子，一个按钮点击事件里写了三次 setCount：

// 文件路径：src/components/Counter.jsx import { useState } from "react"; export default function Counter() { const [count, setCount] = useState(0); const handleClick = () => { // 三次更新，React 会合并成一次渲染 setCount((c) => c + 1); setCount((c) => c + 1); setCount((c) => c + 1); }; return ( <button onClick={handleClick}> 点击了 {count} 次 </button> ); }

假如没有批处理，浏览器需要在短时间内同步更新三次 DOM，性能压力会成倍增加。有了批处理，事件处理函数里的三次 setCount 最终只触发一次渲染，最终 count 从 0 变成 3。

3.2 React 18 之前和之后的差异

React 18 之前，批处理只在 React 事件系统内部生效。而在 Promise、setTimeout、原生事件、异步请求回调这些场景中，React 没办法自动批处理，导致来回触发多次渲染。

React 18 引入了“自动批处理”（Automatic Batching），把批处理的范围扩大到几乎所有场景。如果你还在用 React 17 或更早版本，下面这段代码里的三次更新可能会触发三次渲染：

// React 17 及以前的行为 import { useState } from "react"; export default function App() { const [a, setA] = useState(0); const [b, setB] = useState(0); const fetchData = () => { Promise.resolve().then(() => { setA((v) => v + 1); setB((v) => v + 1); // React 17：这里可能触发两次渲染 // React 18：自动批处理，只会触发一次渲染 }); }; return ( <div> <span>a={a}</span> <span>b={b}</span> <button onClick={fetchData}>请求模拟</button> </div> ); }

真实项目里最常见的场景是：接口请求返回后需要同时更新多个 state，比如设置 loading 为 false、写入列表数据、修改分页信息。React 18 的自动批处理能避免这些更新产生多次重复渲染，对性能是实打实的提升。

3.3 批处理机制的三个常见误区

误区一：setState 后立刻读取新值。批处理意味着 setState 不是同步更新的，React 会先记住这次更新，等当前事件处理完后统一执行。如果需要在更新后做后续操作，应该利用 useEffect 监听该状态变化，或者在 setState 的回调函数里处理（注意：类组件时代这种方式更常见，函数组件中推荐用 useEffect 或计算派生状态）。

误区二：并发特性就是多线程。React 18 的并发特性不是“同时执行多个 JavaScript 任务”，而是“高优先级任务可以打断低优先级任务的渲染过程”。它是在 JS 单线程基础上实现的可中断渲染机制。

误区三：批处理会让所有更新都变慢。批处理是为了减少不必要的渲染负担，不是让每次更新都延迟。React 内部会按优先级调度更新，紧急交互（比如输入）仍然优先响应。

3.4 如何验证自动批处理

最简单的验证方式是打开 React DevTools 的 Profiler 面板，记录一次异步更新操作，看组件渲染次数。如果你把上面 Counter 示例的日志打印在组件函数中，React 18 下点击一次按钮，组件函数只执行一次；React 17 下在 Promise 回调中多次 setState，则可能执行多次。

这里要注意，不要只看“打印了几次”就下结论，因为 StrictMode 在开发模式下会让组件函数额外执行一次，这属于 React 故意做的副作用检测，不代表真实渲染次数。

4. React 与 Vue 路由差异，以及不同业务场景下如何选择

4.1 前端路由的本质

路由是用来解决“不同 URL 对应不同页面状态”的机制。前端路由有两种主流模式：

1. Hash 模式：URL 中带#，比如http://localhost:3000/#/home，兼容性好，但 URL 不美观。
2. History 模式：基于 History API，比如http://localhost:3000/home，URL 干净，但服务端需要做回退配置，否则刷新会 404。

4.2 React Router 与 Vue Router 的差异

React 生态最常用的是 React Router，Vue 生态最常用的是 Vue Router。两者的核心差异不在功能，而在使用模型上。React Router 把路由组件化，你可以在任意组件里通过 Hooks（如 useParams、useNavigate）操作路由；Vue Router 则把路由配置作为“数据源”，配合路由守卫实现更集中的控制。

React Router 6 的配置式写法：

// 文件路径：src/router/index.jsx import { createBrowserRouter, RouterProvider } from "react-router-dom"; import Home from "../pages/Home"; import About from "../pages/About"; const router = createBrowserRouter([ { path: "/", element: <Home />, }, { path: "/about", element: <About />, }, ]); export default function AppRouter() { return <RouterProvider router={router} />; }

Vue Router 4 的配置式写法：

// 文件路径：src/router/index.js import { createRouter, createWebHistory } from "vue-router"; import Home from "../views/Home.vue"; const router = createRouter({ history: createWebHistory(), routes: [ { path: "/", name: "home", component: Home, }, ], }); export default router;

对比关键差异如下：

4.3 不同业务场景怎么选

如果你的项目是大型后台管理系统，需要细粒度的权限控制，Vue Router 的全局守卫写起来比较顺手。如果你的项目是重组件交互的前端应用，类似工作流编辑器、实时数据看板，React Router 的组件式写法会和 React 的心智模型更统一。

还有一个隐藏点：如果你的项目同时需要 Web 端和 App 端，并且都基于 React（React + React Native），那选择 React Router 可以让路由思维在两端保持延续；如果只做中小型 H5 或后台，Vue Router 的配置化更省心。

很多新人会在 History 模式部署后刷新页面出现 404，以为是路由写错了。实际上这是服务端配置问题。以 Nginx 为例，让所有非静态资源请求都回退到 index.html：

# 文件路径：nginx/conf.d/react-app.conf server { listen 80; server_name example.com; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } }

生产环境改配置前一定要先备份原文件，并在测试环境验证，避免线上直接“破防”。

5. React Native 与 Taro：多端开发的机遇和那些“白屏”问题

5.1 React Native 是什么

React Native 让开发者用 React 的组件模型编写原生移动应用。它在 JavaScript 层与原生层之间架起一座桥，把组件映射为真实原生控件。问题是，桥的通信开销、原生环境差异、第三方库的兼容性，都会造成“项目能跑，但总会在意想不到的地方崩”。

5.2 React Native 启动白屏的排查思路

React Native 启动白屏是高频问题。白屏不等于程序没运行，很多时候是 JS Bundle 加载失败或容器渲染失败。建议按以下顺序排查：

注意：涉及原生环境和打包配置时，要保证有测试设备或测试包验证，不能直接在生产环境操作。最小化权限、先小范围灰度，是工程上更稳妥的做法。

5.3 Taro：一套代码写多端

Taro 是一个编译型多端框架，它允许你用 React（或 Vue）语法写代码，然后编译成微信小程序、H5、React Native 等目标端。很多写 React 的人以为“会 React 就会 Taro”，实际踩坑之后才发现，小程序的运行环境和 Web 差的不是一点半点。

Taro 项目初始化命令如下：

# 使用 Taro 创建项目 npx @tarojs/cli init my-taro-app # 进入项目并安装依赖 cd my-taro-app npm install # 运行到微信小程序端 npm run dev:weapp

使用 Taro 开发必须牢记的一些点：

1. 小程序端对动态创建 DOM 的能力有限制，不能完全依赖 Web 端的 JSX 写法。
2. 不要在 JSX 里直接使用浏览器专用 API，比如 window、document，跨端代码要写条件判断或使用 Taro 提供的环境判断 API。
3. 循环的 key 属性必须设置，否则小程序端渲染会出现列表更新错乱。
4. 组件样式隔离和 Web 端不同，全局样式、页面样式、组件样式的关系需要仔细梳理。
5. 部分第三方 React 组件库直接搬到 Taro 会失效，因为它们依赖了 DOM API。

如果你面试时被问到“React 和 Taro 开发必须牢记的技能”，上面五条就是最实际的回答方向。

5.4 多端开发的工程建议

无论用 React Native 还是 Taro，都建议把业务代码与平台相关代码分离。通用的状态管理、请求逻辑、组件逻辑放共享层，差异化的 UI 交互放到各端专属层。这样即使某个端的原生问题导致白屏，也不会拖垮整个业务。

6. 从零搭建一个 React 项目：GitHub 建仓、计数器与仪表盘可视化

6.1 项目创建与 GitHub 仓库

当前创建 React 项目最简单的方式是 Vite，而不是老牌的 Create React App。Vite 启动速度快，配置直观，React 官方文档也推荐它作为新的前端构建工具。

# 创建 React + TypeScript 项目 npm create vite@latest react-demo -- --template react-ts # 进入目录并安装依赖 cd react-demo npm install # 启动开发服务器 npm run dev

如果你想把项目推到 GitHub，常规做法是先在 GitHub 上创建一个空白仓库，然后关联本地仓库。注意，不要直接在 GitHub 上勾选“Add a README file”，否则本地 push 时容易出现冲突。

# 初始化本地仓库 git init # 添加所有文件并提交 git add . git commit -m "feat: 初始化 React 项目" # 关联远程仓库，origin 地址换成你自己的仓库地址 git remote add origin git@github.com:yourname/react-demo.git # 推送代码 git push -u origin main

如果你的远程仓库已经存在，拉取合并需要谨慎。建议先 pull 再 push，或者确保没有重复文件。

6.2 React 加减法计算器：最小的完整示例

计算器项目非常适合用来理解 React 的组件与状态模型。下面是一个用 React + TypeScript 写的加减法计算器，核心逻辑非常清晰。

// 文件路径：src/components/Calculator.tsx import { useState } from "react"; export default function Calculator() { const [num, setNum] = useState(0); const add = () => { setNum((prev) => prev + 1); }; const subtract = () => { setNum((prev) => prev - 1); }; return ( <div> <h2>当前数值：{num}</h2> <button onClick={add}>加 1</button> <button onClick={subtract}>减 1</button> </div> ); }

这里必须强调一点：setNum 使用了函数式更新写法setNum((prev) => prev + 1)。函数式更新能确保在连续多次更新时拿到最新的 state 值。如果用setNum(num + 1)连点三次，有可能因为闭包捕获了旧值而只加一次。

把 Calculator 组件挂到 App 中即可运行：

// 文件路径：src/App.tsx import Calculator from "./components/Calculator"; export default function App() { return ( <main> <h1>React 计算器示例</h1> <Calculator /> </main> ); }

6.3 仪表盘项目：可视化不是先写图表，而是先整理数据流

很多 React 初学者想做“仪表盘”，一上来就百度哪个图表库好用，然后照着示例贴一堆图表组件，最后发现页面卡顿、数据一多就整个崩。

仪表盘项目的正确打开方式应该是：

1. 先定义数据模型。比如销售趋势图需要“日期 + 销售额 + 订单量”这样的数据结构。
2. 再设计状态管理方式。简单的仪表盘用 useState + useEffect 就够了，复杂跨组件共享数据再引入 Zustand 或 Redux Toolkit。
3. 最后才是渲染图表。选择 ECharts 还是 Recharts，取决于你的定制需求。ECharts 配置灵活，包体积大；Recharts 基于 React 组件化，适合快速开发。

一个简单的仪表盘数据获取结构：

// 文件路径：src/hooks/useDashboardData.ts import { useEffect, useState } from "react"; export interface DashboardData { date: string; amount: number; } export function useDashboardData() { const [data, setData] = useState<DashboardData[]>([]); const [loading, setLoading] = useState(false); const [error, setError] = useState<Error | null>(null); useEffect(() => { let ignore = false; async function fetchData() { setLoading(true); try { const response = await fetch("/api/dashboard"); const result = (await response.json()) as DashboardData[]; if (!ignore) { setData(result); } } catch (err) { if (!ignore) { setError(err as Error); } } finally { if (!ignore) { setLoading(false); } } } fetchData(); return () => { // 防止组件卸载后继续 setState ignore = true; }; }, []); return { data, loading, error }; }

这里的ignore标记非常关键。异步请求返回时组件可能已经卸载，如果在卸载后调用 setState，React 会给出警告，甚至在某些场景下造成内存泄漏。这是新手最容易忽略的地方。

6.4 React Flow 与 BPMN.js：自定义流程图怎么做

热搜词里出现的“react flow”和“react bpmn.js实现自定义流程图”，其实属于 React 可视化生态中的具体场景：

1. React Flow 是一个基于 React 的节点与连线编辑器库，适合做自定义流程图、脑图、低代码编排器。
2. BPMN.js 是流程建模领域的专业库，用于 BPMN 2.0 流程图的展示与编辑，但它本身是框架无关的，需要 React 开发者自己封装成组件。

如果你需要做业务审批流、工作流编排，BPMN.js 更专业；如果只是做简单节点图，React Flow 的组件化开发体验更好。核心提示是：这类库的文档往往只负责“渲染”，复杂的布局算法、节点拖拽校验、连线存储都需要你自己设计。先跑通最小示例，再逐步扩展，不要一开始就希望完整还原一个编辑器级产品。

7. AI Agent 中的 ReAct 模式：另一个“React”

7.1 命名巧合

热搜词里出现“aiagent react”，很多前端开发者第一反应是“AI Agent 用 React 开发”，但另一个“React”也值得关注——ReAct（Reasoning + Acting，推理 + 行动）。

这是 AI Agent 领域的一种提示词工程模式。它的核心思想是让大模型在推理过程中交替进行“思考”和“行动”：

1. Reasoning：模型描述自己对当前问题的分析和下一步计划。
2. Acting：模型调用外部工具（搜索、计算、API 等）获取新信息。
3. Observation：将工具返回结果作为观测信息继续推理。

这个循环非常像前端开发中的“状态更新 + 重新渲染”：每次工具调用都会产生新的信息，每个新信息又会触发下一次决策。用 React 的思维来理解 ReAct，会更容易掌握。

7.2 一个最小 ReAct 模式的伪代码示例

async function runAgent(task, tools) { let messages = [ { role: "system", content: "你是智能助手，必须通过思考和调用工具来完成任务。" }, { role: "user", content: task }, ]; // 最多执行 8 步，防止无限循环 for (let step = 0; step < 8; step++) { const response = await callLLM(messages); // 如果模型认为可以结束，直接返回答案 if (response.finish) { return response.answer; } // 模型决定调用某个工具 const toolName = response.action; const toolArgs = response.actionInput; // 执行工具并得到观测结果 const observation = tools[toolName](toolArgs); // 把思考、行动、观测结果追加到消息历史中 messages.push(response.message); messages.push({ role: "tool", content: observation }); } return "达到最大步骤数，任务结束。"; }

这段代码只是一个逻辑演示，不是可直接运行的完整程序。它想表达的是：Agent 的每一次迭代都像一次 React 的状态更新，输入是“旧的上下文 + 新的观测结果”，输出是“下一步决策”。

理解了这一点，你就不会把“aiagent react”单纯理解成前端知识，而是看到 AI Agent 和前端框架在设计哲学上的共通性：一切围绕状态变化驱动流程推进。

8. React 面试与学习重点：别再背无效面经

8.1 React 面经里真正高频的问题

React 面试题多而杂，但核心离不开下面几个方向：

8.2 React 的学习重点是什么

React 的学习重点不是把 API 背完，而是按下面的顺序构建认知：

1. 组件化思维：一个页面如何拆成组件，组件之间如何通信。
2. 状态模型：状态来源、状态变化、状态共享、状态提升。
3. 渲染流程：一次 setState 之后 React 内部发生了什么，经过协调（reconciliation）、fiber 调度、commit 三个阶段。
4. 副作用管理：useEffect 的依赖数组、清理函数、与生命周期函数的区别。
5. 性能优化：什么时候需要优化，什么时候不需要。

很多初学者一上来就学 Redux、React Router，结果组件本身的逻辑还没理清，问题越堆越多。正确的顺序是先把基础组件写熟，再学路由与状态管理，最后看源码和原理。

8.3 React 依赖的 JS 到底是什么

React 项目的依赖并不只有 react 和 react-dom 两个包。一个完整项目通常还包含 TypeScript、路由库、状态管理库、构建工具，以及各种 Babel/PostCSS 插件。

查看依赖树是排查问题的第一步：

# 查看顶层依赖 npm ls --depth=0 # 查看某个包的具体依赖关系 npm ls react # 检查依赖安全漏洞 npm audit

如果 node_modules 里的依赖冲突导致编译失败，优先看依赖树，确认是哪个版本的包存在 peerDependencies 冲突，再决定升级版本还是用 overrides 或 resolutions 强制锁定版本。任何时候不要在生产环境直接删除 node_modules 和 lock 文件，这种操作非常危险。

9. React 常见问题与排查思路

做一个比较完整的排查表，建议收藏备用：

每个问题都能写成一篇文章，但真正重要的排错思路是统一的：

1. 先看报错信息和网络请求。
2. 再确认状态变化是否符合预期。
3. 然后缩小范围，判断是 React 逻辑问题、第三方库问题还是服务端问题。
4. 最后再修改代码，并在测试环境验证。

10. 最佳实践与工程建议

10.1 组件设计规范

功能单一：一个组件尽量只做一件事。如果一个组件的判断条件超过两三层，就该考虑拆分。

类型明确：用 TypeScript 定义 props 和 state，不要到处写 any。组件边界只有在类型清晰的条件下才可靠。

命名清晰：组件文件使用 PascalCase，普通工具函数使用 camelCase。目录结构上，建议按功能模块组织，而不是按文件类型组织。

错误处理：组件里能兜底的就兜底，比如异步请求失败显示占位 UI。应用级错误用 ErrorBoundary 包裹，避免某个组件崩溃导致整个页面白屏。

10.2 状态管理选型

不是所有项目都要上 Redux。小项目用 useState + useReducer 就够；中等项目可以引入 Zustand，写法简洁，性能好；大型复杂项目才考虑 Redux Toolkit 的规范约束。不要把状态管理库当成“解决所有问题的银弹”，它同样会带来概念负担和样板代码。

10.3 性能优化要克制

React 项目最常见的性能问题不是 React 本身慢，而是开发者做了太多无效优化。React.memo、useMemo、useCallback 并不是免费的，它们本身需要比较依赖项，代价是额外的缓存和可读性下降。建议按下面顺序优化：

1. 先减少不必要的渲染次数，比如避免父组件更新时连带渲染大量子组件。
2. 再减少渲染成本，比如拆分大组件、使用虚拟列表。
3. 最后才加缓存，且只在 Profiler 证明是性能瓶颈时加。

10.4 日志、权限与生产安全

生产环境不要在前端随意打印敏感数据；涉及用户信息的接口，前端要做基础校验，但真正的权限控制必须在服务端完成。前端代码已经部署到公网，任何“隐藏逻辑”都不安全，需要把敏感密钥放在服务端环境变量中。

如果遇到线上故障，流程上遵循“备份、回滚、最小权限、灰度验证”四原则。尤其涉及 Nginx 配置、数据库变更和依赖升级时，先改测试环境，再发小范围灰度，最后全量上线。

10.5 React 依赖的 JS 生态维护

定期更新依赖是健康工程的一部分，但不要盲目升级。React 18 升级到 React 19 这类大版本变化，要查看官方迁移指南，确认第三方库是否兼容。项目中锁定 package-lock.json 或 pnpm-lock.yaml，保证团队环境一致。

CI 流水线中建议加入 lint、类型检查、单元测试和依赖安全检查，把常见问题挡在合并之前。

11. 总结与后续学习方向

这篇文章从 B 站切片标题的“破防”梗聊起，本质上围绕 React 技术本身展开了一轮相对完整的梳理：React 的核心心智模型、React 18 批处理机制、React/Vue 路由差异、React Native 与 Taro 的多端实践、React 项目搭建与仪表盘可视化、AI Agent 的 ReAct 模式、面试与学习重点，以及常见问题和最佳实践。

如果只记一件事，我希望你记住“视图是状态的函数”这句话。React 的大部分 API、Hooks、性能优化方案，都是为了更好地实现和维护这个函数关系。React 18 的自动批处理、并发特性，也是围绕“更新调度”在做文章。跨端开发、路由、可视化、AI Agent 里的 ReAct，本质上都是状态驱动的产物。

下一步你可以这样实践：

1. 用 Vite 新建一个 React + TypeScript 项目，写一个小的待办事项或计数器，验证 React 18 自动批处理行为。
2. 把项目推到 GitHub，并在 GitHub Pages 或自己的服务器上部署一次，处理一遍 History 路由 404 问题。
3. 尝试用 React Flow 画一个简单的流程图，哪怕只是三个节点和两条连线，也能帮你理解可视化项目的组件划分。
4. 如果对 AI Agent 感兴趣，单独搜索 ReAct 论文和 LangChain 的 Agent 实现，你会发现 React 的经验在这里居然也能用。

React 生态每年都在变化，但底层的心智模型非常稳定。你可能今天还会为一个隐藏的闭包陷阱破防，但只要掌握“状态是怎么流动的、渲染是怎么触发的、副作用是怎么管理的”，下一次遇到问题就会从容很多。