企业官网建设流程全解析

1. 为什么我要用五种技术栈写同一套 Admin 系统

先说清楚这个项目到底在干什么。我手里有一套功能完全一致的 Admin 后台系统，包含登录鉴权、动态菜单、角色权限、数据表格、图表看板、表单增删改查这些标配模块，然后我用五种不同的技术栈把它分别实现了一遍：React + Ant Design、Vue3 + Element Plus、NestJS 全栈方案、Spring Boot + Vue 前后端分离、以及 Electron 打包的桌面端版本。做这件事的起因很朴素——团队里前后端人选型一直吵不出结果，有人说 React 生态大，有人说 Vue 上手快，有人说 NestJS 一套 TypeScript 打通前后端省心，还有人坚持 Spring Boot 稳。与其开会扯皮，不如我花时间把同一套业务逻辑在五种栈里都跑一遍，用真实代码量和踩坑记录说话。

这套 Admin 系统的业务场景我选的是最典型的“中后台管理系统”：左侧动态菜单、顶部面包屑、右侧内容区，核心页面包括用户管理、角色管理、权限配置、数据看板、系统日志。功能不复杂，但足够覆盖一个真实 Admin 项目 80% 的日常需求。之所以选 Admin 而不是别的，是因为 Admin 系统是前端工程化能力最集中的体现——路由、状态管理、权限控制、组件复用、构建优化，一个都跑不掉。

这篇文章适合谁看？如果你正在做技术选型、准备搭一个 Admin 脚手架、或者单纯想搞清楚 React 和 Vue 在真实项目里的差异到底在哪，那这篇内容应该能帮你省下不少自己试错的时间。我不会只贴代码，重点讲的是每个选择背后的理由、实际写下来哪里卡壳、以及五种方案各自的甜区和雷区。

2. 五种技术栈的选型逻辑与整体架构设计

2.1 为什么是这五种组合而不是别的

选这五种不是拍脑袋。React 和 Vue 是当下中后台最主流的两套前端框架，必须覆盖；NestJS 代表“全栈 TypeScript”路线，前后端共享类型定义，对中小团队吸引力很大；Spring Boot + Vue 是国内企业级项目最常见的组合，尤其是传统行业和政企项目；Electron 则是把 Web Admin 变成桌面应用的需求，很多内部工具都有这个诉求。

我刻意让五种方案的后端 API 契约保持一致——同一套 RESTful 接口规范，同样的字段命名、同样的分页结构、同样的错误码。这样前端部分的对比才是公平的，不会因为后端接口风格差异导致某个框架写起来更顺或更别扭。接口规范大致是这样：统一返回{ code, data, message }，分页统一{ list, total, page, pageSize }，鉴权用 JWT 放在 Header 里。

2.2 整体架构分层思路

五种方案我都遵循同一套分层逻辑，只是实现方式不同。最底层是数据层，用同一份 MySQL 表结构，用户表、角色表、菜单表、权限关联表，字段完全一致。往上是服务层，负责业务逻辑和鉴权校验。再往上是接口层，暴露 RESTful API。最上面是视图层，也就是 Admin 界面。

这样分层的好处是，当我在对比 React 和 Vue 时，下面三层是完全一样的，差异只集中在视图层和状态管理上，对比结论才干净。NestJS 方案里服务层和接口层合并成了 NestJS 的 Module + Controller + Service，Spring Boot 方案里则是标准的 Controller + Service + Mapper。

2.3 权限模型的设计取舍

Admin 系统绕不开权限。我采用的是经典的RBAC 模型：用户关联角色，角色关联菜单和操作权限。菜单权限控制左侧菜单显示哪些项，操作权限控制按钮级别的显隐。这里有个关键设计决策——权限校验放在前端还是后端？

我的做法是后端返回权限码列表，前端只做展示层控制，真正的拦截在后端。前端根据权限码决定菜单和按钮显隐，但每个接口后端都会再校验一次。很多人图省事只做前端控制，结果接口裸奔，这是 Admin 系统最常见的安全漏洞。五种方案我都坚持了这个原则，前端权限只是体验优化，后端权限才是安全底线。

