企业官网建设流程全解析

1. 写了七年 Vue，是什么让我在 2026 年重新打开 React 文档

我用了七年 Vue。从 Vue 2.6 的data / methods / created一路用到 Vue 3 的 Composition API 和<script setup>，期间给团队搭过组件库，写过内部的低代码平台，也啃过不少类似《深入浅出Vue.js》这样的源码书。很长一段时间里，我觉得前端技术栈这件事选 Vue 就够了，React 充其量是“另一个圈子”的事。

但这一年多来，我发现自己越来越频繁地遇到一个尴尬场景：仓库里越来越多有价值的开源项目，前端默认是 Next.js + React；AI 编程工具随手生成的页面骨架，也几乎默认是 React；翻招聘 JD 里“必须会 React”的岗位比例越来越高，连带着“前端面试题2026”这类资料里，React 面经的数量也远超 Vue。

说到底，我并不是因为 Vue 不好才去学 React，而是因为我在一个“React 正在成为 AI 生态默认语言”的时间窗口里，不想让自己的技术视野变窄。这篇就聊聊我的完整思考、踩坑过程和一套可复制的迁移路线。

1.1 那个我从 GitHub 拉下来却看不懂的 AI 项目

具体触动我的，是一个周末的经历。我想本地跑一个开源的 LLM 对话服务，带 Web 管理界面的那种。README 写得很友好，需要先拉取项目，再补前端依赖，最后启动。我照做了，后端很快跑起来了。然后我顺手想改改前端的配色和布局，加几个自定义快捷指令，结果打开项目里的前端目录，扑面而来的是.tsx文件、useState、next.config.js，以及 Tailwind 的className堆叠。

作为一个资深 Vue 用户，那一刻我感受到的不是“代码看不懂”，而是“我居然连改一个按钮都不知道该从哪里下手”。文件结构里没有规整的.vue单文件组件，一切都是 TSX；组件就是一个导出函数的 JS 文件，样式藏在className里，状态用钩子放在函数体内。这种感觉很像开惯了手动挡车的老司机，突然坐进电动车的驾驶舱——你当然知道方向盘在哪，但仪表盘上那些陌生的东西让你不敢乱碰。

后来我才知道，那只是 React 最基础的形态。真正的困难在后面：useEffect的依赖数组为什么会死循环，为什么setState之后立刻打印数据还是旧的，为什么不能随意在渲染过程中改状态。这些全是思维习惯问题，而思维习惯恰恰是最难改的东西。

1.2 AI 生成代码的“语言偏见”真实存在，而且越来越明显

我原来以为 AI 编程助手对框架是一视同仁的。直到我拿同一个需求分别生成 Vue 和 React 版本：请帮我写一个聊天式问答页面，支持消息列表、输入框、流式输出。结果很出乎意料——React 版本生成的代码几乎可以直接跑，结构清晰，还顺手处理了中断请求的边界情况；Vue 版本也能用，但在模块切分、自定义 Hook 抽象、类型推导这些细节上，明显“生涩”一些。

这不是“AI 看不起 Vue”，而是训练语料池的结构性差异：全网范围内，React 的教程、开源项目、问答讨论、企业代码实战在绝对数量上远超 Vue，模型对“用 React 解决问题”的路径更熟悉。这个差异会进一步影响前端开发者的效率——同一条需求，用 React 写可能 15 分钟，用 Vue 可能要花 40 分钟，还不包括来回调试生成代码的时间。

这产生了一个我之前没意识到的正反馈：AI 时代，框架的“语料厚度”本身就是一种生态壁垒。AI 辅助编程会越来越普遍，而“AI 最擅长写的框架”会获得更多使用者和反馈数据，继续拉大马太效应。作为个体开发者，与其抱怨训练语料不均，不如直接去掌握那门“AI 的母语”。

1.3 写这篇不是劝你放弃 Vue，而是劝你拥有“双语能力”

这里我要把立场说清楚。Vue 在存量系统、后台管理、快速迭代的小产品里，依然是非常高效的选择。我自己的工作项目里，核心后台到现在还是 Vue 3，我不会因为学了 React 就回来说它不行。恰恰相反，认真学了 React 之后，我反而更理解 Vue 的设计优点：模板对设计师和后端转前端的同学友好，状态管理方案选择集中，团队上手成本低。

