★ FEATURED ARTICLE 1. 项目拆解这类管理系统到底在管什么先把这个项目标题拆开看。SpringBoot、Vue、MyBatis、MySQL这四个词组合在一起说白了一套典型的前后端分离管理系统模板。后端Java生态做接口前端Vue做页面中间用JSON通信数据落MySQLMyBatis管SQL映射。这套组合在目前的政务、企业、学校等各类内部管理系统里市场占有率相当高也是很多开发者的第一份工作时大概率要接触的架构。标题里的“政府管理系统”可以放宽理解为机关单位或事业单位的政务管理系统。这类系统的核心业务导向非常明确把单位内部的政务事项、人员信息、审批流程、通知公告搬到线上代替原来的纸质流转和线下跑腿。我接过不少类似项目甲方需求翻来覆去就是那几块——人员管理、角色权限、事项审批、数据统计。把这些模块的骨架搭好60%的定制化需求都能直接套进去。这个项目非常适合三类人第一类是刚学完SpringBoot和Vue基础、想找一个完整项目串联知识点的后端开发者第二类是准备毕业设计或实习简历项目、需要能演示能部署的全栈项目的高校学生第三类是小团队里需要独立承担交付的工程师接手政务类外包项目时可以直接拿这套骨架做二次开发。需要注意一点这类系统的技术难度不在某个单独的技术点而在工程整合。认证怎么做、跨域怎么处理、权限如何控制到按钮级、部署时前端静态资源怎么和后端接口共存这些才是真正拉开项目完成度的细节。下面我按做项目的顺序把这套系统从设计到上线的完整链路过一遍。2. 系统设计模块划分与数据库建模2.1 功能模块怎么划分政务管理系统本质上是一个大号的后台管理平台功能模块的划分逻辑跟商品后台、内容管理后台大同小异。我的建议是第一版不要贪多先把四个核心模块做扎实用户管理、角色管理、部门管理、日志审计。用户管理管账号全生命周期角色管理绑定权限集合部门管理搭组织架构日志审计记录关键操作。基于这四张基础表再往上挂业务模块比如通知公告、事项审批、文件管理等扩展起来就很顺了。用户模块要区分超级管理员和普通用户。超级管理员负责初始化系统、创建账号、配置角色普通用户在被分配的权限范围内操作。这个设计在每个管理系统里几乎一样属于标准动作。2.2 数据库表的详细设计我给这套系统设计了五张核心表第五张是菜单权限表。建表SQL建议用Navicat或者MySQL命令行直接执行字段注释写清楚后续维护会省很多事。用户表字段规划id主键自增格式无要求项目里统一用bigintusername登录账号唯一索引不允许重复password加密存储不能明文保存后续展开说real_name真实姓名用于列表展示和审批记录dept_id关联部门表status账号状态1正常0停用create_time、update_time创建和更新时间角色表id、role_name、role_code、remark。role_code用于代码里判断角色类型比如ADMIN、USER。部门表id、parent_id、dept_name、sort。parent_id支持树形结构部门可以无限级挂载。日志表id、user_id、operation、method、params、ip、time。每次敏感操作往里面插入一条记录是审计追踪的基础。菜单权限表id、menu_name、parent_id、path、component、icon、perms、type。perms是权限标识字符串比如user:add、dept:delete后端接口做权限校验时对比的就是这个字段。五张表的关系很好理解用户属于部门用户绑定角色角色关联菜单权限。典型的RBAC权限模型。创建表的时候有几个注意点。字段类型不要全用varchar——状态字段用tinyint时间字段用datetime或timestamp描述类字段用text。不要偷懒不设默认值比如status字段MySQL 8以下版本正常建表语句里建议设置DEFAULT否则代码里每次都要手动传值。2.3 为什么选这套技术栈选SpringBootVueMyBatisMySQL这套组合最重要的原因是生态成熟。SpringBoot把Spring的配置地狱解决得干干净净内嵌Tomcat让部署变成了一个java -jar命令Vue的组件化开发适合后台管理系统这种页面结构重复度极高的场景MyBatis把SQL控制权完全交还给开发者复杂查询一条SQL写清楚不会像Hibernate那样在性能优化时被层层封装挡住MySQL开源免费团队里人人都能上手。这四样搭配在一起网上资料多出问题搜得到解决方案招聘市场上也好招人。如果换成Spring Cloud微服务对这个体量的项目是过度设计如果用JSPServlet那套老技术开发效率和前后端协作体验又太差用MyBatis-Plus倒是可以能省掉不少单表CRUD的SQL编写后面我会专门提一嘴在项目里如何选型。3. 后端实现从登录鉴权到权限拦截3.1 JWT登录认证详解这套系统的登录认证用JWTJSON Web Token拦截器来实现不用Session。原因很简单前后端分离后后端接口是无状态的Session依赖服务器内存保存状态集群部署时还得引入Redis做Session共享。JWT把用户信息加密进一段字符串服务端不存状态天然适合分布式场景。JWT由三部分组成Header头部、Payload负载、Signature签名。Header里声明加密算法Payload存放用户ID、用户名、过期时间等非敏感信息Signature用服务端密钥对前两部分签名防篡改。登录流程在项目里的实现步骤用户输入账号密码后端接收后先查询用户是否存在再用MD5或BCrypt校验密码校验通过后生成JWT放进响应体里返回给前端前端把token存到localStorage每次请求在请求头里带上Authorization字段后端拦截器拦截所有需要认证的接口检查请求头里的token解析成功则放行失败则返回401密码加密这里我多说一句。MD5是不安全的暴力破解和彩虹表攻击都能轻松突破加盐也只能延缓破解时间。项目里用BCrypt更稳妥每次加密结果都不一样自带盐值Java里用Spring Security的BCryptPasswordEncoder就能直接调。3.2 SpringBoot项目结构与接口实现后端工程按Maven标准结构组织com.xxx.admin ├── controller 接口层 ├── service 业务逻辑层 │ └── impl ├── mapper MyBatis接口 ├── entity 实体类 ├── config 配置类 ├── interceptor 拦截器 └── utils 工具类Controller层只做参数接收和结果封装不再写业务逻辑。Service层处理具体业务流程。Mapper层定义数据库操作方法SQL写在XML映射文件里或用注解直接写。这个分层模式从单机项目到微服务项目通用先养成习惯比什么都重要。业务接口风格用RESTful。用户相关接口示例查询用户列表GET /api/user/list支持分页参数pageNum和pageSize查询参数username、deptId 新增用户POST /api/user 修改用户PUT /api/user/{id} 删除用户DELETE /api/user/{id}分页查询字段有点多我单独建一个PageResult响应体保存total和records前端表格组件直接对接。Controller方法里要校验参数新增和修改的参数校验逻辑要分开写比如新增时检查username是否重复修改时除了username还要检查当前id是否存在。这些细节不在实现阶段处理好上线后就会变成线上事故。3.3 权限控制怎么落到按钮级光有登录认证还不够管理系统还有一个关键点是权限控制。不同角色登录系统后看到的菜单、能点击的按钮都不一样。管理员能看到用户管理菜单和“新增用户”按钮普通用户连入口都看不到。项目里用了拦截器加自定义注解的组合方式实现。先创建一个RequirePermission注解里面声明需要的权限标识比如RequirePermission(user:add)。然后在需要权限控制的接口上打上这个注解在拦截器里检查当前用户拥有的权限集合里是否包含user:add。权限集合在用户登录时一次性查出来放进LoginUser对象再存到ThreadLocal里请求过程中随时可取。菜单按钮前端也要做一道过滤。后端返回用户菜单列表时根据权限集合动态生成前端拿到菜单数据渲染侧边栏没有权限的菜单不渲染。按钮级别的控制前端用自定义指令v-permission没有权限时直接移除DOM元素。注意前端控制只能提升交互体验真正的安全防线永远在后端后端接口必须做权限校验。4. 前端工程化Vue页面开发与接口联调4.1 Vue项目创建与工程结构前端用Vue 2 Element-UI组合这是目前最成熟稳定的后台管理系统搭配。如果项目从零开始且不依赖老组件生态Vue 3 Element Plus也可以但教程和周边工具链目前还是Vue 2资料更多。我项目里用的是Vue 2操作思路是一样的。用Vue CLI创建项目vue create admin-web选择Router、Vuex、Axios这几个插件一路确认完成。项目工程结构src ├── api 接口请求模块 ├── assets 静态资源 ├── components 公共组件 ├── router 前端路由 ├── store 状态管理 ├── views 页面组件 │ ├── login │ ├── user │ ├── role │ ├── dept │ └── dashboard ├── utils 工具函数 ├── App.vue └── main.jsviews目录下的每个业务模块对应一个文件夹文件夹里放index.vue主页面、dialog.vue弹窗组件、form.vue表单组件。这种文件组织方式在多人协作时职责清晰单人开发时查找也方便。4.2 Axios封装与请求拦截前后端分离项目里Axios的封装是整个前端工程的地基。封装得好联调效率和排错效率翻倍封装得不好每个页面都在重复处理错误弹窗、token过期代码冗余到没法看。我在项目里的Axios封装对外开放几个统一能力请求头自动携带token从localStorage读取统一加到Authorization头响应统一处理业务码后端返回值约定code字段200成功401未登录403无权限500系统异常。封装里统一判断code非200直接弹出错误提示401自动跳转登录页token过期或无效时清除本地缓存并跳转到login页面统一封装后页面里请求代码就非常简洁import { getUserList } from /api/user getUserList({ pageNum: 1, pageSize: 20 }).then(res { this.tableData res.records })拿不到数据的异常、token过期的处理全部在拦截器统一完成页面里不用再写一层if判断。4.3 登录页、首页布局与动态路由登录页的核心逻辑就是调用登录接口拿token存到localStorage和Vuex然后跳转到首页。这里容易被忽略的是登录按钮的loading态和表单校验。按钮不设置loading会在网络慢时被连续点击多次重复提交登录请求。Element-UI的Form组件自带校验规则用户名和密码都设required规则并触发方式blur。首页布局用Element-UI的Container布局组件左侧Sidebar放侧边栏菜单顶部Header放用户信息、退出登录按钮右侧Main区域渲染路由对应的页面内容。动态路由是前端一个比较关键的进阶点。直接在前端router里把所有的菜单和页面关系写死会导致不管什么角色登录都能看到完整路由表安全性和体验都差。更好的做法是登录成功后接口返回当前用户的菜单数据前端用router.addRoutes动态注册路由将没有权限的路由直接过滤掉。这样管理员和普通用户看到的系统功能完全不同另一个好处是后续扩展权限时不改前端代码后端加配置就行。5. 完整部署从打包到生产上线5.1 环境准备和服务器规划部署这套系统最低要求一台2核4G的服务器操作系统选CentOS 7或Ubuntu 20.04 LTS都可以。8G内存体验更好因为Java进程默认吃256MB左右MySQL和Nginx各占一部分内存太小的服务器扛不住并发访问。环境准备清单JDK 1.8 MySQL 5.7 Nginx 1.16 Maven 3.6可选服务器上直接编译用JDK用openjdk-8-jdk即可MySQL在服务器上装好后设置root密码开放3306端口。Nginx负责两件事一是托管前端构建后的静态文件二是反向代理后端接口地址解决跨域问题。生产环境的MySQL安全策略建议不要用root账户连接Java应用单独创建一个业务专属账号只赋予业务库的增删改查权限。这样就算连接串泄露攻击者也拿不到整个数据库的权限。5.2 数据库初始化与后端打包准备好服务器环境后按顺序执行部署步骤第一步把源码里的admin.sql上传到服务器执行导入mysql -u root -p admin.sql如果SQL文件里包含创建数据库的语句导入前确认数据库名和配置文件中的一致。项目里的数据库连接配置在application-prod.yml中部署时需要把localhost改成服务器地址把用户名密码改成实际的。注意Spring Boot的配置分环境application-dev.yml是本地开发application-prod.yml是生产环境启动时用spring.profiles.active指定使用哪套配置这样不会出现本地配置误传到线上把数据库连崩的情况。第二步在项目根目录执行打包mvn clean package -DskipTests跳过测试是为了避免测试类里的JUnit用例在打包环境出问题导致构建失败。打包成功后target目录下会生成一个jar文件文件名通常是admin-system-0.0.1-SNAPSHOT.jar。第三步启动后端nohup java -Xms256m -Xmx512m -jar admin-system.jar --spring.profiles.activeprod server.log 21 用nohup挂后台运行输出重定向到server.log方便排查问题。-Xms和-Xmx设置JVM初始和最大堆内存2G服务器推荐256M初始化、512M最大值搭配足够用。启动后测一下接口是否正常curl http://localhost:8080/api/user/login出现响应说明后端启动成功。5.3 前端打包与Nginx配置跨域前端打包前需要修改环境配置。开发环境里请求地址写的是http://localhost:8080部署环境需要改成实际的后端服务地址。项目里用.env.production文件管理VUE_APP_BASE_API http://服务器IP:8080这里硬盘的坑是如果直接把IP写死在代码里后续换服务器又要重新打包。更稳妥的做法是前端相对路径请求由Nginx统一转发。生产环境推荐前端请求后端用同一个域名通过Nginx的location规则分流避免暴露后端端口。执行前端构建npm install npm run build构建完成后dist目录就是所有静态文件。把它上传到服务器的/usr/share/nginx/html/admin目录下。修改Nginx配置文件server { listen 80; server_name admin.example.com; location / { root /usr/share/nginx/html/admin; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files配置是为了解决前端路由用history模式时刷新页面出现404的问题。location /api/把后端接口都代理到8080端口前端请求API路径直接用 /api/ 开头不需要写完整域名目标环境无论怎么迁移都不会受影响。配置完成后检查nginx配置合法性nginx -t nginx -s reload浏览器访问域名能看到登录页输入账号密码能登录进去整个部署流程就闭环了。6. 常见问题与高效排错速查6.1 部署和联调期最常见的坑我把实际部署中高频遇到的问题整理成了一张速查表这些问题在我接手的项目里几乎每个都能遇到。前端请求后端接口出现502排查思路先确认后端进程是否在运行再确认Nginx的proxy_pass地址是否可访问。如果是后端启动就失败去看server.log最后几行异常日志。经常出现的问题是数据库连不上或端口被占用。MySQL连接超时排查思路检查安全组和防火墙是否放行3306端口。确认MySQL允许远程连接root默认监听127.0.0.1需要修改配置文件开启外网访问并执行授权语句。还有一个隐蔽的问题是Nginx服务器和后端服务器不在同一台机器时proxy_pass地址写成了localhost导致连接失败。SpringBoot启动报端口占用排查思路8080端口被其他Java进程占用先执行lsof -i:8080找出占用进程替换端口或在JVM启动前确认端口已释放。前端页面刷新后404排查思路就是Nginx的try_files配置缺失导致的。很多人部署完成后首页能访问一刷新子路由就404就是没加try_files $uri $uri/ /index.html。每次修改前端代码后需要重新npm run build并上传dist目录。有朋友为了省事直接在服务器上改构建产物里的JS文件改完发现页面报错排查半天发现压缩后的代码混淆严重根本没法定位。正确做法是在本地开发环境修改源码重新构建。部署时有个容易混淆的点SpringBoot可以配置打包包含前端静态文件用java -jar直接启动一个进程搞定前后端也可以用Nginx托管静态文件两个服务分层部署。我的经验是两个服务分开部署更独立部署前端不影响后端运行排查问题也方便。6.2 排错方法论先分层再定位没有黄金点在排错思路上的话很多新人在面对报错时会手忙脚乱。我的排错顺序永远是先分层确认问题在哪里再针对具体层级做详细排查。第一层确认网络链路通不通浏览器访问前端域名看页面加载是否正常Network面板里请求是否发出了、状态码是什么。如果有个请求长时间挂起优先怀疑跨域或后端无响应。第二层确认后端接口的情况直接tail -f server.log看后端日志。后端日志里一定要打好日志每次请求的关键入参和出参用log.info输出。排查接口报错时日志就是最强助手。第三层确认数据库状态执行select来验证数据在不在、字段对不对、编码是不是utf8。经常出现接口返回的数据中文乱码排查MySQL连接参数、数据库表编码、前端页面编码三个环节。这套方法既是我的排查习惯也是责任边界划分的依据。多人协作时谁负责哪层出了问题先定责再修复永远不会因为互相甩锅拖慢项目进度。7. 项目复盘做完这个项目后的几点心得第一点做项目之前在纸上先把数据库表关系画清楚比直接上手敲代码省太多时间。表关系定了接口的字段基本也就定了。我见过太多人边敲边想表结构改来改去代码跟着重构浪费大量时间。第二点权限模型从一开始就设计成RBAC别在简单系统里图省事写死角色判断。系统上线后加需求是常态固定角色扩展性差到时候改权限比重新开发一套还麻烦。第三点日志从第一天就认真打不要等项目跑起来再补。后端每个关键接口的入参出参都打日志不然线上问题排查只能靠猜。我接手过一些没有日志的历史项目定位一次问题平均要花半天效率极低。第四点部署脚本和文档随项目一起交付。写清楚每一步执行了什么命令、改了哪些配置交接出去以后别人接手才不至于抓瞎。文件里注释写清楚哪怕过了三个月自己回来看也能快速恢复记忆。如果你准备拿这套系统作为面试项目建议把设计思路整理成一份架构文档重点说清楚为什么选SpringBootVue的组合、JWT相对Session的优势、权限控制的实现原理、Nginx解决跨域的机制。面试官看到的不只是你会写CRUD而是你理解一个完整系统是怎么运转的。我在实际交付中还有一个体会政务类管理系统的核心不是技术炫技而是可靠和可维护。接口返回格式统一、日志完整、权限清晰、部署可重复这些基础能力比用了什么高深框架重要得多。把这套基础骨架吃透后续不管接什么管理系统项目都是往里填业务的事情而已。
阅读完成 · 觉得有帮助？