动态菜单的实现上，React 和 Vue 都用后端返回的菜单树动态生成路由。React 用react-router的动态路由配合useRoutes，Vue 用router.addRoute动态注册。这两种方式思路一致，但 API 风格差异很大，后面会细说。

3. React 方案：生态最全但心智负担也最重

3.1 技术选型与目录结构

React 方案我用的是 React 18 + TypeScript + Vite + Ant Design 5 + Zustand + React Router 6。为什么选 Zustand 而不是 Redux？因为 Admin 系统的状态管理其实没那么复杂，主要是用户信息、权限列表、菜单树这几块全局状态，Zustand 的 API 简洁到几乎零样板代码，Redux Toolkit 虽然也简化了不少，但对这个体量来说还是重。Ant Design 5 的 CSS-in-JS 方案让主题定制方便很多，暗色模式切换几乎不用改代码。

目录结构我按功能模块划分：src/api放接口封装，src/store放 Zustand store，src/router放路由配置和守卫，src/layouts放布局组件，src/pages放页面，src/components放通用组件，src/utils放工具函数。这个结构在五种方案里基本保持一致，方便横向对比。

3.2 动态路由与权限守卫的实现

React Router 6 的动态路由实现是这套方案里最绕的部分。核心思路是：登录后拿到菜单树，把菜单树转换成路由配置数组，用useRoutes动态渲染。这里有个坑——useRoutes必须在组件内调用，而路由配置又依赖异步获取的菜单数据，所以需要一个 loading 状态过渡。

// 路由守卫核心逻辑 const router = useMemo(() => buildRoutes(menuTree), [menuTree]); const element = useRoutes(router); if (loading) return <Spin />; return element;

权限守卫我用了一个AuthGuard高阶组件包裹需要鉴权的路由，内部检查 token 和权限码。这里要注意的是，React 的守卫组件在路由切换时的执行时机和 Vue 的全局前置守卫不一样，React 是在渲染阶段判断，Vue 是在导航阶段拦截，这导致 React 方案里如果权限不足，页面会先渲染再跳转，有一瞬间的闪烁。解决办法是在守卫组件里先返回 null 或 loading，确认权限后再渲染子组件。

3.3 状态管理与数据请求的配合

Zustand 管理全局状态，但页面级的数据请求我用的是 SWR 的思路——每个页面自己请求自己的数据，不往全局 store 里塞。全局 store 只放用户信息、权限码、菜单树这些跨页面共享的东西。这个边界很重要，我见过太多项目把所有接口数据都塞 Redux，结果 store 臃肿得没法维护。

数据请求我封装了一个request函数，基于 fetch 做了统一拦截：自动带 token、统一错误处理、401 自动跳登录。这里有个细节，Ant Design 的 message 组件在 React 18 的严格模式下会有重复弹出的问题，需要在请求拦截里做去重处理，或者用 App 组件包裹整个应用来获得正确的 message 实例。

3.4 React 方案的实操心得

写下来最深的感受是：React 的自由度是双刃剑。路由、状态、请求、权限，每个环节都有多种方案可选，选型决策本身就消耗大量精力。比如动态路由，你可以用useRoutes，也可以用react-router-config，还可以自己写递归渲染。这种自由度对老手是优势，对新手就是灾难。

另一个坑是 Ant Design 5 的按需加载。Vite 下用unplugin-vue-components的 React 版本或者babel-plugin-import，配置不对会导致样式丢失或者打包体积暴涨。我实测下来，Ant Design 5 配合 Vite 的 tree-shaking 已经不错，不一定非要上按需加载插件，直接全量引入再靠 tree-shaking 优化，配置更简单，出问题概率更低。

4. Vue3 方案：上手最快但细节坑不少

4.1 技术选型与组合式 API 实践

Vue 方案我用的是 Vue3 + TypeScript + Vite + Element Plus + Pinia + Vue Router 4。Pinia 替代 Vuex 是必然选择，API 更简洁，TypeScript 支持更好。Element Plus 是国内 Admin 项目用得最多的组件库，表格和表单能力很强。