但“双语能力”这件事，我过去大半年的体会太深了：能读 React 代码，意味着你能读最前沿的 AI 开源项目；能写 React 代码，意味着 AI 生成的那一大坨高质量前端代码你改得动、接得住；面试的时候，你能在“Vue 深度”之外多一张“React 实战”牌，竞争力完全不同。这也是我写这篇最想传达的：不是改换门庭，而是在 AI 时代给自己多备一条路。

2. AI 时代的生态势差：从开源项目到面试现场，React 为什么总被优先提起

如果只是“想跟上 AI 时代”，那具体为什么是学 React，而不是 Svelte、Solid，或者干脆继续深挖 Vue？这一章我想把背后的生态逻辑摊开来讲。

2.1 LLM 应用、Agent 工具链的前端，几乎被 React/Next.js 占领

过去一两年，开源世界里和 AI 强相关的一批明星项目，比如 Lobe Chat、Open WebUI、各种 AI Agent 的 Web 管理面板，还有大量 LLM 应用模板，几乎很难看到哪个是 Vue 版本成为主流的。这不是开发者“追时髦”，而是生态选择的结果。

原因有几个：React 有全世界最庞大的组件库和解决方案；Next.js 的 SSR、流式渲染能力特别适合大模型应用那种“边生成边渲染”的交互；React 的社区治理模式和 Meta 背景，让海外团队选择技术栈的时候压力更小；再加上大量 AI 应用本身就是从英文开源社区启动的，而那个社区的历史技术资产里，React 的占比天然更高。

对普通前端开发者来说，这带来的直接后果是：你想从最新开源项目里学东西、想参与开源项目贡献代码、想基于某个 AI 应用模板做二次开发，大概率绕不过 React。技能栈里的“React 阅读理解能力”，已经变成接近“多会一门英语”那种存在——不是必须，但有了它，你能接触的东西会突然多出一个量级。

2.2 训练语料池决定了 AI 写 React 比写 Vue 更“熟”

前面提到“AI 生成代码偏 React”，根子还是在训练语料。大模型在海量网页、代码仓库、开发者问答上训练，而这个语料池里 React 相关的代码量和讨论量远高于 Vue。于是你能看到一个很明显的规律：用编程助手处理通用前端需求，它给出的默认版本十有八九是 React + TypeScript，而且细节完成度很高。

我实测过一个例子：让它生成一个带权限判断的侧边导航菜单。React 版本直接给出基于 context 的权限方案，还补了useMemo避免重复计算；Vue 版本给出的代码倒是也能跑，但用了provide/inject和 Pinia 混着写，明显没有形成稳定的模式。这类差异在几十个需求上反复出现之后，我的结论已经不只是“AI 擅长 React”，而是“用 React 去承接 AI 生成代码，效率链路最顺”。

值得留意的是，这个趋势也在反向影响 AI Agent 的开发。现在不少 Agent 工具的 UI 自动化方案，底层 DOM 操作、页面状态监听、测试用例示例代码，都大量使用 React 风格来写。学好 React，再去看这些自动化脚本和测试代码，阅读理解成本会低得多。

2.3 2026 年前端面试里，React 相关题目的占比为什么上来了

先说明：我并不是说所有面试都考 React，Vue 岗位依然大量存在。但一个直观感受是，在近年流行的那类“前端面试题2026”资源里，React 面试题的厚度和覆盖面确实在变大：Hooks 闭包陷阱、渲染优化、状态管理方案、和 TypeScript 的结合、性能调优、React 18/19 的并发特性……为什么？因为大量公司尤其是做 AI 产品、出海业务、中大型 SaaS 的公司，前端栈在向 React 迁移，团队招聘的期望画像里，React 已经成了默认项。

我自己经历过一次印象很深的面试：对方产品线其实是 Vue 3 做的，但面试官在最后专门加了一轮 React 基础面。他的原话大意是：“我们核心产品是 Vue，但接下来计划用 AI 工作流重做一部分交互，这部分大概率会用 React 生态做技术预研，希望候选人两套都能上手。”这种需求，我在一个招聘周期里至少遇到了三次。

