做业务管理系统这几年我越来越觉得小而全的项目比大而空的平台更有意思。幼儿园管理系统就是典型例子功能点看上去不多但角色有园长、教师、家长三套视角业务又涉及幼儿信息、考勤、收费、食谱、健康档案这些不能出错的数据真做起来比想象中琐碎得多。如果你正准备用 Spring Boot Vue 搭一套类似的管理系统或者想找完整的练手项目参考这篇我把整个系统的设计思路、表结构、关键代码和部署踩坑都拆开讲一遍希望能帮你少走弯路。1. 幼儿园管理系统的需求本质手工台账线上化先说清楚这套系统到底在解决什么问题。幼儿园日常管理离不开几类重复劳动每天晨检要记录幼儿出勤和体温月底要核算伙食费和保育费每周要排食谱并公示给家长老师还要维护每个孩子的健康档案和接送记录。这些工作在过去全靠纸质台账和微信群数据分散、容易漏、难追溯园长想统计一个班的出勤率都得翻半天记录。系统化的核心价值不是上了一个软件而是把这几条业务流程理顺幼儿信息作为主数据贯穿考勤、收费、食谱、档案教师按班级维度录入日常数据家长通过账号只能看到自己孩子的相关信息。数据集中之后园长可以实时看到全园考勤率、收费完成率、食谱执行情况这个视角是纸质管理给不了的。这套系统的目标用户也很明确一是幼儿园的管理者需要看全局数据二是一线教师需要快速录入和查询三是家长主要用移动端或网页看通知和孩子的动态。开发的时候我建议按这三类角色去设计功能菜单和接口权限而不是按功能模块平铺直叙否则后面加角色权限会非常被动。项目本身基于 Spring Boot 提供后端接口Vue 负责前端页面数据库用 MySQL交付物包括完整源码、SQL 初始化脚本和开发文档。这个组合在中小型业务管理系统里属于最稳的路线框架成熟、资料多、招人容易出了问题网上一搜基本都有答案。2. 技术选型Spring Boot Vue 这对组合的实际分量技术选型这件事我吃过不少亏早些年做管理系统喜欢追新框架结果团队维护成本居高不下。幼儿园管理系统这类业务核心诉求是稳定、快速交付、容易改需求所以我最终选的是最稳妥的组合。2.1 后端Spring Boot MyBatis-Plus MySQLSpring Boot 2.7.x 是当前兼容性最稳的版本。Spirng Boot 3 虽然已经出来很久但对 JDK 版本有要求很多服务器环境还是 JDK 8用了 3 之后要么升 JDK 要么换环境纯属给自己找事。业务系统求稳不求新能用就行。持久层我选了 MyBatis-Plus 而不是原生 MyBatis 或 JPA。原因很直接这种管理系统 90% 的数据库操作是单表 CRUD 加简单分页查询MyBatis-Plus 的 BaseMapper 直接帮你把增删改查写好了代码量能少一半。复杂的多表关联统计比如按班级汇总考勤率直接写自定义 SQL也不难。JPA 虽然省事但复杂查询和 SQL 调优的时候反而碍手碍脚不如 MyBatis-Plus 来得直白。数据库用 MySQL 5.7存储引擎选 InnoDB。幼儿信息、收费记录这类数据对事务要求高InnoDB 的行级锁和事务支持是刚需。字符集我统一用 utf8mb4因为需要处理幼儿姓名里可能出现的生僻字和 emoji 表情utf8 存不下。2.2 前端Vue 2 Element UI 依旧能打前端我用的是 Vue 2 Element UI。我知道现在 Vue 3 和 Element Plus 已经很普及但如果你拿到的项目源码是 Vue 2 写的升级成本其实不低。这套组合的好处是生态极其成熟表格、表单、弹窗、日期选择器这些管理系统高频组件开箱即用团队里有 Vue 2 经验的人比比皆是。如果你是从零开始新写我建议直接用 Vue 3 Element Plus Vite开发体验和性能都好很多。但如果是基于现有源码改造没必要强行升级。项目的核心价值在业务逻辑和数据模型前端框架只是外壳别为了技术新鲜感搭进去大量迁移时间。2.3 为什么不用更轻的方案也有人问过这种系统用 Node.js 的 Express 或者 Python 的 Django 不也行吗技术上当然行但考虑现实因素这套系统的部署环境通常在学校或幼儿园的本地服务器环境可能比较老旧Java 的跨平台能力和部署生态更让人放心。另外Spring Boot 在权限框架Spring Security、定时任务、文件处理这些方面有很成熟的解决方案不需要自己造轮子。幼儿园系统虽然小但该有的能力一个不少用 Java 这套反而少操心。3. 功能模块拆解角色模型才是系统的骨架幼儿园管理系统的难点不在功能多而在角色身份复杂。同一个孩子教师看到的是档案和考勤家长看到的是通知和自己的缴费记录园长看到的是全园统计。这要求系统在登录之后就能明确区分谁能看什么、谁能改什么。3.1 三类角色的权限划分我把角色权限分成三层对应现实中的使用场景角色核心权限典型操作管理员园长全部模块可见可配置基础数据创建班级、分配教师、查看全园统计、收费汇总教师本班数据操作权限录入幼儿信息、晨检考勤、发布班级通知、维护食谱家长仅查看与自家孩子相关的数据查看考勤记录、缴费通知、每周食谱、给老师留言这个划分意味着后端接口不能只判断是否登录还要判断数据归属。比如家长调查询考勤接口后端要校验这个考勤记录关联的 childId 是否属于当前登录用户的 children 列表否则就会出现越权访问。这块我会在后面的接口设计部分详细展开。3.2 功能模块清单系统主要包含以下功能模块每个模块对应一组菜单、一组接口和若干张数据表系统管理用户管理、角色管理、菜单管理这是 RBAC 权限模型的基础一般固定不变幼儿管理幼儿信息录入姓名、性别、出生日期、监护人、健康情况、分班、转班、退园班级管理年级-班级两级结构班级绑定班主任和配班教师考勤管理每日晨检记录到园时间、体温、身体状态支持请假登记收费管理按月生成应收账单记录缴费状态支持退费冲抵食谱管理每周食谱录入与发布家长端可见通知公告园级通知和班级通知支持附件统计报表出勤率、收费完成率、班级人数分布等实际开发中幼儿管理和考勤管理是数据量最大的两个模块同时也是和家长互动最多的入口建议优先实现。食谱管理虽然看着简单但涉及到每周日期循环表结构设计时要注意。3.3 模块之间的数据流转我习惯在动手写代码之前先画一张数据流转图幼儿入园时在幼儿管理录入档案并分配到班级每天早晨教师在考勤管理里点选本班幼儿记录出勤每月系统根据幼儿在班天数自动生成收费管理的应收账单家长在家长端看到的是以上所有数据的汇总视图。这样设计之后每一张表都不是孤立的接口写起来也顺很多。4. 数据库设计核心表结构与关系拆解数据库是业务系统的地基表结构设计得好不好直接决定后面开发是顺畅还是痛苦。幼儿园管理系统我最终设计了 14 张核心表这里挑最重要的几张展开说明。4.1 权限相关表通用的 RBAC 五表用户、角色、菜单三张表再加用户-角色、角色-菜单两张关联表。这是 Spring Security JWT 方案的基础几乎可以直接复用任何 RBAC 项目sys_user用户表字段包括 id、用户名、密码BCrypt 加密、昵称、手机号、头像、状态sys_role角色表园长、教师、家长分别对应一条记录sys_menu菜单表包含菜单名称、路由路径、组件路径、图标、排序、类型目录/菜单/按钮sys_user_role用户角色关联表sys_role_menu角色菜单关联表这套模型不复杂但要注意家长角色关联的菜单应该只包含家长端的几个页面而不是把所有菜单都给他否则前端会直接泄底。4.2 业务核心表幼儿、班级、用户的关系幼儿表是整个系统的核心主数据不能只设计成一个简单的字段集合child_info - id - name 幼儿姓名 - gender 性别 - birthday 出生日期 - class_id 所属班级逻辑外键 - guardian_name 监护人姓名 - guardian_phone 监护人手机号 - health_info 健康状况过敏史、病史等文本 - enrollment_date 入园日期 - status 在园/退园状态 - create_time / update_time为什么强调class_id直接冗余在幼儿表里而不是单独建中间表因为一个幼儿在任意时刻只属于一个班级直接用外键字段最简单。如果以后要做历史班级记录再补一张child_class_log表记录每次调班的时间线即可不用一开始就上多对多结构。家长和幼儿的关系也值得想清楚。一个家长可能有两个孩子在同一个幼儿园一个孩子也可能由爷爷奶奶爸爸妈妈多人监护。实践中我建议单独设计一张child_parent关联表字段包括 child_id、user_id、relation_type父亲/母亲/其他这样在查询我的孩子时直接查这张表不需要在幼儿表里塞多个监护人手机号字段。4.3 业务流水表考勤与收费考勤表记录每天的晨检结果字段设计成attendance_record - id - child_id 幼儿ID - class_id 班级ID冗余方便按班统计 - attend_date 日期 - status 出勤/请假/缺勤 - temperature 体温 - morning_check 晨检备注 - create_user_id 录入教师ID日期字段我用的是DATE类型而非DATETIME因为考勤本身就是按天记录的没必要带时分秒。统计某天全园出勤率时一条 SQL 加上索引就能秒出结果。收费表建议拆成账单和缴费记录两张表不要混在一张里。账单表charge_bill存储每月每个孩子应收多少钱、应收期间、单据编号缴费记录表payment_record存储实际收到多少钱、支付方式、收款时间。这样处理退费和部分缴费时非常灵活多付的钱可以挂在账户余额上冲抵下个月。4.4 索引和字段规范我在建表时给所有表的create_time加默认值CURRENT_TIMESTAMP避免程序里逐条手动设置时间。索引方面考勤表加(child_id, attend_date)联合索引收费表加(child_id, bill_month)联合索引。这些联合索引能覆盖绝大多数查询场景数据量到几十万条也不会慢。5. 后端实现三个决定成败的接口设计决策后端接口写起来其实套路化很强真正决定项目质量的是几个容易被新手忽略的设计决策。我挑三个最重要的讲。5.1 JWT 认证集成 Spring Security配置别贪多很多人一提到 Spring Security 就头疼配置复杂、过滤器链绕来绕去。其实在小项目里不需要把 Spring Security 全部功能铺开只要做到登录接口放行、其他接口校验 JWT、密码 BCrypt 加密、角色注解控制接口权限这四件事就够了。核心配置逻辑是这样的写一个 JWT 过滤器从请求头的Authorization里取出 token解析出用户名和角色塞进 SecurityContext然后在 SecurityConfig 里设置/api/login和/api/register为 permitAll其他接口统一走认证。按钮级或接口级权限用PreAuthorize(hasRole(TEACHER))注解规则清晰又省代码。JWT 的密钥要放到配置文件中不要写死在代码里。过期时间我建议设 24 小时家长端如果做记住登录可用 refresh_token 机制不过一般管理系统没这么高要求一个 token 走到底就行。5.2 数据权限防止家长查到别人的孩子这是幼儿园系统和一般管理后台最大的区别。普通后台登录的是管理员数据全是自己人的但幼儿园系统里家长也能登录如果接口不做数据归属校验家长把接口地址改一改就能遍历所有孩子的信息这是非常严重的隐私问题。我的做法是在 Service 层统一处理家长类型的用户查询数据时先从child_parent表查出他关联的 childId 列表然后在查询条件里强制加child_id IN (...)。这个过程不能依赖前端传参后端必须自己做。抽一个工具方法所有家长可访问的查询接口都调用它确保就算有人绕过前端直接调接口也查不到越权数据。5.3 定时任务与报表统计别让数据库扛所有压力每月收费提醒和出勤率统计这类功能可以用 Spring 自带的Scheduled注解实现不需要引入 Quartz。我通常在项目启动后配置一个每日凌晨的定时任务自动扫描上个月应收未缴的账单生成待缴提醒记录每周日晚生成一周出勤统计报表存入汇总表。报表统计的 SQL 是这套系统里比较值钱的部分。比如统计某个月全园出勤率核心查询是SELECT COUNT(DISTINCT CASE WHEN status PRESENT THEN child_id END) AS present_days, COUNT(DISTINCT child_id) AS total_days FROM attendance_record WHERE attend_date BETWEEN #{startDate} AND #{endDate}按班级维度拆分时再加一个 GROUP BY class_id。这个统计在数据量小的时候性能无所谓但幼儿园跑几年后考勤记录几十万条所以统计口径要尽量在 SQL 层聚合不要把明细查出来再到 Java 内存里算内存和接口响应时间都会受不了。5.4 文件上传与导入导出幼儿头像、通知附件这些免不了要传文件。我习惯把上传文件存到本地磁盘的一个独立目录数据库只存相对路径然后用 Nginx 做静态文件映射。这样做的原因是文件没有进数据库数据库体积不会失控备份也快。上传接口要做文件类型白名单校验图片只允许 jpg/png/webp避免有人传个 exe 上来。Excel 导入导出用 EasyExcel比 POI 写起来省太多事。我用它做幼儿信息的批量导入模板教师可以一次性导入全班幼儿名单不用一个个手输。6. 前端实现Vue 项目里权限控制怎么做才不走样前端相对于后端代码量更多但门槛略低关键点集中在权限控制和日常 CRUD 页面的组织方式上。6.1 动态路由和路由守卫前端不能只做菜单隐藏真正的控制要配合路由守卫。系统登录后前端拿到当前用户的角色和菜单权限列表再根据权限动态生成路由表通过router.addRoutes注入。这个做法的好处是家长端压根不会加载教师端的路由组件从入口上就卡死了。路由守卫配合拦截器每次跳转前检查localStorage里的 token没有就强制跳登录页。这里要注意一个坑刷新页面时整个 Vue 应用会重建需要在全局状态里保存一份用户信息和路由表每次刷新后用 token 重新请求获取用户信息接口再重新动态生成路由否则一刷新就白屏。6.2 按钮级权限的自定义指令单靠路由权限还不够同页面里教师能看到编辑按钮家长只能看查看这就需要在按钮层面做控制。我封装了一个v-permission自定义指令传入需要的权限码如果当前用户没有该权限就直接把 DOM 元素移除。Vue.directive(permission, { inserted(el, binding) { const requiredRoles binding.value const userRoles store.getters.roles const hasPermission userRoles.some(role requiredRoles.includes(role)) if (!hasPermission) { el.parentNode el.parentNode.removeChild(el) } } })这样页面代码里只需要写el-button v-permission[TEACHER]编辑/el-button逻辑非常清晰。权限码的数据源来自后端菜单表里的按钮类型记录前后端保持一致。6.3 标准 CRUD 页面的组织套路幼儿园系统里大多数页面是列表、搜索、新增、编辑、删除的套路。我建议抽一个通用模板避免每个页面都复制粘贴一遍。页面结构基本是顶部搜索区关键词、下拉筛选 表格区数据展示、操作列 弹窗区新增编辑表单。数据请求用 Axios 封装一层拦截器里统一处理 token 过期跳转和错误信息提示。表格里的操作列是前端最容易乱的地方。我的习惯是状态为 X 时显示某个按钮通过v-if控制比如考勤记录只有当天可以编辑过了当天就只能查看这样既减少后端校验压力也让教师操作时不至于误改历史数据。6.4 家长端的简化设计家长端和教师端不建议做成两套完全不同的前端项目维护成本太高。我的做法是把同一套系统的菜单权限做好划分家长登录后路由表只包含我的孩子、考勤记录、缴费通知、每周食谱、通知公告这几个页面界面侧重点放在展示而不是操作。用一个 Vuex 字段记录当前登录角色页面根据角色切换展示风格一套代码两端复用。7. 本地跑通到部署上线一份详实的踩坑记录代码全部写完之后真正的考验才开始。我在部署这套系统的过程中踩了不少坑这里把完整流程和问题记录分享出来。7.1 本地环境搭建实际开发中建议先把数据库跑起来再启动后端最后启动前端这个顺序可以避免前端先启动后接口一片红的假象。第一步用 MySQL 执行init.sql脚本初始化所有表和默认数据。默认数据里包含一个管理员账号和一个测试家长账号方便第一时间进系统看效果。第二步修改后端application.yml里的数据库连接、端口、文件上传路径配置。第三步Maven 打包后直接运行 jar 包测试接口。第四步前端项目根目录执行npm install安装依赖然后npm run dev启动开发服务器。这个流程说起来简单实际会遇到 node 版本不兼容、npm 依赖下载慢、MySQL 字符集不对导致建表失败等问题建议每一步都先把日志看明白再往下走。7.2 Nginx 反向代理和前端刷新 404生产环境部署我采用了前后端分离的标准姿势前端打包成静态文件丢到 Nginx后端 jar 包跑在独立端口默认 8080Nginx 配置反向代理把/api前缀的请求转发到后端服务。最经典的问题是前端路由用了 history 模式之后用户刷新页面会 404因为 Nginx 只认物理文件路径找不到对应路由。解决方法是在 Nginx server 配置里加一行 try_fileslocation / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }这个配置的含义是请求的路径找不到文件时统一回退到 index.html由前端路由接管页面跳转。7.3 跨域、时区和上传路径问题本地开发时请求/api会跨域我在后端配置了全局跨域过滤器开发环境放行所有来源。生产环境因为有 Nginx 代理同源就不存在跨域了所以跨域配置要区分环境。日期问题藏得很深服务器默认时区不一定是中国标准时间如果 JVM 时区没设置数据库存的时间会和实际差 8 个小时。我启动 jar 包时会在命令里加-Duser.timezoneAsia/Shanghai并且在 JDBC 连接串里加上serverTimezoneAsia/Shanghai双保险。上传文件路径的坑主要是相对路径和绝对路径的混淆。本地开发时上传的图片可能存到了项目的临时目录部署后路径变了导致图片加载不出来。我的解决办法是配置文件里单独指定一个绝对路径比如/data/kindergarten/upload/Nginx 把/upload路径映射到该目录后端存储时只存/upload/xxx.jpg这个相对路径。7.4 文档和交付这套系统交付时我会附带三样东西源码、数据库脚本、项目文档。数据库脚本里包含建表语句和基础测试数据文档主要讲清三件事如何初始化数据库、如何启动前后端项目、每个模块的核心表结构说明。这套文档对后续接手的人价值很大很多项目代码写得不错但没文档新人接手要花很长时间摸索。我建议在交付前至少自己装一遍干净环境按照文档从零跑通跑不通的地方证明文档写得还不够细。8. 这套系统的扩展方向与我的开发体会幼儿园管理系统这种东西第一版做到能跑、够用、不出错就已经及格了。如果你基于这套源码继续扩展我建议优先考虑几个方向一是家长端增加在线请假审批流程打通教师和家长的双向确认二是加入收费用的微信支付回调逻辑园方和家长都会省事三是把幼儿的成长档案做成时间线记录上传照片和评语这是家长非常买账的功能也是系统增值的方向。说实话做完这套系统最大的体会是业务管理系统的复杂度从来不在技术而在对业务角色的理解。幼儿、教师、家长三者的关系理顺了表结构和接口自然就顺了角色关系没想清楚代码写得再花哨也没用。如果你也是拿 Spring Boot Vue 练手建议不要只在网上抄代码拿到源码后先从头到尾把表结构过一遍再打开后端接口对着前端页面看一遍搞清楚每个按钮背后调用了哪个接口、数据是怎么流转的这套流程走完比你埋头写一百个 CRUD 页面都有用。