SpringBoot幼儿园管理系统开发指南：数据库建模到部署避坑

看着幼儿园园长、老师和家长每天在微信群里发通知、填表格、对考勤的照片，我就在想，能不能用一个正规的管理系统把这些琐事都收拢起来。后来我用 SpringBoot 给一家民办幼儿园做了一套幼儿园管理系统，把幼儿信息、班级考勤、请假审批、健康档案、收费记录这些业务全部线上化。这篇文章就把整套系统的设计思路、数据库建模、核心代码实现和部署避坑经验完整写出来，给准备做 Java 毕设或者真实接项目的朋友一个可以直接参考的样板。

这套系统适合三类人：一是做毕业设计的学生，直接拿它当项目骨架很省时间；二是想给园所搭建内部管理平台的技术人员，可以快速理解幼儿园行业的业务主流程；三是初级后端开发者，可以通过这个项目吃透 SpringBoot 的数据访问、权限控制和定时任务这些高频技能点。

1. 业务模块设计：先搞清楚幼儿园一天在忙什么

幼儿园的业务不像电商进销存那么复杂，但角色多、流程碎、时效要求高。我接手项目的第一件事不是写代码，而是蹲在园里看了一周，把日常管理动作拆成六条主线。

第一是幼儿档案这条线。 每个孩子从入园登记开始，就有姓名、性别、出生日期、籍贯、过敏史、紧急联系人、所属班级这些基础数据。很多园所之前用 Excel 管理，一个班几十个孩子，信息分散在班主任和保健医手里，孩子生病、换接送人根本查不到记录。所以学生管理模块必须是基础档案的中心，其他模块都要引用它。

第二是班级与教师配置这条线。 幼儿园班级是核心组织单元，一个班有主班、配班、保育员三个角色，还关联教室、人数上限、年龄段（小班、中班、大班）。教师和班级的关系不是固定的，每学期会调动，所以中间要用关联表，不能直接在教师表里写班级 ID。

第三是考勤与接送这条线。 早上的入园打卡和下午的离园打卡，是园长最关心的数据，因为涉及到安全责任。系统要把每个孩子的打卡时间、接送人关系记录下来，还要支持家长临时更换接送人，这时必须通过系统上报，老师收到提醒后核对确认。

第四是健康与保健这条线。 保健医每天要晨检，记录孩子的体温、口腔、精神状态，有异常的要生成预警。另外还有疫苗本管理、身高体重曲线记录，这些数据家长端要能按月查看。

第五是请假与审批这条线。 家长给孩子请假，不能只在微信上跟老师说一声。系统要做请假单流程，家长发起、老师审批、园长可查，请假数据会自动关联到考勤统计里，避免月底核算出勤率时扯皮。

第六是收费与食谱这条线。 学费、餐费、活动费，每笔收费都要有台账，缴费状态分为未缴、已缴、逾期。食谱管理则是每周生成一次，关联食材采购统计，家长能看到一周的餐食安排。

这六条线看似独立，实际数据是打通的。孩子档案关联班级，班级关联教师；考勤关联孩子和接送人；请假关联孩子和审批人；缴费关联孩子和班级。数据库设计的时候，我以幼儿表为圆心，向外辐射所有业务表，这种"一核多辐"的结构在实际开发中最不容易出逻辑混乱。

2. 技术选型与项目结构：SpringBoot版本不要盲目追新

技术选型这个环节，热搜里很多人问"springboot版本太高怎么办"，这个问题我踩过坑。当时我图新鲜用了 SpringBoot 3.2，结果折腾了两天，后来老老实实退回 2.7.18，原因很简单：3.x 的 Jakarta EE 命名空间变更、Spring Security 6 的配置方式变化，还有 MyBatis-Plus 的兼容问题，对做管理系统这种业务型项目没有任何额外收益。

我的选型清单是这样的：

项目结构上，我建议按业务模块分包，而不是按技术层分包。很多教程喜欢 controller、service、mapper 各建一个包，小项目没问题，但业务一多就乱了。我用的结构是：

code复制com.kidergarten
├── config          // 配置类：拦截器、跨域、MyBatis、定时任务
├── common          // 通用返回结果、异常处理、常量
├── module
│   ├── system      // 用户、角色、菜单
│   ├── student     // 幼儿档案
│   ├── attendance  // 考勤
│   ├── leave       // 请假
│   ├── health      // 保健
│   ├── fee         // 收费
│   └── notice      // 公告
├── utils           // JWT、日期转换、Excel导入导出
└── KidergartenApplication.java