组合式 API 我采用的是<script setup>语法糖，这是目前 Vue3 最推荐的写法。但这里有个实际问题——团队里如果有习惯选项式 API 的老成员，混合开发会很痛苦。我的建议是 Admin 项目统一用组合式，因为逻辑复用（composables）在组合式下才真正好用。比如权限判断、表格分页、表单校验这些逻辑，抽成 composable 后在多个页面复用非常顺滑。

4.2 动态路由与权限控制的 Vue 式实现

Vue Router 的动态路由用addRoute实现，比 React 的方案直观很多。登录后拿到菜单树，递归转换成路由配置，然后逐个router.addRoute。全局前置守卫beforeEach里做权限判断，逻辑清晰。

router.beforeEach((to, from, next) => { if (!token && to.path !== '/login') return next('/login'); if (token && !userStore.menus.length) { const menus = await fetchMenus(); menus.forEach(m => router.addRoute(m)); return next({ ...to, replace: true }); } next(); });

这里有个经典坑：动态添加路由后，如果直接next()，当前导航可能匹配不到新加的路由，导致白屏。必须用next({ ...to, replace: true })重新触发一次导航。这个细节我踩过不止一次，网上很多教程都没提。

4.3 状态管理与组件通信

Pinia 的 store 定义很清爽，defineStore配合 setup 语法，和组合式 API 风格统一。用户信息、权限、菜单都放在userStore里，页面级数据还是各页面自己管。

组件通信上，Vue 的provide/inject在 Admin 布局里很好用，比如把当前主题、折叠状态往下传，避免层层 props。但要注意inject的响应性——如果 provide 的是 ref，inject 出来也是 ref，需要.value访问；如果 provide 的是 reactive 对象，直接访问属性即可。这个不一致性经常让新手困惑。

4.4 Vue 方案的实操心得

Vue 方案整体写下来比 React 快，尤其是模板语法对新手友好，v-if、v-for、v-model这些指令让页面代码很直观。但快不代表没坑。Element Plus 的表格组件在数据量大时性能一般，需要配合虚拟滚动；表单校验的触发时机需要仔细调，不然会出现“还没填就报错”的尴尬。

另一个感受是 Vue 的生态虽然丰富，但质量参差不齐。选第三方库时要看维护活跃度，我遇到过某个图表库半年没更新，Vue3 兼容有问题。相比之下 React 生态的库普遍更成熟，但 React 的 breaking change 也更频繁。这是个权衡。

5. NestJS 方案：全栈 TypeScript 的甜与苦

5.1 为什么选 NestJS 做全栈

NestJS 最大的卖点是前后端共享 TypeScript 类型。我在shared目录里定义了一套 DTO 和接口类型，前端直接 import 后端的类型定义，字段名写错编译期就报错。这个体验在 Spring Boot + Vue 方案里是没有的，那边前后端类型对齐全靠文档和自觉。

NestJS 的模块化设计也很适合 Admin 系统。用户模块、角色模块、菜单模块、鉴权模块各自独立，依赖注入让测试和替换很方便。我用 TypeORM 做 ORM，实体定义和数据库表一一对应，迁移脚本自动生成。

5.2 鉴权与权限的实现

NestJS 的 Guard 机制做鉴权非常优雅。我写了一个JwtAuthGuard做登录校验，一个PermissionGuard做权限码校验，配合自定义装饰器@RequirePermission('user:create')，在 Controller 方法上标注需要的权限，Guard 自动拦截。

@Post('user') @RequirePermission('user:create') createUser(@Body() dto: CreateUserDto) { return this.userService.create(dto); }

这套机制比在 Spring Boot 里写拦截器 + 注解要简洁，TypeScript 的类型推导让装饰器参数也有类型提示。但要注意 Guard 的执行顺序，全局 Guard 和局部 Guard 的优先级需要理清楚，不然会出现权限校验被跳过的情况。

5.3 前后端类型共享的实操细节

类型共享说起来美好，实操有几个坑。第一，后端实体和前端视图模型往往不完全一致，比如后端实体有password字段，前端绝对不能拿到，所以不能直接把实体类型给前端用，要单独定义响应 DTO。第二，TypeORM 的实体装饰器和前端类型定义混在一起会导致前端打包时引入后端依赖，必须用import type或者单独的shared包隔离。

