前端圈子里有个很有意思的现象很多人觉得换框架就是一次大手术尤其是“从 React 换到 Vue”或者反过来听上去就像把房子的承重墙拆了重砌。但实际上如果你的技能栈是标准化的——组件化思想、状态管理、路由机制、副作用处理这些底层能力都成体系——跨框架移植更多是“换工具”而不是“换脑子”。我最近把一个中后台系统的路由模块从 React Router 迁移到了 Vue Router顺手把整套组件结构也做了平移。整个过程走完最大的感受是路由机制才是跨框架移植的命门搞懂了 URL、路由表、渲染出口这三者的关系框架差异就没那么吓人了。这篇内容我想从路由机制入手把标准化技能栈怎么在 React 和 Vue 之间“搬运”这件事讲透。包含完整的思路拆解、代码对照、踩坑记录适合写过至少一个框架、正准备接触另一个或者团队里技术栈混杂、想在多个框架间保持开发效率的人。不吹不黑全是实际操作中磨出来的东西。1. 标准化技能栈为什么能跨框架移植1.1 先搞清楚“标准化”到底标准化了什么很多开发者听说“标准化技能栈”第一个反应是“统一用某个框架全家桶”。这个理解不能说错但太窄了。真正的标准化指的是把那些不依赖具体框架、还能复用的能力和约定沉淀下来形成一套稳定的心智模型。具体的说有四个层面组件化思维UI 由独立、可组合的组件构成组件有输入Props和输出事件内部状态对外不可见。路由驱动视图URL 是应用状态的“单一事实来源”页面结构由路由表声明组件通过路由出口动态渲染。状态管理隔离全局共享状态独立于组件树通过单向数据流或受控更新来驱动视图刷新。副作用集中处理数据请求、缓存、埋点等副作用逻辑从组件生命周期中剥离放到统一层处理。这四个能力React 有Vue 也有Angular 有甚至小程序框架都在朝这个方向靠。换句话说你在一套框架里练出来的核心技能换个框架之后依然有效只是语法糖和调用方式变了。我之前带过一个项目前后端分离的中后台系统前端一开始用 React 写。后来公司要出面向 C 端的轻量版团队想换 Vue 来降低新人的上手成本。按很多人的直觉这等同于重写。但我们评估后发现真正要重写的是“表达方式”而不是“设计模式”。路由配置、状态模块、API 层、权限模型全都可以平移区别只在写法和 API 调用上。1.2 跨框架移植的真实场景跨框架移植不是一个偶尔发生的事实际上很常见大概有这几类团队裂变一个项目组分出两个团队一个继续维护 React 技术栈一个去做新项目但选型 Vue公共的业务逻辑和路由模型需要复用。技术栈收敛公司同时有多个老项目一部分是 React、一部分是 Vue想逐步统一但不允许一次性全量重写需要把核心机制规范化后在两边同步。个人能力迁移开发者换工作后新公司技术栈不同之前沉淀的通用技能如路由设计、权限模型、错误处理可以直接带过去用新框架重新表达一遍。我经历的这个项目属于第二种。当时手里有个运行了两年的 React SPA路由模块非常成熟嵌套路由、动态路由权限、面包屑自动生成、页面标题联动都是典型的中后台需求。迁移到 Vue 版本时我没有一个组件一个组件地硬搬而是先把“路由机制”这一个核心稳定点吃透其他东西跟着路由走自然就顺了。1.3 选择路由机制作为移植切入点的原因为什么是路由机制而不是组件库或者状态管理我的理由有三个第一路由是应用的骨架。页面怎么组织、菜单怎么映射、权限怎么拦截、刷新后 URL 自动对应到哪个页面这些都挂在路由上。骨架稳了皮肉组件怎么换都行。第二路由的抽象层级足够高不同框架的实现高度相似。React Router、Vue Router、Svelte Router 的底层逻辑都是“URL 与组件映射的动态切换”API 再多本质都一样。第三路由迁移最容易验证。迁移完路由打开页面、刷新、回退、前进、深链访问一套操作就能确认有没有搬对。相比状态管理的隐性 bug路由问题的暴露更直观。把这些想清楚之后我做了个决定先完全理解 React Router 在旧项目里承担的所有职责列成清单再去 Vue Router 里寻找对应能力。不匹配的能力重点标记最后一起解决。结果就是整个移植过程中的大多数坑都集中在“框架对路由机制的不同封装方式”上而不是业务逻辑本身。2. 路由机制内核拆解2.1 路由的本质是 URL 到视图的单向映射不管前端路由库怎么包装都要解决一个核心问题当浏览器地址栏 URL 变化时应用如何决定渲染哪个页面组件拆开看有三件事监听 URL 变化前端路由不能像传统 MPA 那样让浏览器发起完整请求而是要在不刷新页面的前提下感知 URL 的变化。解析 URL 并匹配路由记录拿到的 URL 字符串要与开发者声明的路由配置进行模式匹配拿到对应的路由记录路由记录里包含组件、参数、元信息等。变更视图把匹配到的组件渲染到页面指定区域同时处理路由参数、嵌套子路由的匹配结果。React Router 的内部实现会维护一条 history 堆栈Vue Router 的做法是创建一个响应式的路由状态对象。但它们做的事情是一样的用一套规则把“URL 的变化”翻译成“组件的切换”。用一个生活化的类比来解释把路由表想象成一本菜谱的目录URL 是你说出的菜名路由出口Outlet 或 router-view是你面前的餐盘。你说出菜名后厨路由匹配逻辑查目录、准备食材、炒菜然后把菜放到你的餐盘上。框架差异只在于后厨用的厨具不同但“点菜 — 查目录 — 上菜”这个过程是通用的。2.2 两种典型的 URL 模式hash 与 history前端路由最常见的两种模式名字和适用场景要搞清楚模式实现方式优点缺点适用场景Hash监听 URL 中 # 号后内容的变化不需要服务端配合URL 不美观有历史遗留痕迹静态托管、无服务端配置权限的环境History基于 History APIpushState、replaceState、popstateURL 简洁美观无 # 号刷新/deep link 时服务端必须配合回退到入口页正常前端项目、可配置服务端的环境我旧项目的 React Router 用的是createBrowserRouter也就是 history 模式。迁移到 Vue 时我用的是createWebHistory两者在同一种模式下工作URL 的表现形式完全一致。这里有个最容易踩的坑如果部署环境没配好history 模式刷新二级页面会直接 404。这个问题跟框架无关而是服务端需要把未知路由全部回退到入口页面。第一次部署 Vue 版本时我也忘了配结果被人拉过去救火一查才发现是 Nginx 少了一段try_files。2.3 路由表的数据结构与匹配算法路由表本质上是一个嵌套数组每个路由记录包含path路径、component组件、children子路由、meta元数据等字段。React Router 用的是RouteObjectVue Router 用的是RouteRecordRaw结构惊人的相似// React Router 的 RouteObject 简写 const routes [ { path: /dashboard, element: Dashboard /, children: [ { path: analytics, element: Analytics / }, { path: users, element: Users / } ] } ]// Vue Router 的 RouteRecordRaw 简写 const routes [ { path: /dashboard, component: Dashboard, children: [ { path: analytics, component: Analytics }, { path: users, component: Users } ] } ]差别很直观React 用element字段直接放 JSXVue 用component字段放组件的选项对象。匹配算法也很像按路径分段动态段用:id或$id之类的占位符表示匹配到的参数对象可以在组件里获取。React Router v6 用useParams拿参数Vue Router 用route.params拿参数目标是同一个东西。嵌套路由的匹配结果也遵循一致的逻辑父路由匹配后子路由的组件会渲染在父组件留下的“出口”位置。React 的出口是Outlet /Vue 的出口是router-view /。我当时就是按照这个对应关系把整套页面骨架平移过去的几乎没有遇到阻塞。3. 跨框架移植的整体设计3.1 移植前的任务清单拆解接到移植任务之后我做的第一件事不是写代码而是把旧项目的路由模块拆成一份“功能清单”贴在墙上看。这次用的清单长这样基础路由配置登录页、首页、错误页。嵌套路由主布局骨架作为父路由业务页面作为子路由。动态路由段详情页使用:id参数。路由守卫/拦截器未登录跳转登录页、权限不足跳转 403。路由元信息联动菜单高亮、面包屑生成、页面标题变更。懒加载与代码分割按路由动态加载页面组件。404 处理未匹配的路径统一兜底。清单列完之后对照 Vue Router 的 API 逐个找对应项。这个过程其实很快因为前面说过两大路由库的抽象层级高度一致。真正花时间的是那些“路由之外”的东西比如权限数据的初始化时机的差异、路由守卫里异步逻辑的处理方式。但这些也都可以通过标准化的设计消化掉。3.2 映射关系对照React Router 与 Vue Router 的对应为了方便实际操作我把 React Router 和 Vue Router 的对应关系做成了一个表格贴在项目的共享文档里。这里截取最重要的几项功能React RouterVue Router迁移注意点路由模式createBrowserRouter、createHashRoutercreateWebHistory、createWebHashHistory配对使用即可路由表声明RouteObject[]elementRouteRecordRaw[]componentJSX 换成组件对象路由出口Outlet /router-view /位置和嵌套逻辑相似导航跳转useNavigateuseRouter/router.push注意编程式导航的写法声明式链接Link torouter-link to写法差异不大动态参数useParamsroute.params参数命名规则一致路由守卫loader、route guard、useEffect模拟全局 / 路由级 / 组件内守卫是迁移中差异最大的部分懒加载React.lazy(() import(...))() import(...)函数式导入格式接近这张表看着简单但实际迁移时每个格子背后都有一堆细节。比如 React 的loader函数它在路由渲染前执行可用于数据预取或权限校验Vue Router 没有完全等价的东西但你可以使用全局前置守卫beforeEach来实现类似效果。区别在于执行时机和取消导航的能力这个我在下一节详细说。3.3 状态管理与副作用层的对应关系路由只是骨架真正让页面活起来的还有状态管理和副作用逻辑。标准化的技能栈里这两块也会跟着框架一起“换皮”。我在旧项目里用 Redux Toolkit 管理全局状态迁移时换成了 Pinia。从概念对照来看Redux Toolkit 的createSlice对应 Pinia 的defineStore一个管 Redux 的 reducer、action、selector一个管 state、getter、action。React 的useEffect对应 Vue 的watch或onMounted差别是 React 需要你关心依赖项和清理逻辑Vue 的watch会自动追踪响应式依赖但跨渲染层的“时序感”需要重新适应。React 的 Context 对应 Vue 的provide/inject用法不同但解决的问题一样跨层级共享数据避免一层层传 Props。状态管理迁移最容易出的问题是“思路没转过来”。Redux 里习惯写不可变更新到了 Pinia 觉得直接赋值也太爽了但爽的时候忘了 Pinia 同样有响应式原理的边界比如解构出来的状态不要直接改要用 store 上的 action 改。这类问题不在路由范围但确实会出现在整个移植周期里也值得留意。3.4 迁移顺序从路由到组件再到周边能力整个项目迁移我定的顺序是“路由骨架 → 页面容器 → 业务组件 → 状态模块 → 服务端通信层”。这个顺序保证每一步都可验证不至于到最后堆了几十个文件再排查。具体是这么走的路由骨架先行把路由配置结构搭好挂上占位组件确保任何 URL 都能正确渲染到对应的占位页面。页面容器跟进把每个路由对应的页面框架布局、数据加载、错误处理落地。业务组件平移这时候才开始动手改组件代码因为路由和页面骨架已经验证过组件的输入输出可以直接对接。状态模块对接把全局状态替换为 Pinia store替换组件里的取值逻辑。服务端通信层同步替换请求库的封装调整拦截器确保注入 token、错误码处理逻辑一致。每个阶段结束都做一次完整回归登录、进首页、下钻详情页、刷新、直接访问深链。五个阶段走完就大致有了一个可运行的 Vue 版本剩下的是细节调优。4. 实操过程一次完整的路由迁移实录4.1 从 React Router 到 Vue Router 的配置对照这一节把关键代码放上来对照着看会清晰很多。旧项目 React 的路由入口是这样// React Router v6 入口 import { createBrowserRouter, RouterProvider, Outlet } from react-router-dom const router createBrowserRouter([ { path: /, component: MainLayout /, children: [ { path: dashboard, element: DashboardPage /, meta: { title: 工作台, icon: DashboardOutlined } }, { path: projects/:id, element: ProjectDetailPage /, meta: { title: 项目详情 } } ] }, { path: /login, element: LoginPage / }, { path: *, element: NotFoundPage / } ]) function App() { return RouterProvider router{router} / }实际项目里Vue Router 的配置可以长这样// Vue Router 4 入口 import { createRouter, createWebHistory } from vue-router const routes [ { path: /, component: MainLayout, children: [ { path: dashboard, component: DashboardPage, meta: { title: 工作台, icon: DashboardOutlined } }, { path: projects/:id, component: ProjectDetailPage, meta: { title: 项目详情 } } ] }, { path: /login, component: LoginPage }, { path: /:pathMatch(.*)*, component: NotFoundPage } ] const router createRouter({ history: createWebHistory(), routes })注意最后一条 404 路由React 里用path: *就能通配Vue 4 里必须写/:pathMatch(.*)*如果写path: *会直接警告甚至失效。这是我移植时撞到的第一个动作级差异一搜就是一片开发者的血泪。这里已经把“标题差异”拉开到了实际执行层不理解这些差异就只是在抄代码换个场景马上抓瞎。4.2 嵌套路由出口与组件树的对齐嵌套路由的关键在于“出口”Outlet / router-view与子路由树的对应关系。React 写法function MainLayout() { return ( div classNamelayout SideMenu / div classNamecontent Outlet / /div /div ) }Vue 写法几乎是一一对应!-- MainLayout.vue -- template div classlayout SideMenu / div classcontent router-view / /div /div /template这里有一个比较隐蔽的坑如果你的子路由也嵌套路由比如/dashboard/analytics这种两级路径那么中间的父组件也要放一个router-view。否则子路由匹配到了但找不到渲染出口页面就白屏。排查这类问题时我有个习惯打开 Vue DevTools 看当前的route对象确认 path 是否正确匹配了路由记录再确认匹配到的matched数组里的每个组件是否都在对应层级提供了出口。React 侧排查逻辑一样只是看到的是 React DevTools 里的 Router 状态。这个出口逻辑一旦掌握嵌套路由怎么加深都不怕。4.3 动态路由参数与导航拦截的实现差异动态路由参数部分旧项目里从详情页跳转的代码// React const navigate useNavigate() const goDetail (id) navigate(/projects/${id}) // 获取参数 const { id } useParams()Vue 侧import { useRouter, useRoute } from vue-router const router useRouter() const route useRoute() const goDetail (id) router.push(/projects/${id}) // 获取参数在模板里直接写 $route.params.id在 script 里通过 route.params.id参数机制本身的差异很小但有个关于“监听参数变化”的细节值得单独说。在 React 里同一个组件/projects/1切换到/projects/2useParams会更新但组件的“旧渲染”不会自动刷新你得用useEffect监听参数变化再去拉数据useEffect(() { fetchProject(id) }, [id])Vue 里一个组件从/projects/1切换到/projects/2时组件默认实例是会被复用的onMounted不会再次触发。正确姿势是用watch监听路由参数watch(() route.params.id, (newId, oldId) { fetchProject(newId) })这类“框架时序”差异很多掌握了就能避开大量白屏或数据不刷新问题。我自己还总结了一个规律凡是 React 需要useEffect手动同步的地方Vue 往往有一个响应式机制让你“少干活”但代价是必须理解响应式的边界不然会在解构、异步更新上栽跟头。路由守卫是最能体现框架设计哲学差异的地方。旧项目的 React 版本用 v6 的loader做权限校验同时配合Navigate做重定向// React Router 的 loader 权限控制 { path: /dashboard, element: DashboardPage /, loader: async () { const user await getCurrentUser() if (!user) { return redirect(/login) } return { user } } }Vue 版本没有 loader 的等价物最常见做法是全局前置守卫router.beforeEach((to, from) { const user authStore.getUser() if (to.meta.requiresAuth !user) { return { path: /login, query: { redirect: to.fullPath } } } if (to.meta.roles !to.meta.roles.includes(user.role)) { return { path: /403 } } return true })两者都能实现“未登录去登录页没权限去 403”但有一个体验上的差异React 的loader是在路由匹配后、渲染前执行的且可以做到“加载完再进页面”Vue Router 的全局守卫则支持异步流程你可以await一个请求再决定放不放心前进。我用 Vue 全局守卫实现了旧项目 loader 的所有逻辑甚至能更好地展示加载进度条整体体验没有降级。4.4 懒加载与代码分割的落地懒加载这块差异不大都是把动态 import 交给路由记录。旧项目的 Reactconst DashboardPage React.lazy(() import(/pages/Dashboard))Vue 版const DashboardPage () import(/pages/Dashboard.vue)Vue Router 的动态导入不需要包一层lazy直接写函数返回 import 即可。打包工具会自动按路由记录拆分 chunk。注意点在于懒加载组件渲染前需要“加载中”态React 一般用Suspense包出口Vue Router 可以直接在组件外层用defineAsyncComponent或在路由出口外面包一层 loading 占位。我的做法是在布局组件里监听route.meta.pending之类的标记位来控制进度条。4.5 路由元信息的一体化设计中后台系统里路由元信息通常是业务粘合的关键层。菜单名、图标、权限标识、面包屑、页面标题、是否缓存都塞在meta字段里。React 和 Vue 都支持在路由记录上自定义字段这一点没什么障碍重点在于统一约定。我这次迁移里设定了一套 meta 规范meta: { title: 项目详情, icon: ProjectOutlined, permissions: [project:view], breadcrumb: [首页, 项目列表, 项目详情], keepAlive: false }页面标题的联动React 一般通过useEffect设置document.titleVue Router 有官方推荐的afterEach守卫处理router.afterEach((to) { document.title to.meta.title ? ${to.meta.title} - 某管理后台 : 某管理后台 })这种“用一套数据驱动两份 UI”的标准化设计让两个版本之间保持高度同步。后面如果菜单项要调整顺序、改权限、改标题只改路由配置就够了两边同步改同一份结构成本很低。4.6 权限模型在路由层如何落地关于权限我在第 4.3 简单提过守卫生的做法这里展开说明完整的权限模型。标准化的做法一般有两层静态路由登录页、错误页、公共页人人可访问。动态路由从后端拿到当前用户有权限访问的路由列表动态注册到路由实例上。React Router 里动态路由可以用useRoutes或重写整个 routes 数组再setRoutesVue Router 4 提供了router.addRoute和router.removeRoute而且使用 API 时不太直观如果你直接修改router.options.routes数组不会响应式更新。正确方式是调用 addRoute 后用nextTick再导航到目标地址等待路由重新解析。这里贴一段 Vue 侧动态路由的代码// 登录后拿到用户权限过滤出可用路由并注册 const initDynamicRoutes async (permissions) { const asyncRoutes generateRoutes(permissions) // 根据权限过滤出路由表 asyncRoutes.forEach(route router.addRoute(route)) // 重新导航一次确保动态添加的路由已经生效 return router.replace({ path: / }) }权限模型就是这么平移到 Vue 的。但要注意动态路由注册前的 404 逻辑要特殊处理。如果你一开始就在路由表里写了/:pathMatch(.*)*兜底动态路由注册后这个兜底规则会优先匹配吗答案是只要动态路由是在兜底之前注册就会优先匹配但如果先匹配到 404 再注册动态路由刷新后会失效。所以实际项目中我通常把兜底路由做成一个函数动态路由注册完再把真正的 404 加进去或者直接在守卫里做逻辑判断。5. 常见问题与排查技巧实录5.1 路由能跳转但页面空白这是我在移植后的第一周被反馈最多的问题基本都有固定套路。打开控制台看路由实例的currentRoute是否正常更新再确认目标路由组件是否真的被加载最后检查布局组件里有没有对应的router-view。有一回排查一个三级嵌套页面顶层有布局、中间层有 Tab 容器、底层是业务页面我发现中间层组件忘记写router-view /导致 URL 变了、路由记录匹配到了但组件渲染没有落点。壳子在肉没了。5.2 动态路由刷新后失效或 404这个问题几乎和动态路由权限模型同时出现。根因在于刷新页面时Vue Router 初始化只注册了静态路由而之前通过addRoute注册的路由记录全部丢了。解决思路是在应用初始化或路由守卫执行前先异步拿用户信息再根据权限把动态路由注册完成最后放行导航。我在项目里的做法是引入了一个“启动初始化”模块在main.js里先调用const bootstrap async () { await authStore.fetchUserInfo() if (authStore.isLoggedIn) { await initDynamicRoutes(authStore.permissions) } app.use(router) app.mount(#app) } bootstrap()这种方式保证了刷新后路由注册一定先于首次导航完成避免了“路由还没注册就去匹配”的竞态。5.3 参数变化但组件不更新这个问题在第 4.3 已经提过这里再补充一种容易误判的场景如果你在 Vue 组件里直接写const userId route.params.id然后组件模板绑定userId当同一组件切换到不同参数时userId不变因为route是响应式对象但你解构出来的常量不是响应式的。正确写法是用computed(() route.params.id)或者在模板里直接写route.params.id才能保持响应式追踪。React 侧同理const { id } useParams()每次渲染都能拿到新值但如果你把它缓存到一个 state 里并且忘了在 effect 中同步也会出现类似的问题。5.4 嵌套路由的父子组件数据依赖顺序这个问题的典型表现是父组件在onMounted里异步拿到某个数据然后想把它传给子路由的页面组件。但因为出口渲染是同步的父组件数据还没到子组件已经渲染了第一帧结果子组件拿到的 Props 是空的。针对这个问题我的方式是使用路由元信息做“数据就绪”标记。父组件拿到数据后先更新 meta子组件 watch meta 变化再拉取自己的数据或者干脆在父组件里用 v-if 控制 router-view 的渲染。React 里对应的做法是条件渲染Outlet /在 loader 或组件里等数据齐了再渲染出口。注意这里不要用nextTick去碰运气因为异步数据的时间点你用肉眼是估不准的。5.5 路由守卫在循环依赖或无限重定向中打转Vue Router 的守卫如果返回值不断指向同一个地址会触发无限重定向。比如router.beforeEach((to) { if (!isLogin() to.path ! /login) return /login if (isLogin() to.path /login) return /dashboard })逻辑看似没问题但如果isLogin()的状态是异步获取的第一次执行时状态还没初始化从一个页面跳到另一个页面守卫反复执行就可能来回跳。这种问题很恶心因为它不一定每次复现。我解决的方式很简单加一个“初始化完成”的全局状态。只有初始化完成后守卫里才做重定向判断。初始化期间直接放行或进入等待页。这个模式在两个框架里都适用而且在 React Router 里可以放在 loader 里做体验更平滑。5.6 打包后 chunk 文件缺失或路径错误懒加载路由打包后访问某个页面 404多半是打包路径问题。Vue CLI 或 Vite 配置的base路径、React 的basename都要和服务端部署路径匹配。之前用 React 时basename配的是/admin/迁移到 Vue 后createWebHistory(import.meta.env.BASE_URL)要和 Vite 的base配置一致否则生产环境刷新就白屏。这个问题跨框架都存在属于部署层面的标准坑放这里提醒一下。6. 我对跨框架移植的三点体会与一条避坑清单最近这轮迁移收尾后我自己复盘了整个过程发现很多东西如果早一点想明白能省掉大量试错时间。这里分享几点算是给同样要做跨框架移植的人一些参考。第一把路由机制当成“基线”。在你的旧代码里先画出路由图理清 URL、菜单、权限、组件树四者的映射再动手写新框架代码。不要把注意力耗在语法迁移上否则你会被个别差异磨死。只要路由模型对齐了页面导航、权限拦截、面包屑这些联动就都能顺藤摸瓜。第二状态管理和副作用层要早做对应规划。我因为没有提前规定“哪个 React Hook 对应 Vue 的哪个 API”中途不断回去翻源码很费时间。做一张 React / Vue 生命周期对照表贴在项目文档首页会省很多事。第三不要放过任何“看起来很简单”的差异。404 通配写法的不同、懒加载包装方式的不同、守卫执行时机的不同都值得先验证一次再大规模复制。这些小差异不是框架的缺陷而是各自设计取舍的体现。理解了取舍你才真正拥有了标准化的技能栈而不是只会抄 API。最后附上一条避坑清单是我这次移植时踩过或见过的坑的浓缩路由表里不要直接写业务逻辑保持纯粹的声明式。动态路由注册后务必处理刷新时的恢复流程。懒加载组件要配套加载中态不要让用户看着白屏发呆。守卫里的异步逻辑必须在初始化完成后才执行导航判断。参数监听用框架最推荐的响应式方式不要解构常量。部署环境记得把 history 模式的服务端回退配好。跨框架移植的尽头不是“把代码翻译一遍”而是把底层的设计模式内化成自己的思维方式。路由机制、状态模型、生命周期调度这些内核在不同框架里来回穿梭之后你会发现写 React 和写 Vue 的区别越来越小——都是拿合适的表达方式把已经想清楚的业务逻辑呈现出来。希望这篇内容能帮你少踩几个坑早点体会到这种感觉。