所以，即使你的主栈是 Vue，简历上出现“React 项目经验”和“能读 React 代码、能完成跨端复用”的表述，给面试官传递的信号和“我会 Vue”是完全不同的——前者说明你没有框架洁癖，有能力在不确定的技术环境里快速迁移。这一点在 AI 时代格外重要，因为技术选型的确定性正在变低，谁也不能保证明年新项目一定用哪个框架。

3. 从 Vue 思维到 React 思维，最难的从来不是语法，是这五个转变

真正动手写 React 之后你会发现，JSX 和 Vue 模板的语法差异，大概一天就能适应。真正阴魂不散的，是过去几年用 Vue 建立起来的那套思维方式。下面列一下我踩得最狠的五个点。

3.1 指令式模板 vs 表达式化 JSX

最直观的第一个冲击：Vue 的模板是一套“HTML 扩展语言”，里面有专门的指令——v-if、v-for、v-model、@click。而 React 的 JSX 里没有指令这回事：你想条件渲染，就写 JavaScript 表达式；你想循环，就map；你想绑定事件，就传一个函数。换句话说，Vue 是在“HTML 里插逻辑”，React 是在“JavaScript 里写界面”。

来看一个最典型的对比。Vue 写法：

<template> <ul> <li v-for="item in list" v-if="item.visible" @click="handleClick(item)"> {{ item.name }} </li> </ul> </template>

React 写法：

<ul> {list .filter((item) => item.visible) .map((item) => ( <li key={item.id} onClick={() => handleClick(item)}> {item.name} </li> ))} </ul>

我在最初一两周里，经常下意识地想写v-if，发现编辑器里没有这个代码提示后，才慢慢意识到：React 不需要再发明一套指令体系，因为 JavaScript 本身已经足够表达这些逻辑了。这种“少一层抽象”的设计，一开始觉得别扭，久了反而觉得通透——你有什么状态、怎么过滤、怎么映射，全部是显式 JavaScript，没有魔法。

3.2 “自动响应” vs “显式更新”：setState 为什么总被新手忘记

用 Vue 的时候，我很少考虑“数据变了视图为什么更新”，因为框架代理了响应式系统。你写好数据对象，在模板里引用它，赋值之后界面跟着变，这属于天经地义。React 不是这样，它默认不会“侦测”你随意改掉的变量，你必须调用setState告诉 React：这个数据变了，请重新渲染。

这个区别有多深？我见过好几个 Vue 转 React 的同事，第一次写组件时写出这种代码：