每个 module 内部再分 controller、service、mapper、entity、dto、vo。这样做的好处是，改考勤模块不会碰到学生模块，代码定位快，多人协作也容易划分任务。你要是做毕设，把每个 module 当成一个小的功能演示即可，答辩时拆解起来也清楚。

实操心得：项目依赖里建议加上 spring-boot-starter-validation，做参数校验非常有效。之前我懒，所有参数校验都写在业务代码里，一封字段三十行判断逻辑，后来全部改用 @Valid + @NotBlank 注解，代码量直接少了一半。

3. 核心表设计与建模：看懂这九张表，业务就通了一半

数据库设计是管理系统的灵魂，表关系没理清，后面写多少代码都在填坑。我按"基础数据表、业务数据表、关联数据表"三层来设计，下面这几张是核心中的核心。

3.1 幼儿与班级基础表

code复制t_class（班级表）
- id, class_name, grade_type(小班/中班/大班), max_student, head_teacher_id, create_time

t_student（幼儿表）
- id, student_no(学号), name, gender, birthday, class_id, allergy_info,
  blood_type, enroll_date, status(在读/转出), create_time

班级表关联教师用 head_teacher_id 只是作为默认值，实际班级和教师是多对多关系，我单独建了 t_class_teacher 关联表，字段是 id, class_id, teacher_id, role_type, is_active。为什么要单独做？因为每学期老师调动很频繁，如果直接改班级表的字段，历史任职记录就丢了。

幼儿表里我特意加了 allergy_info 字段，这是做系统时容易忽略的点。幼儿园的食谱推送、保健晨检都需要查询过敏信息，这些字段在数据库设计阶段就要预留。还有一个细节，student_no 要设置成唯一索引，孩子的学号跨学期不能变，后面做考勤、缴费都要靠它关联。

3.2 考勤与请假业务表

code复制t_attendance（考勤表）
- id, student_no, attendance_date, morning_time, afternoon_time,
  morning_status(正常/迟到/缺勤), afternoon_status, pickup_person, create_time

t_leave（请假表）
- id, student_no, leave_type(病假/事假/调休), start_date, end_date,
  reason, status(待审批/通过/驳回), apply_user, approve_user, approve_time

考勤表的设计有一个很关键的考量：为什么不直接用 student_id 而用 student_no？因为考勤数据量最大，用学号这种业务主键在检索时能减少一次关联查询。morning_time 和 afternoon_time 各存一个，再加状态字段，统计迟到率、出勤率时直接用 SQL 的 count 和 group by，不需要在应用层做复杂计算。

请假表则是典型的审批流设计。status 字段有三个状态，前端根据状态显示不同按钮，后端根据状态控制接口是否允许操作。这里要注意并发问题，我第一次做的时候没加乐观锁，两个老师同时审批同一条请假记录，状态互相覆盖。后来加上 version 字段，更新时带上 where version = #{version}，问题就解决了。

3.3 家长账号与缴费表

code复制t_parent（家长表）
- id, student_no, father_name, father_phone, mother_name, mother_phone,
  address, is_main_contact

t_user（用户表）
- id, username, password, user_type(admin/teacher/parent), parent_id, teacher_id, status

t_fee_order（缴费单表）
- id, student_no, fee_type(学费/餐费/活动费), amount, due_date,
  status(未缴/已缴/逾期), pay_time, operator_id

家长表我做了冗余设计，father 和 mother 字段直接平铺在表里，而不是一个"家长子表"。原因是绝大多数家庭只有一两个联系人，平铺字段简单直观，查询快，没必要过分追求范式。t_user 表则是登录账号的核心，通过 parent_id 或 teacher_id 关联到具体业务人，一个家长可以关联多个孩子，所以家长表设计时要考虑一对多的兼容。

核心经验：缴费表里要加 operator_id 字段，记录谁操作的收款确认。之前上线后园长问"这个月谁收的这笔钱"，没有操作人字段根本查不到。管理系统的审计需求，在表设计阶段就要想清楚，后期补很痛苦。

4. 登录鉴权与权限控制：三种角色一套逻辑

幼儿园管理系统的权限体系不复杂，就三种角色：管理员（园长）、教师、家长。但我见过很多同学把权限做成 if else 判断，代码一片混乱。我的做法是角色-菜单-接口三层控制。

4.1 JWT 签发与拦截器配置

登录接口校验完用户名密码后，生成 Token 放回给前端，Token 里只存 userId 和 userType，不存敏感信息。JWT 的有效期我设置为 2 小时，加一个 refreshToken 7 天有效期，这样既安全又不用频繁登录。

拦截器配置是重点。我是这样写的：