我的做法是建一个 monorepo，packages/server放 NestJS，packages/web放前端，packages/shared放纯类型定义。shared 包里只有 interface 和 type，没有任何运行时依赖，前后端都能安全引用。

5.4 NestJS 方案的实操心得

NestJS 的学习曲线比 Express 陡，但比 Spring Boot 平缓。如果你熟悉 Angular 的依赖注入和装饰器，上手会很快。它的文档质量很高，但中文资料相对少，遇到问题搜英文更快。

性能上，NestJS 默认用 Express 作为底层，高并发场景可以切换到 Fastify。我实测下来，Admin 系统这种 IO 密集但并发不高的场景，Express 完全够用，没必要为了性能提前上 Fastify 增加复杂度。

6. Spring Boot + Vue 方案：企业级项目的稳妥选择

6.1 后端架构与安全配置

Spring Boot 方案我用的是 Spring Boot 3 + MyBatis-Plus + Spring Security + JWT。这是国内企业级项目最经典的组合。Spring Security 的配置是这套方案里最复杂的部分，过滤器链、认证管理器、权限表达式，配置项多且容易配错。

我采用的是无状态 JWT 方案，关闭 Session，每个请求带 token，过滤器解析 token 后设置 SecurityContext。权限校验用@PreAuthorize("hasAuthority('user:create')")注解。这里要注意 Spring Security 6 的配置方式和 5 有较大差异，很多老教程的代码直接跑不起来，WebSecurityConfigurerAdapter已经废弃，要用SecurityFilterChainBean 的方式配置。

6.2 前后端分离的接口规范

前后端分离最怕接口对不齐。我定了一套严格的接口规范：统一响应体、统一错误码、统一分页参数。后端用@RestControllerAdvice做全局异常处理，把业务异常转成统一格式返回。前端封装 axios 拦截器，统一处理错误提示和 401 跳转。

跨域问题上，开发环境用 Vite 的 proxy 代理，生产环境用 Nginx 反向代理，后端不配置 CORS。这样最干净，也最接近生产实际。

6.3 Vue 前端的对接要点

前端部分和纯 Vue 方案基本一致，差异在于接口调用的封装。Spring Boot 返回的时间格式默认是时间戳或者 ISO 格式，需要和前端约定好。我统一用 ISO 8601 字符串，前端用 dayjs 格式化。另外 Spring Boot 的 Long 类型在 JavaScript 里超过 2^53 会精度丢失，用户 ID 这种字段要么用 String 返回，要么配置 Jackson 序列化为字符串。

6.4 Spring Boot 方案的实操心得

这套方案最大的优势是稳。生态成熟，遇到问题几乎都能搜到答案，招人也容易。缺点是开发效率相对低，Java 的样板代码多，一个简单的 CRUD 要写 Controller、Service、ServiceImpl、Mapper、XML 好几层。MyBatis-Plus 能省掉不少，但整体还是比 NestJS 啰嗦。

启动速度也是硬伤，Spring Boot 项目启动动辄十几秒，改一行代码重启等半天。开发体验上确实不如 NestJS 的热重载流畅。但如果是团队协作、长期维护的企业项目，这些代价换来的是稳定性和可维护性，值不值取决于你的场景。

7. Electron 桌面端方案：把 Admin 装进客户端

7.1 为什么要把 Admin 做成桌面应用

有些 Admin 系统需要访问本地资源，比如读取本地文件、调用串口、连接本地打印机，这些在浏览器里做不到或者受限。Electron 把 Web Admin 打包成桌面应用，既能复用 Web 技术栈，又能获得本地能力。我做的这个 Electron 版本基于 Vue 方案，因为 Vue 的打包配置相对简单。

7.2 主进程与渲染进程的通信

Electron 的核心是主进程和渲染进程的 IPC 通信。主进程负责窗口管理、本地文件操作、系统调用，渲染进程就是我们的 Admin 界面。通信通过ipcMain和ipcRenderer，配合contextBridge暴露安全的 API。

// preload.js contextBridge.exposeInMainWorld('electronAPI', { readFile: (path) => ipcRenderer.invoke('read-file', path), print: (data) => ipcRenderer.invoke('print', data) });

