ELAdmin 前后端分离权限管理系统 v2.7：代码生成器一键出前后端

中后台项目最容易低估的工作量，不在业务页面，而在业务之前那套底子。菜单要分树、按钮要分权限标识、数据要按部门分范围；登录态要能踢人、要能查在线用户；操作日志、异常日志、定时任务、字典、岗位、部门——这些东西跟你的业务一点关系没有，但每接一个新项目就得重写一遍。真从零写，一个熟练的后端也要两三天才能把骨架立住，还没算前端那套动态路由与权限指令。

ELAdmin 就是把这套底子做完了的工程。它是一套前后端分离的权限管理系统：后端 Spring Boot 2.6.4 + Spring Data JPA + Spring Security + Redis + MySQL，前端 Vue 2 + Element-UI，Apache-2.0 协议，二次开发、商用、闭源发布都可以。功能面上，用户 / 角色 / 菜单 / 部门 / 岗位 / 字典六类基础管理、菜单级动态权限与按钮级权限标识、按部门的数据权限、JWT 鉴权加图形验证码、在线用户踢出、操作日志与异常日志、Quartz 定时任务、代码生成器、服务器监控与数据库管理都内置了。我在包内逐层数了一遍：后端 308 个源码文件里，REST 接口层 30 个控制器、22 个 JPA 实体；前端 283 个源码文件里，58 个 .vue 业务页面。这不是一个只有骨架的 demo。

我在 Windows 11 上把它从源码到运行完整跑了一遍，下面所有数字都来自当次运行的日志：后端 mvn clean package 总耗时 3 分 00 秒，BUILD SUCCESS，产出 eladmin-system-2.7.jar 共 131,906,555 字节（约 125.8MB）；前端 npm install 装下 2142 个包，npm run build:prod 耗时 19.59 秒，dist 目录 64 个文件共 6,695,154 字节（约 6.4MB）；后端从进程启动到 Started AppRun 是 10.287 秒，监听 8000 端口，GET /auth/code 返回 HTTP 200 和一张验证码。登录之后我把 8 个页面逐页截了图，网络请求 0 个 4xx / 5xx，控制台 0 个 JS 报错。结论先说：它适合要在一个成熟权限骨架上做二次开发的企业内部系统，也适合拿它当 Spring Boot 加 Vue 分层写法的参考工程；但它不是开箱即用的成品软件，需要你自己准备 JDK 8、MySQL、Redis 三样运行环境，而且前端技术栈压在 Vue 2 上，新项目如果一定要 Vue 3，适配成本得自己算——这两条我在后面单列。

ELAdmin 是什么

一句话：一套已经写好的中后台权限底座，前后端分离，后端管数据与鉴权，前端管动态菜单与页面。

• 项目名：ELAdmin，本次收录版本 v2.7
• 协议：Apache License 2.0，二次开发、商用、闭源发布都可以
• 后端：Spring Boot 2.6.4，Spring Data JPA + Hibernate 5.6.5，Spring Security，内嵌 Tomcat 9.0.58，Druid 连接池，Quartz 2.3.2
• 前端：Vue 2 + Element-UI，Vue CLI 生产构建
• 数据：MySQL 8.0（兼容 5.7 及以上），字符集 utf8mb4；缓存用 Redis
• 运行环境：JDK 8（工程按 Java 8 编译），Node.js 16 及以上用于前端构建
• 代码规模：后端 308 个源码文件（30 个 REST 控制器 / 22 个 JPA 实体），前端 283 个源码文件（58 个 .vue 页面）

功能模块按用途分一遍：

• 权限体系：用户、角色、菜单、部门、岗位、字典六类管理，菜单支持树形结构与按钮级权限标识
• 数据权限：按部门维度控制数据可见范围，不是只做接口鉴权
• 鉴权链路：JWT 令牌加图形验证码（算术题），密码经 RSA 公钥加密后传输
• 在线用户：登录态写进 Redis，可以在后台直接把某个用户踢下线
• 日志：操作日志、异常日志、慢 SQL 记录
• 定时任务：Quartz 调度，支持 Cron 表达式与执行记录
• 代码生成：连数据库读表结构，一键生成前后端代码，支持在线预览与下载
• 运维：服务器信息、应用部署、部署历史、数据库管理
• 工具集：邮件发送、本地与云存储、支付配置、接口文档