java复制public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        // 放行登录、注册接口
        if (handler instanceof HandlerMethod) {
            String token = request.getHeader("Authorization");
            if (StringUtils.isBlank(token)) {
                throw new BusinessException("未登录");
            }
            // 解析 token，把 userId 放入 ThreadLocal
            LoginUser user = JwtUtils.parse(token);
            UserContext.set(user);
            return true;
        }
        return true;
    }
}

需要注意，拦截器里要对 OPTIONS 请求做放行处理，否则前端联调时跨域预检请求会被拦截，界面上报"未登录"。

4.2 接口级权限控制

我自定义了一个 @RequireRole 注解，标注在 Controller 方法上：

java复制@RequireRole({"teacher", "admin"})
@PostMapping("/attendance/manual")

然后在拦截器里解析这个注解，判断当前用户的 userType 是否有权限。这个方案比引入 Spring Security 轻量得多，对于三种角色的项目完全够用。你要硬上 Spring Security 也行，但配置角色继承、权限表达式的时间成本挺高的。

4.3 数据级权限的控制

接口权限只是第一层，还有一个很容易被忽略的数据权限问题。家长登录后只能看自己孩子的数据，这个不能用接口权限控制，必须在 SQL 层处理。我的做法是，家长登录后把关联的 student_no 列表取出来，查询考勤、缴费数据时加 IN 条件：

java复制// 获取当前登录家长关联的所有学生学号
List<String> studentNos = studentService.getStudentNosByParentId(currentUserId);
// 考勤查询加上数据权限
QueryWrapper<Attendance> wrapper = new QueryWrapper<>();
wrapper.in("student_no", studentNos);

这里有个教训：之前有同学把数据权限过滤放在 service 层用循环过滤，结果数据量大时页面卡得厉害，后来改成 SQL 层的 IN 查询才好。数据过滤的原则是能下推给数据库就下推，永远不要在应用层做内存过滤。

5. 功能模块的编码实现：考勤、食谱、健康档案逐一拆解

写代码要讲顺序。我建议先做学生档案模块，因为它是基础；然后做考勤，因为它是家长高频使用的功能；最后做保健和缴费，因为逻辑更独立。下面按我开发的顺序逐个说明。

5.1 学生档案模块实现

这个模块就是常规的增删改查，但有三个重点细节点。

第一是新增学生时自动创建家长账号。代码如下：

java复制@Transactional
public void addStudent(StudentAddDTO dto) {
    // 1. 保存学生基础信息
    Student student = new Student();
    BeanUtils.copyProperties(dto, student);
    student.setStudentNo(generateStudentNo()); // 生成学号
    studentMapper.insert(student);

    // 2. 保存家长信息
    Parent parent = new Parent();
    parent.setStudentNo(student.getStudentNo());
    parentMapper.insert(parent);

    // 3. 创建家长登录账号，初始密码123456
    User user = new User();
    user.setUsername(dto.getFatherPhone()); // 手机号作为登录名
    user.setPassword(BCrypt.hashpw("123456", BCrypt.gensalt()));
    user.setUserType("parent");
    user.setParentId(parent.getId());
    userMapper.insert(user);
}

注意这里加了 @Transactional，三步操作要么全部成功，要么全部回滚。之前没加事务，出现过学生表有数据、家长表没数据的情况，登录的时候直接报空指针。

第二是学号生成策略。学号不能直接用自增 ID，因为班级转学要保留学号。我用的是"年级年份 + 班级编号 + 三位流水号"，比如 2024-03-001。生成时查数据库当前最大学号然后加一，这里要加唯一约束防并发冲突。

第三是转出学生的处理。逻辑删除的字段 status 置为转出，保留历史数据，所有关联表照常存在。物理删除会破坏考勤、缴费的记录完整性，所以系统里一律不提供删除接口，只做状态变更。

5.2 考勤打卡模块实现

打卡这里要区分两种场景：刷卡/扫码的自动记录和老师手动补录。刷卡的话前端扫码后调用后端接口，传 student_no，后端记录当前时间，判断是上午还是下午。手动补录是老师代操作，要记录操作人。

打卡接口核心逻辑：