这里有个安全原则：绝对不要在渲染进程直接开nodeIntegration，要用contextIsolation+preload的方式，只暴露必要的 API。很多教程图省事直接开 nodeIntegration，这是严重的安全隐患。

7.3 打包与自动更新

Electron 打包用 electron-builder，配置多平台构建。Windows 出 exe，macOS 出 dmg，Linux 出 AppImage。打包体积是个问题，一个简单的 Admin 应用打包出来动辄上百 MB，因为 Chromium 内核就那么大。优化手段有限，主要是压缩资源和排除无用依赖。

自动更新用 electron-updater，配合对象存储或者静态服务器放更新包。这里要注意签名问题，macOS 和 Windows 对未签名应用都有拦截，正式发布需要代码签名证书，这是笔额外成本。

7.4 Electron 方案的实操心得

Electron 开发最烦的是调试。渲染进程可以用 Chrome DevTools，但主进程的调试要靠日志或者 attach 到 Node 调试器，体验割裂。另外主进程和渲染进程的代码运行环境不同，同一个工具函数不能直接共用，要么各写一份，要么打包时分别处理。

启动白屏是 Electron 最常见的坑，原因通常是渲染进程加载失败或者 preload 脚本报错。排查方法是打开 DevTools 看控制台，或者在主进程里监听did-fail-load事件。我遇到过 preload 路径写错导致白屏，找了半天才发现是打包后路径变了。

8. 五种方案横向对比与常见问题排查

8.1 开发效率与代码量对比

我把五种方案的核心模块代码量做了统计，数据基于同一套业务功能：

数据仅供参考，但能看出几个趋势：NestJS 全栈因为类型共享，前后端联调成本最低，总耗时最少；Spring Boot 后端代码量明显偏多，主要是 Java 的样板代码；React 前端代码量略高于 Vue，主要是路由和状态管理的配置更繁琐。

8.2 常见问题速查表

8.3 独家避坑技巧

第一个技巧关于动态菜单的缓存。五种方案我都做了菜单缓存，登录后把菜单树存 localStorage，刷新页面先读缓存再后台更新。这样避免每次刷新都等接口返回才渲染菜单，体验好很多。但要注意缓存失效策略，权限变更后要能及时更新。

第二个技巧关于接口错误的统一处理。我在所有方案里都封装了统一的错误处理，但有个细节：网络错误和业务错误的提示要区分。网络错误提示“网络异常，请检查连接”，业务错误直接显示后端返回的 message。混在一起提示会让用户困惑。

第三个技巧关于主题切换。Admin 系统经常要支持暗色模式，Ant Design 5 和 Element Plus 都支持 CSS 变量主题。我的做法是把主题变量抽成一份配置，切换时改根元素的 class，CSS 变量自动生效。这样比用 JS 动态改样式性能好，也不会有闪烁。

9. 我的选型建议与真实体会

写了五遍同一套系统，最大的收获不是学会了五个技术栈，而是搞清楚了它们各自的边界。如果你让我给建议，我会这么说：团队小、追求开发效率、前后端都想用 TypeScript，选 NestJS 全栈；团队有 Java 背景、项目要长期维护、对稳定性要求高，选 Spring Boot + Vue；前端团队主导、需要丰富生态和组件库，React 和 Vue 都行，Vue 上手更快，React 生态更广；需要桌面端能力，Electron 是唯一现实选择。

但技术选型从来不是纯技术问题。我见过太多团队选了“最先进”的技术栈，结果因为招不到人或者成员不熟悉，项目拖了半年。也见过用“过时”技术栈稳稳当当交付的项目。工具是为人服务的，适合团队的才是最好的。

最后分享一个我踩过的坑：五种方案我都用了同一套 RBAC 权限模型，但在 React 方案里，因为动态路由的异步特性，权限校验的时机比 Vue 晚了一拍，导致某些边界情况下会出现权限闪烁。这个问题花了我整整一天才定位到，解决办法是在路由守卫里加一个同步的权限预检查。如果你也在做 React 的动态权限路由，这个细节值得注意。