值得单独说的是代码生成器。它不是生成一个 CRUD 壳子，而是按工程既有的分层写出实体、Service、Controller 和前端页面，字段类型、查询条件、表单控件都能在生成前逐项调整。做企业内部系统的团队最枯燥的那部分工作量，基本被这一块摊平了。

它和其他后台框架差在哪

国内常见的同类工程有几个，分工其实挺清楚：

• 若依（RuoYi）：同样是权限管理底座，数据访问以 MyBatis 为主，风格偏「代码生成 + 传统分层」，国内资料最多
• gin-vue-admin、go-admin：Go 语言那一侧的同类产品，胜在单二进制部署，但生态与 Java 企业环境不通用
• vue-element-admin：纯前端模板，只有页面与路由，没有后端、没有数据库、没有真权限，它是界面参考，不是系统
• ELAdmin：Java 侧的前后端分离方案，数据访问用 JPA 而不是 MyBatis，权限一直做到数据权限那一层

差别主要在两点。一是 ORM 选型：ELAdmin 全程 JPA + Hibernate，实体上直接写注解，不写 XML 映射文件；习惯 MyBatis 的人第一次看会觉得少了点什么，但改字段的时候确实更省事。二是它把数据权限与运维管理这两块也做进了主线——很多同类工程只做到接口鉴权，数据可见范围要自己补。

如果你的团队已经在 MyBatis 上有一堆积累，那换到 JPA 的迁移成本是真实存在的，别被「都是 Spring Boot」骗过去。

我的测试环境

• 系统：Windows 11，单机同时跑 MySQL 与 Redis
• JDK：Temurin 1.8.0_504（工程要求 Java 8）
• Node.js：24.16.0 / npm 11.13.0
• 数据库：MySQL 8.0，库名 eladmin，导入包内 sql/eladmin.sql
• 缓存：Redis 5.0.10，本次实测跑在 127.0.0.1:6378
• 后端端口：8000，上下文路径为空
• 前端端口：开发态 8013
• 截图：桌面 1400 像素宽 6 张、移动 390 像素宽 2 倍图 2 张，共 8 张
• 未验证项：没有做集群部署与压力测试，性能数字都来自单机冷启动

后端：构建与启动

包里已经放了构建好的 jar，只想立刻看效果可以跳过构建；但从源码走一遍只要 3 分钟，建议还是走，出问题时你知道每个模块在哪。

cd 后端源码
mvn clean package -DskipTests

这条命令实测跑完是 BUILD SUCCESS，Total time 03:00 min。产物在 eladmin-system/target/ 下，主包 eladmin-system-2.7.jar 是 131,906,555 字节。

启动时数据库与 Redis 的连接参数不走写死的配置文件，而是用 -D 传进去，同一份 jar 就能换环境复用：

java -DDB_HOST=127.0.0.1 -DDB_PORT=3306 -DDB_NAME=eladmin \
     -DDB_USER=root -DDB_PWD=你的数据库密码 \
     -DREDIS_HOST=127.0.0.1 -DREDIS_PORT=6379 \
     -Xms256m -Xmx1024m -jar eladmin-system-2.7.jar

有两个默认值要留意：数据源默认账号与密码都是 root，Redis 默认端口 6379。它们跟你的环境不一致时必须用 -D 覆盖，键名就是 DB_USER、DB_PWD、REDIS_PORT 这几个。

启动成功的判据很简单：日志里出现 Started AppRun，并且访问 /auth/code 能拿到带 uuid 与验证码图片的 JSON。我这边这条接口返回 HTTP 200，从进程起来到这一句日志是 10.287 秒。

前端：先改接口地址，再构建