const [count, setCount] = useState(0); function add() { count = count + 1; // 数据变了，但组件不会重新渲染 }

然后对着毫无反应的界面怀疑人生。正确的写法是setCount(count + 1)。这句话背后的思维模型是：React 把“状态的修改”和“视图的更新”显式地绑定在了一次 API 调用上。你每次setState，本质上是在给 React 的下一次渲染排期。

还有一个 Vue 转过来特别容易踩的坑：setState不是同步的。你调用setCount(1)之后马上想依赖新值做下一步操作，打印出来的count可能还是 0。这是因为 React 会把状态更新合并到渲染周期里。你要么在事件处理里用函数式更新，写成setCount((prev) => prev + 1)，要么用useEffect在渲染完成后取最新值。这个异步心智，和 Vue 的nextTick有点类似，但机制完全不是一回事。

3.3 组件通信：没有 $emit 和 bus 之后，反而更清爽

Vue 里最常用的父子通信策略是 props 向下、$emit向上，跨层级通信用事件总线或者 Pinia。React 的世界里没有事件总线的位置——父传子是 props，子传父本质上还是“父组件把回调函数当 prop 传下去，子组件调用这个回调”。

一开始你会觉得这很啰嗦：怎么传个消息还要层层写回调？直到你在大型项目里被 Vue 的隐式总线坑过，才会理解 React 的显式回调有多利于排查。数据从哪来、被谁改、经过哪些函数，全部在代码里一目了然，不会出现“我$on注册了事件但不知道是谁$emit的”这种悬案。

跨层级共享状态时，Vue 的provide/inject和 React 的 Context 思路相通，但 React 用起来更容易形成稳定模式：Context 在函数组件里就是useContext(MyContext)，配合useReducer可以模拟类似 Redux 的单向数据流。它迫使你把状态图画出来，这在后期维护上的收益，远比“省几行代码”重要。

3.4 从钩子函数到 useEffect 依赖数组：副作用要自己管理

Vue 的生命周期耳熟能详：onMounted、onUpdated、onUnmounted。很多人刚接触 React 时，会误以为useEffect就是onMounted，我一开始也这么用——在useEffect(() => { ... }, [])里做初始化请求，跑起来倒也对。但真正的区别在于：useEffect是“和渲染结果同步的副作用调度器”，依赖数组里写什么，决定了它什么时候执行。

最经典的一个坑是死循环：

useEffect(() => { setCount(count + 1); }, [count]);

这段代码里，count一变，useEffect 执行，执行体里又把count + 1，然后又触发 effect……这比 Vue 的 watcher 更容易让新手原地爆炸，因为 Vue 的watch通常不会去监听自己修改的那个数据源。

正确的理解方式是：useEffect 依赖数组里的值，是“指示 React 什么时候需要重新订阅这个副作用”的信号，而不是“在这个函数里少碰这些变量”。真正稳妥的做法是尽量在事件处理函数里改状态，useEffect 只负责和外部系统同步——订阅、轮询、定时器、DOM 操作这些。等这个模型想通，React 的副作用管理其实比 Vue 的散装钩子更集中。

3.5 框架是“全家桶”还是“乐高积木”：两种哲学的碰撞

Vue 给人的印象是“渐进式全家桶”：core + vue-router + Pinia + 官方文档一气呵成，团队约定少，标准统一。React 更像乐高积木：官方只提供核心渲染能力，路由要用 react-router 或 Next.js，状态管理要用 Redux、Zustand 或 Jotai，数据请求要用 TanStack Query 或 SWR。你面临的不只是“怎么选”，还有“为什么不选”。

这种自由度前期非常劝退：我常常打开一个 React 项目，发现它用的状态库和我上次看的不一样，路由写法也有差异。但两三个月之后，我才慢慢理解自由度的价值：React 项目的技术栈是“选”出来的，每个选择背后都有团队对业务场景的权衡；而 Vue 项目则是被文档“带”着走，一致性高，但可塑性略弱。

这是两种工程哲学，没有孰优孰劣。但作为开发者，多体会一种“手动拼装”的哲学，会显著提高你对架构的敏感度。我甚至觉得，学 React 最大的收获并不是 React 本身，而是被迫重新思考了很多 Vue 曾替我默认决定过的问题：状态放哪里、数据请求放哪里、性能在哪一层优化。

4. 一个月迁移计划：从“能看懂”到“能上手写 React”

如果你决定试试，我给出一套自己验证过的四周路线。不需要辞职，每天一到两个小时，一个月后你就具备“读懂 React 项目源码 + 上手写一个小东西”的能力。

4.1 第一周：用最小火力拆掉语法障碍

第一天不要刷概念，直接搭环境：用 Vite 创建一个 React + TypeScript 项目，然后把默认模板改成一个由 3 个组件拼成的简单页面。目标只有一个：熟悉.tsx文件长什么样。

这一周你要过一遍这些基础项：JSX 表达式与className、事件绑定onClick与 Vue 的@click的区别、props 的 TypeScript 定义、useState的基本用法、列表渲染的map和key的作用。我推荐拿 Vue 的写法对照着看，同一个功能两种框架各写一遍，比如计数器、待办事项、一个带输入框的表单。

核心心法是：不要在 JSX 里找 Vue 的影子。这一周的目标不是写出优雅代码，而是尽快把条件渲染和列表渲染的肌肉记忆切换过来，让自己不再下意识去找指令。

4.2 第二周：把 Hooks 四兄弟用熟，这是 React 的根

第二周专攻四个 Hook：useState、useEffect、useMemo、useCallback。不需要研究太多原理博客，我建议直接做一个带实际副作用的页面，比如一个支持搜索防抖的列表，或者一个定时拉取最新数据的看板。

• useState：管理组件自身状态，替换 Vue 里ref/reactive的使用场景。
• useEffect：处理副作用，替换 Vue 的onMounted和watch。
• useMemo：缓存计算结果，替换 Vue 的computed。在 React 里渲染函数会整体执行，如果不缓存，数据量大的重计算会直接影响每一帧渲染。
• useCallback：缓存函数引用，配合子组件的memo使用。这是 React 做性能优化的关键抓手，也是 Vue 自带更新优化后你不太会想到的东西。

这一周最容易困惑的点是useMemo和useCallback到底该用在哪里。我的经验是：先别过度优化，等页面真的卡了，或者需要传回调给memo子组件时再加。初学阶段，理解它们是用来控制“重新渲染范围”的即可。

4.3 第三周：把一个真实的 Vue 小项目逐行搬到 React

这是整个计划里价值最高的一步。从你自己的历史项目里挑一个体积在 10 来个小组件的中小型 Vue 页面，比如一个后台表单页加一个列表页，逐行用 React 重写。注意：不要用 AI 直接整段翻译，先自己动手写一遍，写完再交给 AI 检查并优化。

迁移过程中，你会密集体会前面说的思维差异：v-model变成受控组件，this.$emit变成回调 props，computed变成useMemo，watch变成带依赖数组的useEffect。我当时迁移一个数据看板时，特意把 Vuex 状态改成 React 的useReducer，瞬间理解了 action 和 reducer 为什么比 mutation 更接近纯函数。

这一周结束的标志是：你能不看参考，独立写出一个有异步请求、条件渲染、父子通信、状态共享的页面。到了这一天，React 已经不再是“另一个框架”，而是你的第二语言。

4.4 第四周：用 AI 辅助完成一个现学现卖的 React demo

第四周建议做一个和 AI 相关的完整小应用，目的不在乎“做产品”，而在体验“React + AI 工具链”的真实协作节奏。比如一个基于大模型 API 的问答助手前端：消息列表、输入框、流式输出展示、上下文保留。这里会用到 SSE 或者 WebSocket 来接收流式数据，这本身也是近几年很热门的前端技能点。

你可以让 AI 先写一版，然后在其基础上继续改造：

• 把输入框改成受控组件，支持 Enter 发送
• 把消息列表抽成独立组件，用 props 和memo优化
• 加上 loading 和中断取消的交互状态

这几步会把前面学的知识全部串起来。而且到这时你会有一个很现实的感触：回头看 AI 生成的 React 代码，已经不再是一个看不懂的黑盒，而是能指出“这里依赖数组漏了依赖”“这里应该用useMemo”的水平。能 review AI 写的代码，才算是真正掌握一门技术栈。

我做过的一个 react + SSE/WebSocket 实时展示文件变化的小工具，最开始就是第四周的产物。它用 React 渲染一个文件状态列表，通过 WebSocket 推送内容变化，界面实时刷新。这个项目小到能讲清楚，但又涉及状态更新、列表 diff、类型定义，深度刚刚好。

4.5 这四周里我实际踩过的五个坑

1. 没有给列表加 key，或者拿 index 当 key。Vue 里v-for也要求 key，但缺失时兼容性反而更“宽容”；React 里 key 写错会导致状态错乱，尤其列表项可删除或排序时，可能渲染出完全错误的 UI。
2. 在渲染函数里直接修改 props 或 state。React 不会主动检测这种修改，结果就是 UI 不更新或者隐性 bug。改状态一律放到事件处理函数、定时器回调或useEffect里。
3. setState 连续调用依赖旧值。比如连点三次 +1，如果写setCount(count + 1)，实际可能只加了一次；正确写法是函数式更新setCount((prev) => prev + 1)。
4. useEffect 里的清理函数忘记写。Vue 的onUnmounted是显式的，React 的useEffect则把“下一次执行前要清理上一次”的机制内建进去。订阅、定时器、全局事件监听都必须在 return 里清理，否则组件卸载后还会继续执行。
5. 滥用 context 导致全局重渲染。Vue 的provide/inject有类似问题，但 React 的 context 一旦变化，所有消费它的组件都会重渲染。如果存的是非 UI 类状态，建议拆 context，或者直接换用 Zustand 这类轻量库。

5. 学 React 不等于背叛 Vue：2026 年项目选型的个人判断

学了一段时间之后，你自然会面对那个问题：实际项目里到底该选 Vue，还是选 React？

5.1 我会继续用 Vue 的场景

如果是公司内部的存量系统、运营后台、中后台管理界面，并且团队已经沉淀出一整套 Vue 技术栈和组件库，我不会考虑迁移。这类项目的特点是：页面密集、结构相对规整、不需要太前沿的交互、团队迭代速度要求高，Vue 的模板直观和组件封装模式反而是效率利器。配合成熟的桌面端组件库，任意成员两天就能搞定一个复杂的表单页。

另一个场景是偏快速验证的产品原型。Vue 的上手成本低，文档路径清晰，对“不打算长期维护”的 MVP 来说，开发速度和心智负担都很友好。我自己做个人小工具时，还是经常用 Vue + Vite，十分钟出来一个页面，体验确实很顺。

5.2 我会优先上 React 的场景

反过来看，将来凡是和 AI 深度绑定的产品——大模型应用前端、Agent 工作台、需要流式渲染和并发更新的页面——我会默认选 React + Next.js。原因很好理解：生态模板多、流式渲染顺手、开源参考项目丰富，而且 AI 辅助编码在这里效率最高。

国际化、出海业务也倾向 React。海外工程师的技术习惯、设计系统模板、登录支付组件、路由和 SEO 方案，React/Next.js 的资料是最不缺的。如果团队招聘时特别看重“AI 应用前端”这个标签，React 也是更被认可的入场券。

还有一个场景我会主动选 React：当团队对前端架构的长期演进有明确想法时。React 技术栈的自由度允许你按业务定制状态层和请求层，而不是被一套官方方案牵着走。这种选择需要更强的工程判断力，但长期看更有可能沉淀出贴合业务的架构。

5.3 跳出框架：前端开发 skills 的底层是什么

框架只是工具，一个前端工程师的底层能力其实和框架无关：对 DOM 和浏览器渲染机制的理解、对网络协议和请求优化的把握、对状态管理和数据流模型的认知、对 TypeScript 类型系统的熟练度、对用户体验和可访问性的判断。

学完第二个框架，最大的收获是会被迫从这些底层维度重新审视所有选择。比如学了 React 的useMemo，你才会回头想 Vue 的computed到底是凭什么帮你省去那么多重计算；学了 React 的受控组件，你才会意识到 Vue 的v-model本质上就是 value + onChange 的语法糖。这种“拆穿魔法”的过程，才是能力真正的提升点。

平时做需求时，我也提醒自己不要一开始就纠结用 Vue 还是 React，先把需求的数据流理清楚：数据从哪来、要变成什么样、用户如何与它交互。数据流想明白之后，框架只是实现细节。比如处理 m3u8 流媒体播放，或者做 K 线图这类专业图表，网上靠谱的开源库往往同时提供 Vue 和 React 封装，这时候懂两套框架意味着你能直接读懂封装源码，而不是只能等别人出插件。再比如 Electron 场景，主进程和渲染进程的 IPC 通信方式和 Vue 或 React 本来就没关系，但社区里 React 的配套示例和模板明显更多，解决一个 Electron 集成问题时，你天然多一种检索路径。

5.4 给你的最小行动建议

最后给一个最轻量的行动建议：不要立 flag，不要发“我要学 React”的公开宣言，直接打开电脑，零成本地建一个 React 脚手架，今天就把一个 Vue 组件翻译成 JSX。第一天哪怕只是把v-if改成&&，把@click改成onClick，你都已经迈出第一步了。第二周再考虑要不要深入，第三周拿着真实项目练手。

技能迁移的本质是认知重构，而不是收集更多知识点。与其等到面试和项目压力来临时焦虑，不如把这件事当成一个顺手推进的小事。而且学 React 的过程会同时加深你对 Vue 的理解，这件事本身就是最好的回报。

我在实际迁移中的体会是：真正走进 React 之后，最大的变化不是多会了一个框架，而是我不再被“Vue 人 / React 人”这种标签限制了。我可以直接打开任何一个开源项目，看两行代码就大致明白它的状态管理思路，然后决定是借鉴还是绕开。这种可以自由选择的余量，才是 AI 时代前端工程师最值得攒的东西。如果你也正处于“想学又觉得没必要”的纠结状态，我的建议是从今晚二十分钟的 JSX 练习开始，剩下的交给时间。