前阵子接手了一个让我记忆深刻的改造任务把一套基于Vue 3写的后台管理系统整体搬迁到React技术栈。业务方给的理由很直接——团队主力框架已经切到React老项目继续维护Vue只会越拖越重。听起来不过是“多学一个框架”的事真动起手来才发现真正的难点不在框架语法而在怎么把一套已经成型的标准化技能栈完整地“平移”过去。这篇文章就围绕这次跨框架移植重点聊聊标准化技能栈的构建思路以及在整个过程中让我踩坑最多的路由机制。如果你正在面对框架统一、老系统迁移、多端复用这些问题这篇内容值得你花十分钟仔细读一读。1. 先搞清楚标准化技能栈到底在标准化什么1.1 多框架并存的现实痛点先说一个很多团队都会遇到的真实情况。业务线扩张之后老项目用Vue 2新项目用React还有一些工具页面用原生JS加jQuery。表面上看大家各干各的实际上代码里重复的东西非常多。登录鉴权逻辑三套系统里写了三遍用户列表页的交互两个框架里各实现了一次路由权限的判断规则在A项目里写在路由配置里在B项目里直接写在了组件内部。这种局面带来的问题不只是维护成本翻倍更麻烦的是人的经验无法复用。新同学入职明明在前一家公司把Vue写得很熟到了这边要用React重写一遍老员工换项目也得先花一两周熟悉另一套框架的写法。项目的复杂度一上来团队的分工协作就会变得很别扭——大家很难共用一套代码规范也很难把某个模块的“最佳实践”沉淀下来。我见过最夸张的情况是同一个业务接口的请求逻辑在两个项目里各自封装了一遍参数名、错误码、重试策略全不一样。后面接口要加一个参数前端得同步改两处漏改一处线上就出bug。这种问题不是你多写几个工具函数能解决的本质上是团队缺少一套“无论用什么框架都不会变”的公共技能栈。1.2 稳定层与变化层的拆分思路我自己的体会是跨框架移植这件事前置工作不是先去查新框架的语法而是先把现有代码里“稳定的部分”和“会变化的部分”拆开。只有想清楚哪些东西是不依赖框架的才谈得上“移植”否则你就是在重写不是迁移。举一个最直白的例子。一个登录模块里面包含哪些东西表单的UI结构和校验交互这是随框架变的。用户提交的用户名和密码组装成接口请求参数这是不变的。请求成功之后把token存起来、把用户信息写入全局状态、跳转到首页这是不变的。路由守卫里判断“有没有token”“token是否过期”这是不变的。按钮点击时的loading态、禁用态这是随框架变的。我建议把这几部分画成一张清单区分出“稳定层”和“变化层”。稳定层是业务规则包括数据模型、接口协议、权限模型、状态流转变化层是表现层包括组件的写法、渲染方式、生命周期钩子、状态管理库的API。分层包含内容是否随框架变化稳定层接口定义、数据结构、权限规则、路由表、状态流转逻辑否变化层组件模板/JSX、指令v-if/v-for、生命周期写法、框架路由/状态库API是标准化技能栈的核心就是尽量把代码往稳定层里放。组件里只留体现层逻辑业务规则全部下沉到底层。这样哪天换框架你要重写的只有最上面薄薄一层下面一层老代码可以原样搬过去。1.3 一套可以带走的知识骨架再往深一层想标准化技能栈不能只停留在“代码分层”这个粒度上。对开发者个人来说真正值钱的是一套“无论用什么框架都能回答问题”的知识骨架。比如页面入口是怎么加载的是直接渲染组件还是经过路由匹配后懒加载页面从哪来、数据存在哪、操作怎么流转多个页面共享的状态放在哪里作用域怎么控制用户能不能访问某个页面/接口权限判断在哪里做页面销毁时定时器、事件监听、网络请求要不要清理这些问题不管是Vue、React还是别的框架答案的骨架都是一样的。框架只是给你提供了不同的语法和API来回答这些问题。你如果脑子里有这套骨架迁移的时候就是在“不同框架的答案之间做映射”而不是从零开始学一个新体系。这也是为什么很多人在一个框架里写了三五年换一个框架很快就上手而有些人看起来用过很多框架真遇到迁移需求还是抓瞎。关键区别就在于前者脑子里装的是“技能栈”后者脑子里装的只是“API列表”。2. 跨框架移植从Vue到React的核心方法论2.1 第一步把业务逻辑从组件里抽出来开始动手迁移之前一定要先把业务逻辑从组件里抽出来。这一步做的越彻底后面迁移越顺利。拿一个常见的用户列表页来说Vue组件的script部分可能长这样script setup import { ref, onMounted } from vue import { getUserList, deleteUser } from /api/user const list ref([]) const loading ref(false) async function fetchList() { loading.value true try { const res await getUserList({ page: 1, pageSize: 20 }) list.value res.data.list } finally { loading.value false } } async function handleDelete(id) { await deleteUser(id) fetchList() } onMounted(fetchList) /script这个写法本身没毛病但如果整个项目都是这个风格那迁移到React的时候这里所有逻辑都要用hooks重写一遍。真正好迁移的结构应该是这样的先把“获取列表”这个动作变成一个不依赖框架的纯函数// services/userService.ts export async function fetchUserList(params: PageParams): PromiseUserList { const res await getUserList(params) return { list: res.data.list, total: res.data.total } }组件里只负责“调用这个函数把结果渲染出来”以及“处理loading和错误状态”。这样迁移的时候service文件可以直接拿过去组件里只是换一种方式调用而已。我个人建议在项目里建立一个services目录专门放所有跟接口打交道的逻辑。组件里不允许直接写axios.get这类调用必须通过service包一层。这个习惯不仅对跨框架迁移有帮助对单元测试、接口mock、多端复用都有好处。2.2 第二步状态管理的等效替换状态管理是跨框架移植中特别容易踩坑的地方。很多人在Vue里用Pinia用习惯了到了React就想着怎么把Pinia的“那一套”搬到React里来其实没必要。两个框架的状态管理库虽然API不同但底层要解决的核心问题是同一个在组件外部维护一份共享状态让多个组件能读到同一份数据并且数据变化时触发界面更新。以用户登录信息为例Vue项目里的Pinia store长这样// stores/user.ts import { defineStore } from pinia export const useUserStore defineStore(user, { state: () ({ token: localStorage.getItem(token) || , userInfo: null }), actions: { setToken(token: string) { this.token token localStorage.setItem(token, token) }, async fetchUserInfo() { this.userInfo await getUserInfoAPI() } } })迁到React以后用Zustand写出来的是这样// stores/user.ts import { create } from zustand interface UserState { token: string userInfo: UserInfo | null setToken: (token: string) void fetchUserInfo: () Promisevoid } export const useUserStore createUserState((set) ({ token: localStorage.getItem(token) || , userInfo: null, setToken: (token) { set({ token }) localStorage.setItem(token, token) }, fetchUserInfo: async () { const userInfo await getUserInfoAPI() set({ userInfo }) } }))如果你把这两份代码放在一起对比会发现除了API长得很不一样之外核心的数据结构完全是同一套。所以明智的做法是先定义好状态的TypeScript类型再把状态操作抽成纯函数最后才去套框架的store壳子。类型定义和业务逻辑都可以跨框架复用只有最外层那十几行Store定义需要重写。2.3 第三步模板语法与JSX的映射对照UI层是整个迁移过程中工作量最大的部分。Vue用模板语法React用JSX两者虽然都是声明式描述界面但写法差异很大。如果你把Vue的模板和React的JSX放在一起对比可以总结出一张映射表Vue模板React JSXv-ifcondition{condition Comp/}或{condition ? A/ : B/}v-foritem in list{list.map(item ...)}v-modelvaluevalue{value} onChange{(e) setValue(e.target.value)}:class{active: isActive}className{isActive ? active : }v-showvisiblestyle{{display: visible ? block : none}}计算属性computeduseMemo(() ..., [deps])监听器watchuseEffect(() ..., [deps])举个具体的例子。一个简单的用户列表模板Vue写法template div classuser-list div v-ifloading classloading加载中.../div div v-else-iferror classerror{{ error }}/div ul v-else li v-foruser in filteredList :keyuser.id span{{ user.name }}/span button clickhandleDelete(user.id)删除/button /li /ul /div /templateReact里对应的是function UserList() { if (loading) return div classNameloading加载中.../div if (error) return div classNameerror{error}/div return ( ul {filteredList.map(user ( li key{user.id} span{user.name}/span button onClick{() handleDelete(user.id)}删除/button /li ))} /ul ) }映射关系很清晰。这里我想提醒一点v-for渲染列表时:key对应到React里的key这个一定要保持值一致否则切换框架之后列表会出一些诡异的重绘问题。还有一点Vue的模板里可以写一些简单的表达式但React的JSX本质上就是JavaScript可以直接调用函数能力边界完全不同——算是迁移过程中的一个小惊喜。2.4 第四步生命周期与副作用函数的对齐生命周期处理是迁移中另外一个容易出bug的地方。Vue 3的组合式API里有onMounted、onUnmounted、watchReact里的对应物是useEffect。先看Vue的写法script setup import { ref, onMounted, onUnmounted } from vue const count ref(0) const timer ref(null) onMounted(() { timer.value setInterval(() { count.value }, 1000) }) onUnmounted(() { clearInterval(timer.value) }) /scriptReact的写法import { useState, useEffect } from react function Counter() { const [count, setCount] useState(0) useEffect(() { const timer setInterval(() { setCount(c c 1) }, 1000) return () clearInterval(timer) }, []) return div{count}/div }从效果上看useEffect(() {...}, [])和onMounted(() {...})基本对应useEffect里的return函数和onUnmounted对应。但这里有一个关键差异很多从Vue迁到React的人都会踩坑Vue的onMounted和onUnmounted是分开的两个钩子职责单一清晰。React的useEffect同时承担了挂载、更新、卸载三件事依赖数组变化会触发重新执行清理函数也会跟着重新执行。比如上面的定时器例子如果你把依赖数组写成了[count]那每次count变化定时器都会被清除再重建一次表现就是计时器会跳秒或者越来越慢。这种问题在Vue里几乎不会出现因为Vue的watch和生命周期钩子分工明确你得主动写watch才会去监听变化。所以在迁移时一定要仔细核对每个onMounted/onUnmounted对应的副作用在useEffect里通过依赖数组明确控制执行时机而不是凭感觉随便填一个空数组。3. 路由机制解析跨框架移植中最容易翻车的一环3.1 路由的三种工作模式你必须彻底搞懂路由是这次跨框架移植里让我折腾最久的部分。原因很简单路由不只是“URL对应哪个页面”这么简单它还牵扯到页面刷新、权限控制、懒加载、前进后退每一个细节在不同框架里的处理方式都不一样。先从底层原理说起。前端路由主要有三种工作模式hash模式URL中带一个#号例如https://example.com/#/user/list。路由切换时只改变#后面的部分浏览器不会向服务器发起请求。核心机制是监听浏览器hashchange事件拿到新的hash值后匹配对应的组件渲染。优点是不需要服务器任何配置刷新不会404缺点是URL里带#不好看而且不利于SEO不过对后台系统影响不大。history模式URL看起来是正常的路径例如https://example.com/user/list。切换路由时利用history.pushState方法在浏览器历史栈里添加一条记录再配合popstate事件监听前进后退。优点是URL干净美观缺点是刷新当前页面时服务器必须把所有路径都重定向到首页否则会直接404。memory模式路由状态完全保存在内存里不依赖URL。这种模式主要用于非浏览器环境比如SSR、单元测试、或者一些嵌在原生应用里的WebView。模式URL示例刷新行为适用场景hash/#/user/list无需服务器配置静态部署、简单页面history/user/list需服务端重写规则常规SPA、SEO优化memory无URL变化完全内存态SSR、测试、特殊嵌入Vue Router默认使用hash模式也支持history模式React Router底层基于history库可以自由切换。但注意默认模式不一样。Vue Router 4默认是hash模式React Router在Web环境下默认是history模式。迁移时如果不显式设置就会出现“Vue项目里一切正常搬到React后刷新页面直接404”的尴尬状况。3.2 手写一个Mini Router理解底层原理与其被各种路由库的API绕晕不如亲手实现一个极简版的路由器理解了原理以后任何框架的路由API在你眼中都只是包装层。下面我用原生JavaScript实现一个简化版的路由分发器。先定义一个路由表再监听hash变化匹配到对应组件就渲染// mini-router.js class MiniRouter { constructor(routes) { this.routes routes this.current null window.addEventListener(hashchange, () { this.handleRoute() }) } handleRoute() { const path window.location.hash.slice(1) || / const matchedRoute this.routes.find(route route.path path) if (matchedRoute) { this.current matchedRoute matchedRoute.render() } else { // 没有匹配到路由时执行兜底逻辑 this.handleNotFound(path) } } push(path) { window.location.hash path } handleNotFound(path) { console.warn(No route matched: ${path}) } }使用的时候你只要预先注册好路由表然后实例化路由器初始执行一次handleRoute即可const routes [ { path: /, render: () renderHomePage() }, { path: /user/list, render: () renderUserList() }, { path: /user/detail, render: () renderUserDetail() } ] const router new MiniRouter(routes) router.handleRoute()这个例子展示了路由机制最核心的骨架路由表是数据hash变化是触发器匹配到的处理函数是执行单元。你看这里面根本没有框架的事情。Vue Router和React Router做的无非是把“匹配到后执行渲染”这一步接入了各自的组件渲染机制并且补充了懒加载、嵌套路由、路由守卫等高级能力。想通了这一层跨框架移植路由的时候你只需要关心“如何把同一份路由表翻译成目标框架的组件映射结构”而不是把路由的思想推倒重来。3.3 路由表设计的最佳实践在跨框架移植的过程中我发现最值得做的优化是把路由表本身抽成一份与框架无关的纯数据配置。设想一下一份完整的业务路由配置至少应该包含这几项信息页面的访问路径path页面对应的组件component页面的标题meta.title是否需要登录meta.requiresAuth访问权限标识meta.permission是否懒加载lazy我把这些定义放在一个独立的路由数据文件里// router/routes.ts export interface AppRoute { path: string component?: () Promiseany meta: { title: string requiresAuth: boolean permission?: string } children?: AppRoute[] } export const appRoutes: AppRoute[] [ { path: /dashboard, component: () import(/pages/Dashboard), meta: { title: 工作台, requiresAuth: true } }, { path: /user/list, component: () import(/pages/UserList), meta: { title: 用户列表, requiresAuth: true, permission: user:list } }, { path: /login, component: () import(/pages/Login), meta: { title: 登录, requiresAuth: false } } ]这份配置文件里不出现任何Vue Router或React Router的API。迁移的时候这份文件原封不动搬过去只需要写一个适配层把它翻译成目标框架的路由配置。Vue Router 4的适配大概长这样// router/vue.adapter.ts import { createRouter, createWebHashHistory } from vue-router import { appRoutes } from ./routes const vueRoutes appRoutes.map(route ({ path: route.path, component: route.component, meta: route.meta, children: route.children?.map(child ({ ...child })) })) export const router createRouter({ history: createWebHashHistory(), routes: vueRoutes })React Router的适配则是这样// router/react.adapter.tsx import { createBrowserRouter } from react-router-dom import { appRoutes } from ./routes export const reactRouter createBrowserRouter( appRoutes.map(route ({ path: route.path, element: React.lazy(route.component), children: route.children?.map(child ({ path: child.path, element: React.lazy(child.component) })) })) )你看只要路由表本身就是纯数据从Vue迁移到React就是写两个不到二十行的适配函数完全用不着大量重写路由相关代码。3.4 路由守卫的两种实现思路对比路由守卫是权限控制的关键也是两个框架差异比较大的地方。Vue Router提供了beforeEach这种全局前置守卫官方概念是“守卫”React Router没有对应的“守卫”API更常见的做法是写一个包装组件或者用useNavigate做跳转拦截。但底层的判断逻辑完全可以抽成一份公共函数。先看Vue的写法// router/guard.ts export function authGuard(to) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { return { path: /login } } if (to.meta.permission !hasPermission(to.meta.permission)) { return { path: /403 } } return true }在Vue Router里注册router.beforeEach((to) { return authGuard(to) })React这边我通常写一个AuthGuard组件来承接这套逻辑// components/AuthGuard.tsx import { Navigate, useLocation } from react-router-dom export function AuthGuard({ children }: { children: React.ReactNode }) { const location useLocation() const routeMeta getRouteMeta(location.pathname) const check authGuard({ meta: routeMeta }) if (check true) { return {children}/ } return Navigate to{check.path} replace / }在使用时把需要鉴权的路由用AuthGuard包一层即可。你会发现核心的authGuard函数在两个框架里完全一样变的只是“在哪里调用这个函数”的机制。我建议你把权限判断、登录状态检查、页面标题设置这些逻辑全部抽成独立的工具函数不要散落在各个页面组件里。这样等到哪天路由库升级或者再次迁移时这些核心判断逻辑一行都不用改。4. 实操实录后台用户管理模块的完整移植过程4.1 移植前评估清单与工作量估算下面用一个具体模块——后台用户管理——来演示完整的迁移过程这也是我这次项目的缩影。开始动手前我列了一份评估清单把模块里所有东西都盘点清楚类别具体内容数量页面用户列表、用户详情、新增/编辑弹窗5个视图接口列表查询、详情查询、新增、编辑、删除、批量操作7个接口路由列表页、详情页带权限控制2个路由状态当前查询条件、选中项、列表数据3个全局状态权限按钮级权限、页面访问权限两类这里我想强调一个重要原则永远不要直接对整个系统“一把梭”迁移。把系统拆成独立的业务模块先挑一个模块完整走一遍流程验证迁移方案可行之后再铺开到其他模块。我当时选的就是用户管理模块因为它的增删改查逻辑最典型权限粒度适中很有代表性。4.2 路由与权限部分的搬迁第一步迁移的是路由和权限。这部分最有代表性因为它最容易出错。原Vue项目的路由配置是这样的// router/index.ts import { createRouter, createWebHashHistory } from vue-router const router createRouter({ history: createWebHashHistory(), routes: [ { path: /user/list, name: UserList, component: () import(/views/user/UserList.vue), meta: { requiresAuth: true, permission: user:list } }, { path: /user/detail/:id, name: UserDetail, component: () import(/views/user/UserDetail.vue), meta: { requiresAuth: true, permission: user:detail } } ] }) router.beforeEach((to) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { return /login } })我先把路由表数据抽出来保持路径、权限标识、标题这些信息完全不变// router/userRoutes.ts export const userRoutes [ { path: /user/list, meta: { title: 用户列表, requiresAuth: true, permission: user:list } }, { path: /user/detail/:id, meta: { title: 用户详情, requiresAuth: true, permission: user:detail } } ]然后在React项目里用这套数据生成React Router配置// router/index.tsx import { createBrowserRouter } from react-router-dom import { AuthGuard } from /components/AuthGuard import { userRoutes } from ./userRoutes export const router createBrowserRouter([ ...userRoutes.map(route ({ path: route.path, element: ( AuthGuard permission{route.meta.permission} UserLayout / /AuthGuard ), children: [ { index: true, element: UserList / }, { path: detail/:id, element: UserDetail / } ] })) ])这里有个容易踩的细节坑Vue Router的动态参数是:idReact Router用的是:id语法相同但两者在子路由的嵌套匹配规则上有差异。Vue的嵌套路由在父路由下通过children匹配完整路径React Router里子路由的path如果以/开头就会变成绝对路径一不小心就会摸不到父布局。我的建议是迁移时保持子路由的path为相对路径不要带前导/。4.3 状态层与服务层替换接着处理状态层。用户管理模块里有一个“当前选中的用户ID”和“查询条件”需要在多个页面之间共享。原Vue项目的Pinia store// stores/userModule.ts import { defineStore } from pinia export const useUserModuleStore defineStore(userModule, { state: () ({ searchParams: { keyword: , status: }, selectedUserId: null as string | null }), actions: { setSearchParams(params) { this.searchParams { ...params } }, setSelectedUserId(id: string) { this.selectedUserId id } } })React项目里用Zustand重写// stores/userModule.ts import { create } from zustand interface UserModuleState { searchParams: { keyword: string; status: string } selectedUserId: string | null setSearchParams: (params: { keyword: string; status: string }) void setSelectedUserId: (id: string | null) void } export const useUserModuleStore createUserModuleState((set) ({ searchParams: { keyword: , status: }, selectedUserId: null, setSearchParams: (params) set({ searchParams: { ...params } }), setSelectedUserId: (id) set({ selectedUserId: id }) }))可以发现重写的只是Store的定义业务逻辑——查询条件的合并、选中用户ID的赋值——完全没有变化。如果你当初把接口调用也收口在了service文件里那这一步更是毫无压力直接沿用原来的fetchUserList、deleteUser这些方法即可。这里有一个实操要领迁移state的时候一定要把TypeScript类型一并搬过来。很多人在Vue项目里对TS类型不重视用的是JSDoc甚至纯JS到了React项目里类型系统更依赖显式声明早一点把类型补齐后面React组件的props传递会顺滑很多。4.4 UI层重写与验收要点UI层是工作量最大的部分。Vue的UserList.vue里有一个表格、筛选表单、删除确认弹窗我迁移时把它拆成了几个独立组件UserFilterForm、UserTable、DeleteConfirmModal。关键不是去重写HTML结构而是把“逻辑”和“样式”分开考虑。表格列定义在Vue里通常是写在el-table-column上的到React里可以抽成一个纯粹的列配置数组// components/UserTable/columns.tsx export const userColumns [ { title: 姓名, dataIndex: name, key: name }, { title: 邮箱, dataIndex: email, key: email }, { title: 操作, key: action, render: (_, record) ( div Button onClick{() onEdit(record)}编辑/Button Button danger onClick{() onDelete(record)}删除/Button /div ) } ]这种列配置抽出来后以后如果再换成别的UI库只需要换表格组件本身列定义可以原样复用。验收阶段我觉得最值得仔细检查的三件事路由跳转的往返一致性。从列表页进入详情页返回时是否保持了之前的查询条件和页码。权限边界的行为一致性。没有某个按钮权限的用户是否在两种框架下都看不到按钮没有页面权限的用户是否都会被重定向到403页。浏览器前进后退的兼容性。用history模式时刷新详情页是否正常直接访问一个深层链接是否被正确处理。5. 移植过程中踩过的坑和解决方案5.1 典型问题速查表整个迁移过程踩了不少坑我把其中最典型的整理成一张速查表你可以直接对照排查问题现象根本原因解决方案React项目刷新页面404history模式需要服务端配合在部署配置里添加所有路径重定向到index.html的规则路由懒加载后白屏React.lazy组件需要Suspense包裹在路由容器外层加Suspense fallback{Loading/}定时器越走越快useEffect依赖数组漏写了依赖项导致清理逻辑没执行仔细检查useEffect的依赖数组确保清理函数正确执行列表组件状态混乱切换路由后React组件没有按预期重新渲染检查路由组件的key设置必要时给页面组件加key强制重建点击浏览器后退页面不更新只在pushState后手动处理没监听popstate确认框架路由已正确处理浏览器前进后退事件全局状态被意外重置状态Store定义在组件内部导致实例重建确保状态Store定义在组件外部且使用全局单例模式5.2 我的几点独家建议最后分享几个这次迁移中沉淀下来的经验属于那种“做之前想不到做完之后觉得必须写下来”的东西。第一个建议迁移过程中不要“一步到位”。很多人一看要迁移就想着抽两周时间一次性把所有代码都改造完。实际上一次全量迁移的风险极高出了问题回滚成本也大。更稳妥的做法是两个框架并行运行——旧框架继续支持线上流量新框架在同一份路由表下逐步接手页面通过一个灰度标识控制流量。当所有页面都验证OK之后再彻底下线旧框架代码。这个方案对团队的心理压力也小很多不会出现“今天上线迁完就必须成功否则线上崩溃”的极端情况。第二个建议用适配器模式封装框架API。比如路由跳转在两个框架里的API分别是router.pushVue和useNavigate()React。如果业务代码里到处直接调用这些API迁移时改起来就非常痛苦。我在项目里统一封装了一个navigate(path)函数所有页面跳转都走这个函数内部才去调用对应框架的API。迁移时只需要改这个函数内部一行代码整个项目的跳转逻辑就全部切换了。同理消息提示、对话框、Loading态这些UI能力都建议封装。封装的成本很低但是长期收益极高。第三个建议把“查询参数”当作路由设计的一等公民。这次迁移让我深刻体会到列表页的查询条件、排序字段、分页信息如果只是放在组件本地状态里一旦刷新页面或者通过URL分享就会全部丢失。好的做法是把这些参数尽量同步到URL的query string上。好处是刷新不丢状态、可以分享链接、可以方便做埋点统计。这个设计跟框架无关属于技能栈层面应该养成的习惯。第四个建议别忽略懒加载。后台管理系统早期页面少很多人不重视路由懒加载。等页面多了之后首屏加载时间会越来越长。在跨框架迁移时刚好是一个重新审视懒加载方案的机会。Vue Router里用() import()React里用React.lazy配合Suspense两个框架都有成熟的方案迁移时顺手把每个页面的按需加载梳理一遍你会发现首屏性能提升非常明显。最后一个建议也是我反复强调过的在所有迁移工作开始之前先花时间把所有业务逻辑抽成不依赖框架的纯函数和数据结构。这一步不会直接让你把某个页面迁移得更快但它会保证你迁移到一半时不会陷入“每个组件都要从头写”的泥潭。跨框架移植难度的大头从来不在语法差异而在你当初写代码时有没有把“稳定的东西”和“会变的东西”分开。这个意识建立起来了这次迁移的收益就不只是换了一个框架而是整个团队的技能栈都变得更标准化、更可携带了。