java复制public AttendanceResult checkIn(String studentNo) {
    LocalDateTime now = LocalDateTime.now();
    LocalTime time = now.toLocalTime();
    String date = now.format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));

    // 查询当天记录
    Attendance attendance = attendanceMapper.selectByStudentAndDate(studentNo, date);

    if (attendance == null) {
        attendance = new Attendance();
        attendance.setStudentNo(studentNo);
        attendance.setAttendanceDate(date);
        // 判断上午/下午
        if (time.isBefore(LocalTime.of(12, 0))) {
            attendance.setMorningTime(time);
            attendance.setMorningStatus(computeStatus(time, "morning"));
        } else {
            attendance.setAfternoonTime(time);
            attendance.setAfternoonStatus(computeStatus(time, "afternoon"));
        }
        attendanceMapper.insert(attendance);
    } else {
        // 已有记录，只补另一时段
        if (time.isBefore(LocalTime.of(12, 0))) {
            attendance.setMorningTime(time);
            attendance.setMorningStatus(computeStatus(time, "morning"));
        } else {
            attendance.setAfternoonTime(time);
            attendance.setAfternoonStatus(computeStatus(time, "afternoon"));
        }
        attendanceMapper.updateById(attendance);
    }
    return new AttendanceResult(studentNo, date, time);
}

这里有一个容易出 bug 的场景：同一个孩子早上刷了两次卡，第二次会覆盖第一次的时间记录。所以我在 update 里加了一个逻辑，如果 morning_time 已存在且当天已写状态，第二次打卡直接返回"已打卡"，不做覆盖。判断简单，但能避免家长说"孩子明明来了，系统怎么显示没来"的纠纷。

考勤统计报表我直接用 SQL 做聚合：

sql复制SELECT t.class_name,
       COUNT(a.id) AS total_attendance,
       SUM(CASE WHEN a.morning_status = 'late' THEN 1 ELSE 0 END) AS late_count
FROM t_attendance a
JOIN t_student s ON a.student_no = s.student_no
JOIN t_class t ON s.class_id = t.id
WHERE a.attendance_date BETWEEN #{startDate} AND #{endDate}
GROUP BY t.class_name

这个报表数据老师每天都看，必须保证响应速度。给 attendance_date 和 student_no 建联合索引，几万条数据毫秒级返回，没有问题。

5.3 每周食谱的定时生成与推送

食谱模块有个很实用的功能：每周一零点自动生成下周食谱，并且推送给家长端。我用 Spring Task 的 @Scheduled 实现：

java复制@Component
public class MenuTask {

    @Scheduled(cron = "0 0 1 * * MON")
    public void generateWeeklyMenu() {
        LocalDate monday = LocalDate.now().next(DayOfWeek.MONDAY);
        List<MenuTemplate> templates = menuMapper.selectTemplates();
        for (MenuTemplate template : templates) {
            WeeklyMenu menu = new WeeklyMenu();
            menu.setWeekStart(monday);
            menu.setWeekEnd(monday.plusDays(4));
            // 复制模板五天的菜品
            menuMapper.insert(menu);
        }
        // 发送通知
        noticeService.sendToAll("本周食谱已更新，请查收");
    }
}

定时任务在实际部署中有个要注意的地方：多实例部署时，@Scheduled 会重复执行。做知识星球或者真实项目的话，建议加一个分布式锁，或者简单点用数据库唯一键做幂等控制。我在菜单表的 week_start 字段上加了唯一约束，重复执行时插入会报错，用 try catch 吃掉即可。

5.4 健康档案与晨检记录

保健医每天晨检要填很多字段：体温、口腔、皮肤、精神状况，还有一个总体评价"正常/异常"。我设计了一张 t_health_check 表：

code复制id, student_no, check_date, temperature, throat_status, skin_status,
   spirit_status, is_normal, note, operator_id

这里的核心操作是风险预警。当体温高于 37.3 或 is_normal 为异常时，系统自动给班主任和家长推送消息。推送用的是简单的站内信，插入一条通知记录，家长端轮询拉取。如果以后接入微信公众号推送，只需要把通知模块的消息渠道抽象成接口，统一扩展即可。

实操心得：晨检数据的录入界面，我一开始做的是表格逐行填，保健医反馈太费时间。后来改成"默认全部正常，仅异常项点击修改"的交互模式，数据量不变，录入时间从每班 10 分钟降低到 3 分钟。做管理系统，交互效率有时候比功能完整更重要。

6. 常见问题排查实录：版本、跨域、打包部署一条龙

下面这些问题是热搜词里大家问得最多、也是我实际开发中被反复折磨的坑，统一整理在这里。

6.1 SpringBoot版本太高引发的兼容问题

如果你已经在用 SpringBoot 3.x，最大的坑是 javax.* 全部要改成 jakarta.*。有多麻烦呢？代码中所有 import javax.persistence.Entity、import javax.validation.constraints.NotBlank 都要改。更麻烦的是，MyBatis-Plus 在 3.5.3 以前的版本不支持 SpringBoot 3，升级后分页插件可能失效。

