简介这是一套基于Jeecg-Boot深度定制的企业级低代码开发平台——Nbcio-Boot源码包面向中小企业IT实施人员、Java后端开发者及流程数字化转型实践者旨在解决OA/ERP类管理系统快速构建难题显著降低工作流定制与业务集成开发成本。资源共1388个文件含624个Java核心业务与流程引擎模块代码、168个bcmap字体映射文件支撑多语言界面渲染、146个PNG图标资源、94个XML配置与Flowable流程定义文件、40个Vue组件及36个JSON接口规范文件整体压缩包仅31.8MB结构清晰、模块解耦度高。已有73人下载学习适合Spring BootFlowable技术栈进阶实践。读者可直接获取开箱即用的钉钉薪资审批流程示例、ERP风格表格选择器、实时在线聊天模块及MySQL/Oracle/SQL Server多数据库适配方案无需从零搭建基础框架大幅缩短企业级系统原型验证周期。 我在企业级低代码开发这块折腾了不少年从早期的代码生成器到后来的各种快速开发平台Jeecg-Boot算是我用得最顺、也最愿意内推给出项目组的一套方案。最近刚好接手了一套基于Jeecg-Boot封装的企业管理平台源码带在线演示打包成rar分发给内部团队做技术调研。借着这个机会我把整个平台的架构逻辑、部署过程、二次开发路径以及我自己踩过的坑整理成一篇完整笔记既是对这套系统的复盘也方便后续接手的新人少走弯路。如果你正准备选型或者打算基于Jeecg-Boot做企业内部管理系统这篇内容应该能帮你省下不少时间。1. 项目整体设计与思路拆解1.1 为什么选择Jeecg-Boot作为基座企业管理系统的核心矛盾从来不是某个页面写不写得出来而是业务模块多、权限模型复杂、交付周期极短。从零开发一套带组织架构、用户角色、菜单权限、数据字典、流程审批的后台光基础架构就要投入一到两个月。而Jeecg-Boot这类低代码平台把企业管理后台的共性需求事先沉淀成了现成的工程骨架我们能直接在此基础上做业务层的二次开发。这套企业平台选择Jeecg-Boot本质上是做了一个取舍用一部分定制化自由度换取极高的项目启动速度和稳定的基础能力。尤其对于企业内部的OA、CRM、进销存这类业态Jeecg-Boot的在线表单和代码生成器能覆盖绝大多数常规增删改查页面而通过自定义按钮、自定义SQL、扩展JAVA服务又能兜底那些非标业务逻辑。从我接到这套源码的实际情况来看交付包里的内容和标准Jeecg-Boot发行版有明显差异多了一套统一门户、若干个业务子模块的样例配置以及预先调整过的前端主题。这说明它不是在原始框架上直接晒源码而是真的经过了一定程度的业务沉淀再封装起来作为团队内部的项目脚手架来复用。1.2 在线演示与源码下载的定位思考配套提供在线演示和源码下载这个设计很有讲究。在线演示解决的是决策层的信任问题业务方不需要理解Spring Boot或Vue他们只需要点开一个URL看到系统里已经有组织树、角色权限、流程审批就能直观判断这套东西适不适合自家业务。源码下载解决的则是开发层的落地问题。演示环境只能证明平台能跑起来但真正的交付价值在于工程本身。拿到源码后团队可以本地编译、运行、打断点排查、改造业务逻辑。我在实际调研中一般先把在线演示的菜单全部点一遍弄清楚哪些是平台自带能力哪些是样例业务再拉源码在本地跑通对照着看几个关键模块的代码实现。这种组合对于技术选型非常高效。一个开源或半开源项目如果连演示站点都没有只能靠文档脑补界面长什么样如果只有演示没有源码又很难判断代码质量和扩展性。两个都有基本上能在一两天内做出相对靠谱的技术判断。1.3 不同角色的使用视角这套平台面向的人群其实可以分成三类。第一类是项目经理或技术负责人他们主要看演示系统里的功能完整度和权限模型关注的是这个平台能覆盖哪些业务场景二次开发的工量有多大。第二类是后端工程师他们关注的是Jeecg-Boot的代码结构、数据库表设计、在线表单的配置逻辑以及系统能不能顺利在本地跑起来。第三类是前端工程师他们关心的是Vue工程的目录结构、页面如何与后端交互、报表和表单组件如何复用。在文章后面我会分别从这三个视角展开。整个讲解思路会围绕一套真实的部署和开发链路来走从拉源码到本地启动再从建一张业务表到生成一套可用的管理页面最后再聊几个我实际遇到的典型故障。2. Jeecg-Boot核心架构与关键能力解析2.1 基础技术栈选型分析Jeecg-Boot的技术栈选择是比较经典的企业级组合。后端基于Spring Boot 2.x内置了MyBatis-Plus作为ORM框架权限认证使用Apache Shiro JWT工作流模块则集成了Flowable引擎。前端基于Vue 2.x和Ant Design Vue组件库构建工具用的是Webpack。这个组合的成熟度很高团队成员招聘时不需要特殊技能只要熟悉主流Java和前端技术栈就能快速上手。数据库方面Jeecg-Boot默认支持MySQL、Oracle、PostgreSQL、SQL Server等主流关系型数据库实际项目中一般用MySQL最常见。缓存由Redis承担用来存Token、字典数据、在线用户信息等。Sys_user、sys_role、sys_permission这三张核心表支撑了RBAC权限模型sys_user_role和sys_role_permission作为关联表。这种五表模型是业界最成熟的权限设计方案和Spring Security体系的权限模型思路一致只是Jeecg-Boot用Shiro实现了同样的效果。在这个基础上Jeecg-Boot还增加了数据权限的配置能力可以在Controller层根据当前登录人的部门或角色自动拼接数据过滤条件。2.2 在线表单与代码生成器的底层逻辑在线表单是Jeecg-Boot最核心的生产力工具。它的底层逻辑是在界面上配置字段类型、校验规则、控件类型然后根据这些配置自动生成数据库字段和对应的前端表单组件。这样业务人员可以直接在系统里维护表单结构不需要写代码就能建立一张业务表。代码生成器则更进一步它能根据已有数据库表反向生成一套完整的前后端代码。后端生成Controller、Entity、Mapper、Service前端生成列表页面、表单页面、接口调用文件。生成出来的代码是基于模板的如果项目里有统一风格的基础模板生成的代码可以直接进代码仓库再手工做一些定制修改。这套模式解决的真正问题是企业管理系统中约有六到七成的模块是单表或简单主子表的增删改查这类模块的代码几乎高度相似。人工写这些代码费时且容易出错代码生成器能保证统一规范让团队把宝贵的精力集中在真正复杂的业务逻辑上。2.3 多租户与数据权限能力企业管理平台经常面临一个情况同一个系统要支撑多个独立的分公司、部门或外部客户使用。Jeecg-Boot的多租户方案是通过在业务表中增加tenant_id字段基于MyBatis-Plus的拦截器在SQL执行时自动追加租户过滤条件来实现的。这比在业务代码里到处手动拼接条件要友好得多能有效防止漏加条件导致的数据越权。实现多租户的关键配置在MyBatis-Plus的配置拦截器中。在系统管理里创建租户后用户登录时会绑定租户ID后续所有请求在操作数据时TenantLineInnerInterceptor会自动改写SQL语句追加tenant_id x的条件。这样业务代码里根本不需要感知多租户的存在只需要在表设计时预留好字段即可。数据权限和租户权限是两个维度。租户权限管的是“这个用户属于哪个租户”数据权限管的是“这个用户在当前租户内能看到哪些范围的数据”。Jeecg-Boot支持按本人、本部门、本部门及以下、全部数据四种数据范围通过配置规则系统会在查询时自动追加部门ID的过滤条件。这个能力在实际业务中非常实用各个部门只能看到自己范围内的数据既保证业务独立又减少了人为误操作的风险。3. 从演示环境到本地部署的完整实操3.1 环境准备与版本兼容性说明先把环境要求说清楚。Jeecg-Boot 3.x版本需要JDK 8及以上Maven 3.6以上Node.js 10以上建议用14或16Redis 3.2以上MySQL 5.7以上。我在实际部署过程中最常用的组合是JDK 8 MySQL 5.7 Redis 6.x Node 14这套组合最稳定踩坑最少。JDK版本建议直接用8虽然11和17也能跑但有些老依赖在更高版本上会有编译或运行时问题没必要给自己找麻烦。MySQL建议用5.7表结构默认是utf8mb4字符集如果数据库服务端的字符集设置不对导入SQL时会出现乱码或索引过长的报错这一点我在后面故障排查部分会详细说。Redis是登录授权和数据缓存所必需的启动前一定要确认Redis服务可用。如果本机没有RedisWindows系统可以直接下载Windows版Redis解压运行Linux环境用yum或apt安装即可。测试环境不在意安全性的话配置完密码后要确保应用服务能通过网络访问到Redis端口。3.2 源码获取与目录结构解读拿到rar压缩包后第一步是解压注意解压路径不要带中文和空格。解压后你会看到标准的Maven工程结构顶层目录下一般有两个核心Maven模块jeecg-boot-base-core是基础核心模块封装了系统通用能力jeecg-module-system是系统管理模块包含用户、角色、菜单等管理功能。前端工程通常是独立的目录Vue项目结构比较标准src/api目录放接口调用文件src/views目录放页面组件src/router目录配置路由。如果这套源码是经过改造的通常会比原生Jeecg-Boot多出business或modules这类业务模块目录放在里面的就是该企业平台自身的业务代码。拿到源码后我建议你先看pom.xml中的模块依赖关系判断系统集成度再看application-dev.yml中的配置项确认数据库、Redis、文件存储等外部依赖的接入方式。把这些摸清楚本地启动的成功率能大幅提升。3.3 数据库初始化与配置文件修改Jeecg-Boot的初始化SQL文件一般放在db目录下文件名类似jeecg_3.6.0.sql用Navicat或命令行工具导入。如果你的MySQL是5.7版本直接导入通常没有问题。导入后需要修改后端配置。在jeecg-module-system的resources目录下找到application-dev.yml主要检查三处数据库用户名密码、Redis地址端口密码、文件上传的存储路径。例如数据库配置示例spring: datasource: dynamic: datasource: master: url: jdbc:mysql://127.0.0.1:3306/jeecg-boot?characterEncodingUTF-8useUnicodetrueuseSSLfalseserverTimezoneGMT%2B8 username: root password: root这个URL里的serverTimezone一定要正确设置改成GMT%2B8即UTC8不然会出现时间上的八小时偏差。Redis配置在同一个文件里检查host、port、password三个字段。如果本地Redis没设密码password填空字符串或注释即可。Jeecg-Boot启动时会向Redis写入一些缓存数据如果连不上Redis启动过程会报错。3.4 后端与前端启动过程实录后端启动有两种方式一种是在IDE里找到JeecgSystemApplication主类直接运行这种方式适合开发调试另一种是先用Maven打包然后通过java -jar方式运行适合测试环境部署。我用IDE启动时遇到的最常见问题是Maven依赖下载超时。国内网络环境下第一次拉依赖会比较慢解决方案是在Maven的settings.xml中配置阿里云镜像并把Maven的本地仓库路径设置到非系统盘避免空间不足。首次启动建议等日志输出中出现“Started JeecgSystemApplication”这样的字样同时确认没有出现红色ERROR级别的异常整个启动过程在两三分钟内完成是比较正常的。前端启动前先进入前端工程目录执行npm install安装依赖。如果网络不佳可以把npm源切换成淘宝镜像npm config set registry https://registry.npmmirror.com npm install npm run serve启动成功后浏览器访问8080端口如果通过Vue CLI的默认配置访问地址是localhost:3000。Vue开发服务器默认带有代理配置/jeecg-boot开头的接口请求会被代理到后端8080端口。看到登录页说明前端已经正常用默认admin/admin123登录即可进入系统。3.5 演示数据与账号权限说明Jeecg-Boot初始化SQL中已经内置了一批演示账号。除了超级管理员admin通常还会有一个普通用户账号比如jeecg密码为jeecg123。不同账号的菜单权限和按钮权限不同可以用来验证权限控制是否生效。这套企业平台在演示环境里提前配置了一些业务示例数据比如客户管理、订单管理等样例模块。这些数据一方面方便你体验权限、审批流程另一方面也应该被看作二次开发的参考样例可以对照代码理解一个完整模块从数据库表到后端接口再到前端页面的完整链路。4. 二次开发实战使用代码生成器完成业务模块搭建4.1 业务表结构与数据字典设计二次开发的第一步永远是设计数据库表而不是急着写代码。我以“供应商管理”模块为例演示从零到一搭建一个完整的业务功能。设计供应商表时我通常会包含如下字段供应商编码、供应商名称、联系人、联系电话、所在地区、合作状态、备注。在建表SQL中需要为每个字段设置合适的类型和默认值同时加上create_by、create_time、update_by、update_time这几个系统审计字段这是Jeecg-Boot代码生成器的硬性要求。数据字典用于管理业务中大量使用的枚举值。比如“合作状态”字段我新建一个字典类型supplier_status设置停用、合作中、已解约等字典项。这样在页面表单中这个字段自动渲染为下拉选择框而不是手工输入既统一了数据规范又减少了脏数据。字典使用的一个细节是如果字典的key在系统中已存在不要重复创建同名类型可以直接复用。不同模块的供应商、客户、商机等业务都可能用到“状态”“类型”这类通用字典项统一维护会比每个模块建一套更加高效。4.2 在线表单配置与代码生成操作表结构准备好之后接下来用在线表单功能完成配置。在系统里进入“在线开发”菜单新建一个表单配置表名、实体名称、功能描述等信息系统会自动根据表结构把字段读出来。在这个阶段你可以调整每个字段的控件类型是文本框、下拉框、日期选择器还是数字输入框是否必填是否列表展示是否查询条件。这个配置确实不需要写代码但直接影响生成代码的质量。我建议在配置时就把列表查询字段选好把表单字段顺序排好。等代码生成之后再去调整页面布局成本就高了。配置完成后一键生成代码。生成方式通常有两种一种是在线预览下载把生成的源码文件下载下来解压后复制到工程对应目录另一种是直接把代码生成到本地源码目录这种方式需要预先配置生成路径。生成的内容包括后端接口文件和前端vue页面文件等直接复制到对应目录即可。4.3 菜单挂载与权限按钮配置代码生成并复制到工程后重启后端服务在前端工程中把新页面配置到菜单树中。重点配置组件的路径要对应到前端view目录下实际生成的页面文件不要填错。菜单配置完成并授权给当前角色后刷新页面就能在菜单里看到新模块。此时还要检查按钮权限。Jeecg-Boot的按钮权限机制是在菜单配置中挂载按钮类型的权限标识比如新增按钮的权限标识是supplier:add修改按钮的权限标识是supplier:edit删除按钮的权限标识是supplier:delete。前端页面上会用v-permission指令包裹按钮只有当前登录人拥有对应权限时按钮才会显示。我建议团队在提交代码前先梳理一下模块涉及的按钮权限点按统一规则命名权限标识别让新人随心情乱起名。否则后期权限配置会变得很痛苦。4.4 常见二次开发需求落地方案代码生成器也不是万能的遇到稍微复杂的业务场景仍然需要手写代码。比如主子表表单在线表单里虽然支持配置子表但生成的代码在部分场景下需要手工调整字段映射关系和级联保存逻辑。这时可以利用MyBatis-Plus的事务注解在主表保存方法上增加Transactional确保主子表数据一致。再比如列表页跳转详情页并携带参数生成的代码里默认的参数传递规则如果不够用可以自行修改前端路由中的query参数。还有一个很常见的场景是列表页的列需要显示关联表字段比如供应商列表需要显示所属地区的名称而不是编码这时可以使用Jeecg-Boot提供的字典注解也可以在后端SQL里改成关联查询再映射到VO对象推荐后者性能更加可控。实际项目中完全依赖代码生成器是不现实的但完全拒绝代码生成器同样不现实。合理的姿势是生成器负责搭骨架业务逻辑负责填血肉两者结合才能最高效地交付。5. 常见问题排查与避坑实录5.1 数据库连接失败与SQL导入异常我接手这套源码时第一次启动后端就遇到了数据库连接失败的问题日志里报的是Access denied for user。后来核对了一下发现是源码里的默认数据库密码和本机MySQL密码不一致。解决办法很简单修改application-dev.yml里的账号密码即可。另一个高频异常是导入SQL时报错“Specified key was too long”。这个问题的根源是MySQL 5.6及以下版本的InnoDB索引长度限制。解决方案是修改MySQL配置把innodb_large_prefix参数打开并设置innodb_file_format为Barracuda或者直接升级到MySQL 5.7以上版本。在utf8mb4字符集下字符类型的字段如果建了索引且长度较长很容易触发这个限制。5.2 前端跨域与接口访问异常Jeecg-Boot后端接口统一以/jeecg-boot为前缀前端开发服务器的代理配置目标就是这个前缀。如果在前端发起请求时报跨域错误优先检查vue.config.js中proxy配置的target是否指向了正确的后端地址端口是否填写正确。如果前后端分别部署在不同域名下需要后端开启跨域支持在网关或Controller层允许指定的Origin来源。需要注意的是生产环境不要直接配置为allow all origins这样存在安全风险正确的做法是维护一份允许跨域的域名白名单。5.3 权限按钮不显示与Token失效问题很多刚接触Jeecg-Boot的同学会碰到一个问题明明在角色中勾选了一个按钮权限但刷新页面后按钮还是不显示。这种情况基本上可以总结为三类原因。第一按钮的权限标识和菜单配置里的权限标识不一致检查前端代码中v-permission的值。第二当前登录用户所属角色的缓存没有刷新退出重新登录即可。第三前端页面没有重新构建开发模式下热更新未生效需要手动刷新浏览器页面。Token失效也别忽略Redis的作用——Jeecg-Boot的Token信息存放在Redis中如果Redis服务重启导致缓存被清空所有在线用户都会被迫重新登录。生产环境如果使用Redis作为Token存储务必配置RDB持久化策略避免Redis重启造成大面积掉线。5.4 部署到生产环境的额外注意事项把项目从本地开发环境迁移到生产环境时有几个问题需要提前处理。第一个是配置文件分离不要把开发环境的账号密码直接带到生产环境建议通过启动参数指定外部配置文件把application-prod.yml放到服务器上专门管理Maven打包时排除本地配置。第二个是前端构建执行npm run build后生成的就是dist目录下的静态文件可以交给Nginx托管。Nginx里要配置两个核心点静态文件路径指向dist目录接口请求反向代理到后端服务地址同时配置静态缓存和Gzip压缩提升访问速度。第三个是文件上传路径。开发环境默认上传到本地磁盘生产环境建议改用MinIO、阿里云OSS等对象存储服务避免应用服务器重启导致上传的文件丢失。Jeecg-Boot的存储配置在配置文件中切换到对象存储后需要重点验证文件上传、预览、下载三条完整链路是否正常。6. 一些关于源码学习和后续扩展的建议如果你拿这套源码是为了学习企业级Java后台开发我建议你按这个顺序阅读核心代码先看Controller层的请求处理方式和参数校验写法再看Service层的事务和业务逻辑组织方式然后看Entity和Mapper层的数据库映射最后看Shiro和JWT的认证授权过滤链。这几块读明白一个Spring Boot后端工程的基本套路就通了。如果是前端方向优先阅读src/utils下的request.js封装和router的权限控制逻辑这两处是理解前端工程的关键。后面的业务页面代码尤其是通过代码生成器生成的标准CRUD页面读两三遍就能掌握Ant Design Vue组件的基本用法。Jeecg-Boot后续的演进方向主要还是围绕低代码能力不断增强越来越多适合通过配置化实现的表单和列表功能会沉淀到在线开发模块中。但我不建议盲目追求全配置化关键业务还是要有代码可控性配置化和编码化需要保持一个合理的平衡。最后分享一个我自己的经验拿到类似的系统源码不要急于改代码先在演示环境把系统功能完整过一遍然后本地跑起来再把代码生成器实际用一遍。走完这三个流程你对这个平台的理解会比看文档十遍都要深刻得多。这套基于Jeecg-Boot的企业管理平台作为企业内部项目的起点或者学习参考都挺值得认真过一遍的。本文还有配套的精品资源点击获取 基于Jeecg-Boot的企业管理平台：架构解析与二次开发实战指南
简介这是一套基于Jeecg-Boot深度定制的企业级低代码开发平台——Nbcio-Boot源码包面向中小企业IT实施人员、Java后端开发者及流程数字化转型实践者旨在解决OA/ERP类管理系统快速构建难题显著降低工作流定制与业务集成开发成本。资源共1388个文件含624个Java核心业务与流程引擎模块代码、168个bcmap字体映射文件支撑多语言界面渲染、146个PNG图标资源、94个XML配置与Flowable流程定义文件、40个Vue组件及36个JSON接口规范文件整体压缩包仅31.8MB结构清晰、模块解耦度高。已有73人下载学习适合Spring BootFlowable技术栈进阶实践。读者可直接获取开箱即用的钉钉薪资审批流程示例、ERP风格表格选择器、实时在线聊天模块及MySQL/Oracle/SQL Server多数据库适配方案无需从零搭建基础框架大幅缩短企业级系统原型验证周期。 我在企业级低代码开发这块折腾了不少年从早期的代码生成器到后来的各种快速开发平台Jeecg-Boot算是我用得最顺、也最愿意内推给出项目组的一套方案。最近刚好接手了一套基于Jeecg-Boot封装的企业管理平台源码带在线演示打包成rar分发给内部团队做技术调研。借着这个机会我把整个平台的架构逻辑、部署过程、二次开发路径以及我自己踩过的坑整理成一篇完整笔记既是对这套系统的复盘也方便后续接手的新人少走弯路。如果你正准备选型或者打算基于Jeecg-Boot做企业内部管理系统这篇内容应该能帮你省下不少时间。1. 项目整体设计与思路拆解1.1 为什么选择Jeecg-Boot作为基座企业管理系统的核心矛盾从来不是某个页面写不写得出来而是业务模块多、权限模型复杂、交付周期极短。从零开发一套带组织架构、用户角色、菜单权限、数据字典、流程审批的后台光基础架构就要投入一到两个月。而Jeecg-Boot这类低代码平台把企业管理后台的共性需求事先沉淀成了现成的工程骨架我们能直接在此基础上做业务层的二次开发。这套企业平台选择Jeecg-Boot本质上是做了一个取舍用一部分定制化自由度换取极高的项目启动速度和稳定的基础能力。尤其对于企业内部的OA、CRM、进销存这类业态Jeecg-Boot的在线表单和代码生成器能覆盖绝大多数常规增删改查页面而通过自定义按钮、自定义SQL、扩展JAVA服务又能兜底那些非标业务逻辑。从我接到这套源码的实际情况来看交付包里的内容和标准Jeecg-Boot发行版有明显差异多了一套统一门户、若干个业务子模块的样例配置以及预先调整过的前端主题。这说明它不是在原始框架上直接晒源码而是真的经过了一定程度的业务沉淀再封装起来作为团队内部的项目脚手架来复用。1.2 在线演示与源码下载的定位思考配套提供在线演示和源码下载这个设计很有讲究。在线演示解决的是决策层的信任问题业务方不需要理解Spring Boot或Vue他们只需要点开一个URL看到系统里已经有组织树、角色权限、流程审批就能直观判断这套东西适不适合自家业务。源码下载解决的则是开发层的落地问题。演示环境只能证明平台能跑起来但真正的交付价值在于工程本身。拿到源码后团队可以本地编译、运行、打断点排查、改造业务逻辑。我在实际调研中一般先把在线演示的菜单全部点一遍弄清楚哪些是平台自带能力哪些是样例业务再拉源码在本地跑通对照着看几个关键模块的代码实现。这种组合对于技术选型非常高效。一个开源或半开源项目如果连演示站点都没有只能靠文档脑补界面长什么样如果只有演示没有源码又很难判断代码质量和扩展性。两个都有基本上能在一两天内做出相对靠谱的技术判断。1.3 不同角色的使用视角这套平台面向的人群其实可以分成三类。第一类是项目经理或技术负责人他们主要看演示系统里的功能完整度和权限模型关注的是这个平台能覆盖哪些业务场景二次开发的工量有多大。第二类是后端工程师他们关注的是Jeecg-Boot的代码结构、数据库表设计、在线表单的配置逻辑以及系统能不能顺利在本地跑起来。第三类是前端工程师他们关心的是Vue工程的目录结构、页面如何与后端交互、报表和表单组件如何复用。在文章后面我会分别从这三个视角展开。整个讲解思路会围绕一套真实的部署和开发链路来走从拉源码到本地启动再从建一张业务表到生成一套可用的管理页面最后再聊几个我实际遇到的典型故障。2. Jeecg-Boot核心架构与关键能力解析2.1 基础技术栈选型分析Jeecg-Boot的技术栈选择是比较经典的企业级组合。后端基于Spring Boot 2.x内置了MyBatis-Plus作为ORM框架权限认证使用Apache Shiro JWT工作流模块则集成了Flowable引擎。前端基于Vue 2.x和Ant Design Vue组件库构建工具用的是Webpack。这个组合的成熟度很高团队成员招聘时不需要特殊技能只要熟悉主流Java和前端技术栈就能快速上手。数据库方面Jeecg-Boot默认支持MySQL、Oracle、PostgreSQL、SQL Server等主流关系型数据库实际项目中一般用MySQL最常见。缓存由Redis承担用来存Token、字典数据、在线用户信息等。Sys_user、sys_role、sys_permission这三张核心表支撑了RBAC权限模型sys_user_role和sys_role_permission作为关联表。这种五表模型是业界最成熟的权限设计方案和Spring Security体系的权限模型思路一致只是Jeecg-Boot用Shiro实现了同样的效果。在这个基础上Jeecg-Boot还增加了数据权限的配置能力可以在Controller层根据当前登录人的部门或角色自动拼接数据过滤条件。2.2 在线表单与代码生成器的底层逻辑在线表单是Jeecg-Boot最核心的生产力工具。它的底层逻辑是在界面上配置字段类型、校验规则、控件类型然后根据这些配置自动生成数据库字段和对应的前端表单组件。这样业务人员可以直接在系统里维护表单结构不需要写代码就能建立一张业务表。代码生成器则更进一步它能根据已有数据库表反向生成一套完整的前后端代码。后端生成Controller、Entity、Mapper、Service前端生成列表页面、表单页面、接口调用文件。生成出来的代码是基于模板的如果项目里有统一风格的基础模板生成的代码可以直接进代码仓库再手工做一些定制修改。这套模式解决的真正问题是企业管理系统中约有六到七成的模块是单表或简单主子表的增删改查这类模块的代码几乎高度相似。人工写这些代码费时且容易出错代码生成器能保证统一规范让团队把宝贵的精力集中在真正复杂的业务逻辑上。2.3 多租户与数据权限能力企业管理平台经常面临一个情况同一个系统要支撑多个独立的分公司、部门或外部客户使用。Jeecg-Boot的多租户方案是通过在业务表中增加tenant_id字段基于MyBatis-Plus的拦截器在SQL执行时自动追加租户过滤条件来实现的。这比在业务代码里到处手动拼接条件要友好得多能有效防止漏加条件导致的数据越权。实现多租户的关键配置在MyBatis-Plus的配置拦截器中。在系统管理里创建租户后用户登录时会绑定租户ID后续所有请求在操作数据时TenantLineInnerInterceptor会自动改写SQL语句追加tenant_id x的条件。这样业务代码里根本不需要感知多租户的存在只需要在表设计时预留好字段即可。数据权限和租户权限是两个维度。租户权限管的是“这个用户属于哪个租户”数据权限管的是“这个用户在当前租户内能看到哪些范围的数据”。Jeecg-Boot支持按本人、本部门、本部门及以下、全部数据四种数据范围通过配置规则系统会在查询时自动追加部门ID的过滤条件。这个能力在实际业务中非常实用各个部门只能看到自己范围内的数据既保证业务独立又减少了人为误操作的风险。3. 从演示环境到本地部署的完整实操3.1 环境准备与版本兼容性说明先把环境要求说清楚。Jeecg-Boot 3.x版本需要JDK 8及以上Maven 3.6以上Node.js 10以上建议用14或16Redis 3.2以上MySQL 5.7以上。我在实际部署过程中最常用的组合是JDK 8 MySQL 5.7 Redis 6.x Node 14这套组合最稳定踩坑最少。JDK版本建议直接用8虽然11和17也能跑但有些老依赖在更高版本上会有编译或运行时问题没必要给自己找麻烦。MySQL建议用5.7表结构默认是utf8mb4字符集如果数据库服务端的字符集设置不对导入SQL时会出现乱码或索引过长的报错这一点我在后面故障排查部分会详细说。Redis是登录授权和数据缓存所必需的启动前一定要确认Redis服务可用。如果本机没有RedisWindows系统可以直接下载Windows版Redis解压运行Linux环境用yum或apt安装即可。测试环境不在意安全性的话配置完密码后要确保应用服务能通过网络访问到Redis端口。3.2 源码获取与目录结构解读拿到rar压缩包后第一步是解压注意解压路径不要带中文和空格。解压后你会看到标准的Maven工程结构顶层目录下一般有两个核心Maven模块jeecg-boot-base-core是基础核心模块封装了系统通用能力jeecg-module-system是系统管理模块包含用户、角色、菜单等管理功能。前端工程通常是独立的目录Vue项目结构比较标准src/api目录放接口调用文件src/views目录放页面组件src/router目录配置路由。如果这套源码是经过改造的通常会比原生Jeecg-Boot多出business或modules这类业务模块目录放在里面的就是该企业平台自身的业务代码。拿到源码后我建议你先看pom.xml中的模块依赖关系判断系统集成度再看application-dev.yml中的配置项确认数据库、Redis、文件存储等外部依赖的接入方式。把这些摸清楚本地启动的成功率能大幅提升。3.3 数据库初始化与配置文件修改Jeecg-Boot的初始化SQL文件一般放在db目录下文件名类似jeecg_3.6.0.sql用Navicat或命令行工具导入。如果你的MySQL是5.7版本直接导入通常没有问题。导入后需要修改后端配置。在jeecg-module-system的resources目录下找到application-dev.yml主要检查三处数据库用户名密码、Redis地址端口密码、文件上传的存储路径。例如数据库配置示例spring: datasource: dynamic: datasource: master: url: jdbc:mysql://127.0.0.1:3306/jeecg-boot?characterEncodingUTF-8useUnicodetrueuseSSLfalseserverTimezoneGMT%2B8 username: root password: root这个URL里的serverTimezone一定要正确设置改成GMT%2B8即UTC8不然会出现时间上的八小时偏差。Redis配置在同一个文件里检查host、port、password三个字段。如果本地Redis没设密码password填空字符串或注释即可。Jeecg-Boot启动时会向Redis写入一些缓存数据如果连不上Redis启动过程会报错。3.4 后端与前端启动过程实录后端启动有两种方式一种是在IDE里找到JeecgSystemApplication主类直接运行这种方式适合开发调试另一种是先用Maven打包然后通过java -jar方式运行适合测试环境部署。我用IDE启动时遇到的最常见问题是Maven依赖下载超时。国内网络环境下第一次拉依赖会比较慢解决方案是在Maven的settings.xml中配置阿里云镜像并把Maven的本地仓库路径设置到非系统盘避免空间不足。首次启动建议等日志输出中出现“Started JeecgSystemApplication”这样的字样同时确认没有出现红色ERROR级别的异常整个启动过程在两三分钟内完成是比较正常的。前端启动前先进入前端工程目录执行npm install安装依赖。如果网络不佳可以把npm源切换成淘宝镜像npm config set registry https://registry.npmmirror.com npm install npm run serve启动成功后浏览器访问8080端口如果通过Vue CLI的默认配置访问地址是localhost:3000。Vue开发服务器默认带有代理配置/jeecg-boot开头的接口请求会被代理到后端8080端口。看到登录页说明前端已经正常用默认admin/admin123登录即可进入系统。3.5 演示数据与账号权限说明Jeecg-Boot初始化SQL中已经内置了一批演示账号。除了超级管理员admin通常还会有一个普通用户账号比如jeecg密码为jeecg123。不同账号的菜单权限和按钮权限不同可以用来验证权限控制是否生效。这套企业平台在演示环境里提前配置了一些业务示例数据比如客户管理、订单管理等样例模块。这些数据一方面方便你体验权限、审批流程另一方面也应该被看作二次开发的参考样例可以对照代码理解一个完整模块从数据库表到后端接口再到前端页面的完整链路。4. 二次开发实战使用代码生成器完成业务模块搭建4.1 业务表结构与数据字典设计二次开发的第一步永远是设计数据库表而不是急着写代码。我以“供应商管理”模块为例演示从零到一搭建一个完整的业务功能。设计供应商表时我通常会包含如下字段供应商编码、供应商名称、联系人、联系电话、所在地区、合作状态、备注。在建表SQL中需要为每个字段设置合适的类型和默认值同时加上create_by、create_time、update_by、update_time这几个系统审计字段这是Jeecg-Boot代码生成器的硬性要求。数据字典用于管理业务中大量使用的枚举值。比如“合作状态”字段我新建一个字典类型supplier_status设置停用、合作中、已解约等字典项。这样在页面表单中这个字段自动渲染为下拉选择框而不是手工输入既统一了数据规范又减少了脏数据。字典使用的一个细节是如果字典的key在系统中已存在不要重复创建同名类型可以直接复用。不同模块的供应商、客户、商机等业务都可能用到“状态”“类型”这类通用字典项统一维护会比每个模块建一套更加高效。4.2 在线表单配置与代码生成操作表结构准备好之后接下来用在线表单功能完成配置。在系统里进入“在线开发”菜单新建一个表单配置表名、实体名称、功能描述等信息系统会自动根据表结构把字段读出来。在这个阶段你可以调整每个字段的控件类型是文本框、下拉框、日期选择器还是数字输入框是否必填是否列表展示是否查询条件。这个配置确实不需要写代码但直接影响生成代码的质量。我建议在配置时就把列表查询字段选好把表单字段顺序排好。等代码生成之后再去调整页面布局成本就高了。配置完成后一键生成代码。生成方式通常有两种一种是在线预览下载把生成的源码文件下载下来解压后复制到工程对应目录另一种是直接把代码生成到本地源码目录这种方式需要预先配置生成路径。生成的内容包括后端接口文件和前端vue页面文件等直接复制到对应目录即可。4.3 菜单挂载与权限按钮配置代码生成并复制到工程后重启后端服务在前端工程中把新页面配置到菜单树中。重点配置组件的路径要对应到前端view目录下实际生成的页面文件不要填错。菜单配置完成并授权给当前角色后刷新页面就能在菜单里看到新模块。此时还要检查按钮权限。Jeecg-Boot的按钮权限机制是在菜单配置中挂载按钮类型的权限标识比如新增按钮的权限标识是supplier:add修改按钮的权限标识是supplier:edit删除按钮的权限标识是supplier:delete。前端页面上会用v-permission指令包裹按钮只有当前登录人拥有对应权限时按钮才会显示。我建议团队在提交代码前先梳理一下模块涉及的按钮权限点按统一规则命名权限标识别让新人随心情乱起名。否则后期权限配置会变得很痛苦。4.4 常见二次开发需求落地方案代码生成器也不是万能的遇到稍微复杂的业务场景仍然需要手写代码。比如主子表表单在线表单里虽然支持配置子表但生成的代码在部分场景下需要手工调整字段映射关系和级联保存逻辑。这时可以利用MyBatis-Plus的事务注解在主表保存方法上增加Transactional确保主子表数据一致。再比如列表页跳转详情页并携带参数生成的代码里默认的参数传递规则如果不够用可以自行修改前端路由中的query参数。还有一个很常见的场景是列表页的列需要显示关联表字段比如供应商列表需要显示所属地区的名称而不是编码这时可以使用Jeecg-Boot提供的字典注解也可以在后端SQL里改成关联查询再映射到VO对象推荐后者性能更加可控。实际项目中完全依赖代码生成器是不现实的但完全拒绝代码生成器同样不现实。合理的姿势是生成器负责搭骨架业务逻辑负责填血肉两者结合才能最高效地交付。5. 常见问题排查与避坑实录5.1 数据库连接失败与SQL导入异常我接手这套源码时第一次启动后端就遇到了数据库连接失败的问题日志里报的是Access denied for user。后来核对了一下发现是源码里的默认数据库密码和本机MySQL密码不一致。解决办法很简单修改application-dev.yml里的账号密码即可。另一个高频异常是导入SQL时报错“Specified key was too long”。这个问题的根源是MySQL 5.6及以下版本的InnoDB索引长度限制。解决方案是修改MySQL配置把innodb_large_prefix参数打开并设置innodb_file_format为Barracuda或者直接升级到MySQL 5.7以上版本。在utf8mb4字符集下字符类型的字段如果建了索引且长度较长很容易触发这个限制。5.2 前端跨域与接口访问异常Jeecg-Boot后端接口统一以/jeecg-boot为前缀前端开发服务器的代理配置目标就是这个前缀。如果在前端发起请求时报跨域错误优先检查vue.config.js中proxy配置的target是否指向了正确的后端地址端口是否填写正确。如果前后端分别部署在不同域名下需要后端开启跨域支持在网关或Controller层允许指定的Origin来源。需要注意的是生产环境不要直接配置为allow all origins这样存在安全风险正确的做法是维护一份允许跨域的域名白名单。5.3 权限按钮不显示与Token失效问题很多刚接触Jeecg-Boot的同学会碰到一个问题明明在角色中勾选了一个按钮权限但刷新页面后按钮还是不显示。这种情况基本上可以总结为三类原因。第一按钮的权限标识和菜单配置里的权限标识不一致检查前端代码中v-permission的值。第二当前登录用户所属角色的缓存没有刷新退出重新登录即可。第三前端页面没有重新构建开发模式下热更新未生效需要手动刷新浏览器页面。Token失效也别忽略Redis的作用——Jeecg-Boot的Token信息存放在Redis中如果Redis服务重启导致缓存被清空所有在线用户都会被迫重新登录。生产环境如果使用Redis作为Token存储务必配置RDB持久化策略避免Redis重启造成大面积掉线。5.4 部署到生产环境的额外注意事项把项目从本地开发环境迁移到生产环境时有几个问题需要提前处理。第一个是配置文件分离不要把开发环境的账号密码直接带到生产环境建议通过启动参数指定外部配置文件把application-prod.yml放到服务器上专门管理Maven打包时排除本地配置。第二个是前端构建执行npm run build后生成的就是dist目录下的静态文件可以交给Nginx托管。Nginx里要配置两个核心点静态文件路径指向dist目录接口请求反向代理到后端服务地址同时配置静态缓存和Gzip压缩提升访问速度。第三个是文件上传路径。开发环境默认上传到本地磁盘生产环境建议改用MinIO、阿里云OSS等对象存储服务避免应用服务器重启导致上传的文件丢失。Jeecg-Boot的存储配置在配置文件中切换到对象存储后需要重点验证文件上传、预览、下载三条完整链路是否正常。6. 一些关于源码学习和后续扩展的建议如果你拿这套源码是为了学习企业级Java后台开发我建议你按这个顺序阅读核心代码先看Controller层的请求处理方式和参数校验写法再看Service层的事务和业务逻辑组织方式然后看Entity和Mapper层的数据库映射最后看Shiro和JWT的认证授权过滤链。这几块读明白一个Spring Boot后端工程的基本套路就通了。如果是前端方向优先阅读src/utils下的request.js封装和router的权限控制逻辑这两处是理解前端工程的关键。后面的业务页面代码尤其是通过代码生成器生成的标准CRUD页面读两三遍就能掌握Ant Design Vue组件的基本用法。Jeecg-Boot后续的演进方向主要还是围绕低代码能力不断增强越来越多适合通过配置化实现的表单和列表功能会沉淀到在线开发模块中。但我不建议盲目追求全配置化关键业务还是要有代码可控性配置化和编码化需要保持一个合理的平衡。最后分享一个我自己的经验拿到类似的系统源码不要急于改代码先在演示环境把系统功能完整过一遍然后本地跑起来再把代码生成器实际用一遍。走完这三个流程你对这个平台的理解会比看文档十遍都要深刻得多。这套基于Jeecg-Boot的企业管理平台作为企业内部项目的起点或者学习参考都挺值得认真过一遍的。本文还有配套的精品资源点击获取