前端最容易出错的一步在构建之前。工程根目录有个 .env.production，源码里默认的接口地址指向项目方自己的演示域名——你不改它，构建出来的页面会去连别人的服务器，表现就是「页面能打开，但登录没反应、接口全 404」。

ENV = 'production'
VUE_APP_BASE_API  = 'http://127.0.0.1:8000'
VUE_APP_WS_API   = 'ws://127.0.0.1:8000'

改完再装依赖、构建：

cd 前端源码
npm install
npm run build:prod

npm install 实测装下 2142 个包，耗时约 2 分钟；build:prod 耗时 19.59 秒，产出 dist 目录 64 个文件，合计 6,695,154 字节。构建过程报 3 条告警：xlsx 库的默认导出告警 1 条，其余 2 条是打包体积超限，都不影响运行。

包里也直接给了构建好的 dist。若只是想先看看界面，把它交给任意静态服务器就能打开，不必自己重新构建；但那份 dist 是按项目方演示地址构建的，你改了后端地址就必须自己重新构建一次。

数据库初始化与首次登录

先建库：

CREATE DATABASE eladmin DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

再导入脚本，sql/eladmin.sql 里包含建表语句与初始数据，管理员账号、菜单、角色都在里面：

mysql -uroot -p eladmin < 后端源码/sql/eladmin.sql

按需再导入 sql/tool_picture.sql 补充图片相关表。初始管理员账号是 admin，初始密码 123456，首次登录后建议立刻在个人中心改掉。

实测数据

• 后端构建：mvn clean package -DskipTests，BUILD SUCCESS，总耗时 3 分 00 秒
• 后端产物：eladmin-system-2.7.jar 131,906,555 字节（约 125.8MB）
• 后端启动：到 Started AppRun 10.287 秒，监听 8000 端口
• 健康检查：GET /auth/code 返回 HTTP 200，响应体含 uuid 与验证码图片
• 前端依赖：npm install 装下 2142 个包，约 2 分钟
• 前端构建：npm run build:prod 耗时 19.59 秒，3 条告警
• 前端产物：dist 64 个文件，6,695,154 字节（约 6.4MB）
• 页面实测：8 个页面全部正常渲染，网络请求 0 个 4xx / 5xx，控制台 0 个 JS 报错，整轮截图 33.81 秒
• 代码规模：后端源码 308 文件 / 30 个 REST 控制器 / 22 个 JPA 实体；前端源码 283 文件 / 58 个 .vue 页面
• 成品包：122,899,705 字节（117.21MB），661 个条目，解压后 140,995,858 字节
• 包内预构建产物：jar 与前端 dist 都在，jar 实测可直接启动，到 Started AppRun 11.611 秒，/auth/code 返回 200

跨平台这条要说明白：本次实测是在 Windows 11 单机上完成的，没有在 Linux 上重复跑一遍。jar 是 Java 字节码，跨平台本身不是问题，但前端构建与 MySQL、Redis 的服务端配置在你的 Linux 机器上仍需要自己走一遍。

界面长什么样

登录页是验证码加账号密码两步，验证码是一道算术题而不是扭曲字母，识别压力小很多：

首页仪表盘放的是实时数据卡片与图表区，左手边是完整的菜单树，权限层级一眼能看出来：

用户管理页是这套系统最典型的一页：左侧部门树筛人，右侧列表带角色、部门、状态与操作列，顶部是搜索与新增：

角色管理页管的是权限分配的入口，每个角色后面挂着菜单权限与数据范围：

代码生成页是最值得看的一页。顶部选表，中间是字段配置，右侧直接给出生成代码的预览，改完可以下载：

服务监控页展示应用运行状态——CPU、内存、磁盘、JVM 堆与非堆，以及缓存信息：

移动端视口下的同一套界面

把视口压到 390 宽、2 倍像素比重新截一遍，能看出后台在手机上的实际观感。登录页是自适应的，输入框撑满宽度：

仪表盘在窄屏下卡片改为纵向堆叠，图表区随宽度收缩，左侧菜单收进抽屉：