我的建议很简单：管理系统这类业务项目，用 SpringBoot 2.7.18 + Java 8 是稳定性最高的组合。热搜词里总有"springboot版本太高"的讨论，我的判断是，除非你有 Spring Security 6 的新特性需求或者处理百万级并发的要求，否则真没必要追新。版本选型的第一原则是可维护性，不是新鲜感。

6.2 跨域配置导致的前端联调失败

前后端分离部署后，前端从 5173 端口调 8080 端口的接口，默认会被浏览器拦截。跨域解决很简单，但要记得配置拦截器顺序：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

如果配置了自定义拦截器，注意addInterceptors方法的注册顺序。运行时发现先走拦截器再走 CORS 处理器，OPTIONS 请求会被拦截器拦住报未登录。解决办法是在拦截器里直接放行 OPTIONS：

java复制if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
    return true;
}

6.3 数据库连接池耗尽问题

项目上线后出现过一个诡异问题：早上九点家长端刷考勤时，系统偶尔报"无法获取数据库连接"。排查下来是因为 MyBatis-Plus 默认的连接池参数不太适合实际场景。HikariCP 默认最大连接数是 10，几十个家长同时刷页面，连接被占满。

我在 application.yml 里调整了连接池：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      connection-timeout: 30000
      idle-timeout: 600000

后来观察了几天，稳定了。这里提醒一句，连接池参数要测算，不是越大越好。一个接口的数据库操作耗时平均 50ms，连接并发占用数 = QPS x 平均耗时。50 的连接数对幼儿园系统绰绰有余。

6.4 宝塔Docker部署实战

最后说一说部署。这个项目我用的是宝塔面板的 Docker 方式部署，比传统 jar 包方式干净很多。核心是写一个 Dockerfile：

dockerfile复制FROM openjdk:8-jdk-alpine
VOLUME /tmp
ADD kidergarten.jar app.jar
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
EXPOSE 8080

然后把 jar 包传到服务器，在宝塔的 Docker 管理器里构建运行，设置端口映射为 8080:8080，再加上 MySQL 容器或者使用宝塔自带的数据库，一套环境就起来了。

这里有个非常容易踩的坑：时区问题。默认容器时区是 UTC，用 LocalDateTime.now() 打点考勤记录会比北京时间早 8 个小时。构建时要么在 Dockerfile 里加环境变量：

dockerfile复制ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

要么在 JVM 启动参数里加 -Duser.timezone=Asia/Shanghai。这个问题第一次上线时排查了我一个小时，因为看起来是"考勤时间不对"，实际是时区问题。

6.5 其他高频问题速查

7. 前端配合要点：Vue3 管理端与 API 约定

虽然系统核心是 SpringBoot，但管理端的 Vue3 项目也要注意配合。这里讲几个关键约定，避免前后端扯皮。

接口返回格式统一为：

json复制{
  "code": 200,
  "message": "操作成功",
  "data": {}
}

后端通过一个全局响应处理器包裹返回值，前端 axios 拦截器里统一判断 code，非 200 时弹出 message。这样错误处理逻辑集中在一处，不用每个页面都写 try catch。

另外一个重要约定是时间格式。Java 后端默认返回的时间格式是 2024-01-15T10:30:00，前端展示时还要格式化。我在配置里加了统一格式：

java复制@Bean
public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() {
    return builder -> {
        builder.simpleDateFormat("yyyy-MM-dd HH:mm:ss");
        builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
    };
}

家长端小程序或者 H5 页面直接拿到格式化好的字符串，省去前端自己转格式的麻烦。

前后端联调时，用 Knife4j 生成的接口文档非常省心。Controller 上加上 @ApiOperation 注解，前端同学打开 swagger 页面就能看到参数示例和返回结构，比 Word 传接口文档方便一百倍。这个习惯我一直坚持，强烈建议大家都用起来。

8. 最后给踩坑者的一些话

整套系统从设计到部署完成，我用了一个多月时间。回想起来最浪费时间的不是代码本身，而是三个环节：一是前期业务调研不够充分，保健医的晨检流程二次调整了界面；二是数据库索引设计不到位，考勤数据过万后查询变慢才补索引；三是部署时忽视了容器时区，上线首日考勤时间就错了。

做管理系统，技术难度本身不高，真正的分水岭在业务理解和数据结构设计。如果你正在做 SpringBoot 幼儿园管理系统，建议先把班级、幼儿、考勤、请假的关系图画清楚再动代码。表结构合理了，后面每个功能都是顺水推舟的事。真遇到定位不了的问题，仔细看日志，从异常堆栈的第一行往上找，大部分低级错误都在那几行里藏着。