需要提醒的是：这套前端是管理后台，做了基础响应式但没做移动端专项优化，表格类页面在手机上仍要靠横向滚动，别指望它像专门的移动端应用那样好用。

一个真实的坑：Node 17 以上构建会报 OpenSSL 错误

这个坑我实际踩到了。前端工程用的是 Vue CLI 4 时代的 webpack 4，它的哈希计算依赖 Node 旧版的 OpenSSL 提供方式；Node.js 17 之后 OpenSSL 3 默认禁用了那套旧算法，于是构建阶段直接抛错，报错原文的关键字是 error:0308010C:digital envelope routines::unsupported，栈顶指向 webpack 的哈希创建。

我在 Node.js 24 上遇到的就是这个。解决办法是给构建过程加一个兼容开关：

$env:NODE_OPTIONS = "--openssl-legacy-provider --max-old-space-size=4096"
npm run build:prod

Linux 与 macOS 下写法一样，只是换成 export NODE_OPTIONS。加上之后构建一次通过，就是前面那 19.59 秒的记录。

两个提醒。第一，这个开关只对构建过程生效，不要写进系统环境变量常驻——它是降级到旧算法的开关，没有正当理由不该全局挂着。第二，--max-old-space-size=4096 不是必需的，但 webpack 4 打 Element-UI 这种体量的项目时堆容易顶到上限，给到 4G 更稳。

另一个同样常见的坑：npm install 阶段如果报依赖树冲突，加 --legacy-peer-deps 可以绕过。这份工程的依赖锁在 Vue 2 时代的版本区间上，新版 npm 的 peer 校验比当年严格得多。

部署到服务器的三条注意

部署本身不复杂，就是静态文件加反向代理，但有几处容易返工。

第一，前端 .env.production 里的接口地址要和你的部署方式匹配。如果用 Nginx 把前后端放在同一个域名下，把 VUE_APP_BASE_API 配成 /（相对路径），由 Nginx 转发给后端。参考写法：

location / {
    root   /path/to/dist;
    index  index.html;
    try_files $uri $uri/ /index.html;
}

location /auth { proxy_pass http://127.0.0.1:8000; }
location /api  { proxy_pass http://127.0.0.1:8000; }

try_files 那一行不能省。前端是单页应用，直接刷新 /system/user 这类路由时服务器上并没有对应的物理文件，不 fallback 就会 404。

第二，改了接口地址就必须重新构建前端。dist 是编译产物，接口地址在构建时就被写进 JS 里了，只改配置不重新构建没有任何效果。

第三，后端 jar 的启动参数记得带上 -Xmx。默认堆对 125MB 的包来说偏小，-Xms256m -Xmx1024m 是包内说明给出的取值，够单机用。

这几类人适合，这几类不适合

适合：

• 要做企业内部管理系统，需要一套现成的用户、角色、菜单与数据权限底座
• 团队技术栈是 Java 加 Vue 2，能直接接手往上叠业务模块
• 需要代码生成器来摊平大量重复的 CRUD 页面
• 想把「菜单级权限 + 按钮级权限标识 + 数据权限」三层结构拿来当参考实现
• 需要一个带定时任务、日志、在线用户、服务器监控的完整运维后台

不适合：

• 想要开箱即用的成品软件。它是工程骨架，不是装上就能用的产品，JDK 8、MySQL、Redis 三样环境得自己准备
• 技术栈已经定在 Vue 3 加 Vite 上。前端是 Vue 2 + Element-UI + Vue CLI，迁到 Vue 3 不是改几行的事
• 团队重度依赖 MyBatis。数据访问层是 JPA + Hibernate，换 ORM 的成本要提前算
• 只想找一个纯前端后台模板。那有更轻的选择，不需要拖一整个 Java 后端
• 需要微服务或分布式架构。它是单体多模块工程，横向拆分要自己做

常见问题

源码获取

建议先转存到自己网盘再下载。手机上打开链接点右下角「保存到网盘」，回头在夸克 App 的「我的网盘」里下。