基于Spring Boot与SSM的幼儿园综合管理系统开发实战

开头想想，一个幼儿园的综合管理系统到底要做什么？很多人看到"幼儿园教育综合管理系统"这种标题，以为就是一个简单的幼儿信息台账，顶多加个班级管理。实际上真正做下来，你会发现这里面的业务复杂程度一点不比企业ERP简单，甚至因为面向的是幼儿群体，很多业务模型的特殊性和细节要比普通管理系统更敏感、更繁琐。这个基于Java、采用SSM/Spring Boot技术栈的SSM340项目，我整体做下来最大的感受就是：业务模块多且相互关联，角色权限必须清晰，数据维度的设计要非常细致，技术选型上不能盲目追新，稳才是王道。

这篇文章我会把这个幼儿园综合管理系统的完整设计与实现过程拆开揉碎来分享，包括业务建模、数据库设计、核心模块实现、权限控制方案，以及我在实际开发中踩过的坑和排查技巧。不管是拿来做毕业设计、课程设计，还是参考学习想自己从零写一套类似的系统，这篇内容都值得你花十分钟看完，然后存下来对着做。

1. 项目整体设计与业务模块拆解

1.1 幼儿园管理系统到底要管什么

幼儿园的综合管理系统，核心不是"管孩子"，而是围绕孩子的在园全生命周期，把与孩子相关的所有信息流、人员流、事务流全部数字化。我梳理下来，核心业务模块至少包括这几大块：

• 幼儿信息管理：这是地基模块，包含幼儿基本信息（姓名、性别、出生日期、入园日期）、家长信息（父母姓名、联系方式、家庭住址）、过敏史、健康档案、户籍信息等。后续所有业务都要引用幼儿ID作为外键。

• 班级与教师管理：幼儿园的班级划分不是固定的，有全日制班、半日班、托班、小班、中班、大班等，每个班级有对应的班主任、配班老师和保育员。教师信息要和账号体系打通，方便后续考勤和权限分配。

• 考勤管理：幼儿每日入园/离园打卡，以及教师每日到岗考勤。这个模块的难点在于异常考勤的处理，比如家长代打卡、临时请假、迟到早退等。

• 健康管理：包含晨检记录（体温、口腔、手部检查）、用药登记（家长委托喂药）、疫苗接种记录、健康体检记录。疫情期间很多幼儿园还加了每日健康上报。

• 食谱管理：每周食谱制定、食材采购计划、过敏原标记，这个模块看起来简单，但涉及到日期维度的循环和周次计算，设计不好很容易乱。

• 收费管理：保教费、伙食费、校车费、延时服务费等，涉及应收、实收、退费、欠费统计。费用计算规则每个园都不一样，属于业务规则的集中地。

• 通知公告与家校互动：班级通知、园所公告、家长留言、老师回复，这块属于信息交互层，虽然技术上不难，但数据模型的合理性直接影响使用体验。

• 系统管理：用户管理、角色管理、菜单权限管理、操作日志。这是整个系统的骨架，所有其他模块的访问控制都依赖这一层。

这些模块之间不是孤立的，比如幼儿信息里的过敏史会影响食谱管理中的菜谱生成；考勤数据会影响收费管理中的伙食费计算；晨检异常会直接推送给班级老师和保健医。所以设计的时候要把这些关联关系全部理清楚，否则后面开发到一半就会发现表之间缺字段、缺关联，返工成本很高。

1.2 角色权限模型与业务闭环设计

幼儿园系统里的角色，比普通的企业管理系统要多不少。我实际设计的角色包括：系统管理员、园长、保教主任、保健医、班主任、配班老师、财务、家长。每个角色能看到的菜单和数据范围完全不同。

注意：权限设计上，我强烈建议用经典的RBAC（基于角色的访问控制）模型，也就是"用户-角色-菜单/权限"三层结构，不要图省事直接在用户表里加角色字段然后代码里硬编码判断。一个幼儿园可能有十几个班级、上百个教职工，后续变更是常态，RBAC模型才能撑得住。

角色权限确定后，还有一个隐含的数据范围问题：班主任只能看到自己班级的幼儿和家长，保健医能看到全园的晨检和健康数据但看不到收费数据，家长只能看到自己孩子的相关信息。这种数据权限的隔离，我在实现时是通过在业务查询层统一加入数据范围过滤条件来实现的，而不是在每个接口里手动判断，避免漏掉某处导致越权。

业务闭环也很重要。比如"幼儿生病"这件事的完整链路是：家长在APP端请假→班主任确认→晨检记录标记异常→保健医跟进→生成缺勤记录→月底考勤统计影响收费核算→费用减免时关联考勤数据。如果每个模块都各自为政，这个链路就断了，会导致数据对不上。所以在设计阶段就要画出完整的业务时序图，明确每个动作会级联影响哪些模块。

2. 技术选型与架构搭建要点

2.1 Spring Boot 与 SSM 的技术组合逻辑

标题里同时出现SSM和Spring Boot，很多初学者会疑惑：SSM和Spring Boot不是两种不同的东西吗？怎么同时用在一个项目里？这里要理清一个概念：SSM指的是Spring + Spring MVC + MyBatis这三个框架的组合，而Spring Boot是一个快速开发脚手架。Spring Boot并不是替代了SSM，而是让Spring和Spring MVC的配置变得更加简化，MyBatis照样可以整合进来。所以这个项目的技术栈实际上就是：Spring Boot作为基础框架，内部仍然用Spring MVC处理请求、MyBatis操作数据库、Spring管理事务。这也是目前绝大多数Java后端项目的标准形态。

我在这个项目里用的是Spring Boot 2.7.x + MyBatis + MySQL 8.0的组合。为什么不用Spring Boot 3.x？最直接的原因是JDK版本。Spring Boot 3.x强制要求JDK 17及以上，而很多学校机房、服务器环境还在用JDK 8，如果项目需要部署到老环境，或者依赖的一些第三方库还没有适配Jakarta命名空间，贸然升级到Spring Boot 3.x会带来一堆兼容性问题。这个项目不是要追求最新技术，而是要稳、要能跑、要能交付，所以选Spring Boot 2.7.x是目前最平衡的选择。

2.2 JDK 与框架版本匹配的坑

刚才说到了JDK版本，这里要重点提醒一个热词里高频出现的问题："springboot版本太高"和"JDK版本不匹配"。我见过太多人卡在这里：下载了最新版的Spring Boot 3.2.x，结果本机JDK还是1.8，启动直接报错；或者是JDK版本是17，但项目里配置的编译目标还是1.8，报"源发行版17需要目标发行版17"的错误。

版本匹配关系，我整理一个简单的对照：

如果你是按这篇项目的思路来做，建议直接使用Spring Boot 2.7.18（2.x系列的最终版本）+ JDK 8 + Maven 3.6+的组合。这个组合的兼容性我已经验证过非常稳，网上搜得到的教程资料也最多，遇到问题出错的概率最小。

还有一个坑是Maven项目里pom.xml中spring-boot-maven-plugin的版本和Spring Boot版本不一致导致打包异常。最佳实践是直接以spring-boot-starter-parent作为父工程，这样所有Spring Boot相关依赖的版本都由父工程统一管理，不需要手动指定。

2.3 项目目录结构与代码分层规范

Spring Boot项目的包结构看起来随意，但实际工程中我建议严格遵守"按功能分层、按模块分包"的组合方式。这个项目我是这样组织的：

code复制com.kindergarten
├── config          // 配置类：跨域、拦截器、MyBatis、Swagger等
├── controller      // 控制层：接收请求、参数校验、返回结果
├── service         // 业务层：接口定义
│   └── impl        // 业务层：实现类
├── mapper          // 数据访问层：MyBatis的Mapper接口
├── entity          // 实体类：对应数据库表
├── dto             // 数据传输对象：接收前端参数、返回前端数据
├── vo              // 视图对象：用于接口响应
├── common          // 公共类：统一返回结果、异常处理、常量、工具类
├── interceptor     // 拦截器：登录验证、权限验证
└── utils           // 工具类：JWT、日期处理、文件上传等

分层的核心原则是：Controller层只做参数接收和结果封装，不写业务逻辑；Service层处理所有业务规则；Mapper层只做SQL数据交换。很多新手习惯在Controller里直接调Mapper，短期看起来代码少，但一旦业务复杂起来，Service层形同虚设，事务控制和复用都会变得很麻烦。我在这个项目里强制自己遵守"Controller→Service→Mapper"的调用链，后续维护时谁改谁知道。

3. 核心功能设计与数据库建模

3.1 从业务需求推导数据库表结构

数据库表设计是这类管理系统的灵魂。我分享一下这个系统里几张核心表的推导过程。以"幼儿信息表"为例，表面上看起来就是一些基本字段，但实际上要考虑：

• 与家长信息的关联：一个幼儿通常有多个联系人（父亲、母亲、爷爷奶奶），而且家长信息可能会变化（比如更换监护人联系方式）。所以我设计了独立的parent表，然后通过student_parent_relation关联表建立幼儿和家长的多对多关系。

• 与班级的关联：幼儿在一个时间段内只属于一个班级，但跨学期可能会升班。如果只在幼儿表里放一个class_id字段，历史数据会丢失。所以正确的做法是设计一张student_class_log表，记录幼儿每次的入班和调班记录。

• 状态字段：幼儿在园状态（在读、休学、退学、毕业）一定要单独一个字段，而且建议用int类型配合枚举值，不要用String直接存"在读"这种中文值。后面做统计查询时，int值比中文值高效得多，也省去了字符集匹配的麻烦。

再来看考勤表的设计逻辑。幼儿考勤表不能简单存一个"入园时间"和"离园时间"字段，还必须有考勤日期、考勤状态（正常、迟到、早退、请假、旷课）、登记人、备注。并且这张表的唯一索引要建在student_id + attendance_date上，保证一个幼儿一天只有一条考勤记录。我见过有人设计成每打卡一次就插入一条记录，结果一天能插好几条，统计全靠distinct，这是典型的表结构设计失误。

3.2 幼儿考勤与健康管理模块的实现

考勤模块的实际实现，我采用了一个比较务实的方案：家长或老师在微信小程序/APP端操作签到操作，后端生成考勤记录。关键逻辑在于打卡时间的业务规则判断。比如入园打卡时间在7:30-8:30之间记为"正常"，8:30-9:00记为"迟到"，9:00之后记为"缺勤"。这些规则我放在Service层通过策略模式实现，没有写死在SQL里，这样不同幼儿园要求不同时，只需要新增一个策略实现或者调整规则配置即可。

健康管理模块的晨检功能，核心表设计思路是：每天保健医对每个入园幼儿做晨检，记录体温、口腔、精神状态、检查结果。这个模块有一个隐蔽的业务点：晨检记录和考勤记录是联动的，如果晨检发现异常，系统应该自动把当天的考勤状态标记为"异常"并通知班主任和家长。我实现时在晨检记录的插入逻辑里加入了联动判断，同时启动一个事务，保证晨检记录和考勤状态更新要么同时成功，要么同时失败。

3.3 食谱管理中的日期维度与过敏源匹配

食谱管理看似是简单的CRUD，但做起来有一个容易踩坑的点：周食谱的日期维度。幼儿园的食谱通常按周制定，比如周一至周五各一套，但遇到节假日、调休，日期的"周几"会和实际工作日错位。我最初的设计是每周生成一条食谱记录，包含周一至周五五个子表，后来发现节假日调休时这套逻辑完全不可用，数据得手动改。

最终我重新设计成"日期-食谱"一一对应的模型：recipe_date字段存储具体的日期（如2025-06-16），每一天单独一条记录，前端按周展示时按照日期归属的周次聚合。这样遇到调休，只需额外配置一条"补课日期"的映射关系，系统自动把周一的食谱复制到补课日期上。这个改动虽然不大，但解决了数据一致性的根本问题。

过敏源匹配的逻辑也很有意思。幼儿健康档案里维护了过敏源（如花生、牛奶、鸡蛋），当保健医为某天生成食谱时，系统会自动检查食谱中包含的食材是否触及某些幼儿的过敏源，如果有冲突就自动标注预警，提醒班级老师和家长注意。这个功能在企业级系统里是很典型的数据交叉校验场景，虽然不难，但非常体现"综合管理"的价值。

4. 实操过程与核心环节实现

4.1 登录认证与权限控制的落地实现

登录认证我选用了JWT（JSON Web Token）方案，配合Spring Boot的拦截器做请求校验。整体思路是：用户登录成功后，后端签发一个有效期2小时的JWT令牌，前端将令牌存放在本地存储中，每次请求时通过Authorization请求头携带，后端拦截器统一校验令牌的有效性。

JWT令牌里我会存储用户的ID、用户名、角色编码，但不存密码等敏感信息。这里有一个细节：令牌的密钥要放配置文件中，不要硬编码在代码里；过期时间要合理设置，太短了影响体验，太长了有安全风险。

权限控制的实现分两层：第一层是拦截器校验登录状态，所有未携带有效令牌的请求直接返回401；第二层是在Controller方法上用自定义@PreAuthorize注解或者AOP切面来判断当前用户的角色是否有权访问该接口。我实际使用的是Spring AOP方式，自定义了一个@RequireRole注解，在切面中解析JWT里的角色编码做校验。

注意：JWT是无状态的，服务端无法主动让某个令牌失效。如果幼儿园需要"强制下线"某个用户的功能，就需要引入Redis存储令牌的黑名单，或者在数据库中记录用户的登录状态。这个项目我加了黑名单机制，管理员踢人后，被踢用户的令牌ID会加入Redis黑名单，有效期与令牌一致。

4.2 文件上传实现与静态资源映射

幼儿园系统里必然有图片上传的需求：幼儿头像、餐食照片、通知附件、体检报告扫描件。Spring Boot中实现文件上传比较基础，但有三个细节值得注意：

第一，上传文件大小限制。Spring Boot默认的单文件上传限制是1MB，多文件限制是10MB，这个对幼儿园场景明显不够用。我通常在application.yml里调整配置：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 100MB

第二，文件存储路径。开发时本地存磁盘没问题，但项目上线后如果部署到服务器，绝对路径就变了。我的做法是在配置文件中设置一个file.upload-dir自定义配置项，应用启动时自动创建该目录，如果目录不存在就创建。这样换环境只需要改配置，不用动代码。

第三，静态资源映射。因为文件是上传到服务器磁盘的，不是项目内部的resources目录，所以需要配置虚拟路径映射，让外界可以通过URL访问上传的文件。核心配置如下：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Value("${file.upload-dir}")
    private String uploadDir;

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/files/**")
                .addResourceLocations("file:" + uploadDir + "/");
    }
}

配置完成后，上传的幼儿头像可以通过http://localhost:8080/files/avatar/20250601.jpg直接访问，前端img标签引用这个URL即可。

4.3 前后端分离与跨域配置的注意点

这个项目的前端用的是Vue，和Spring Boot后端完全分离部署，所以跨域问题是躲不开的。开发环境下，前端跑在http://localhost:8081，后端在http://localhost:8080，浏览器会拦截跨域请求。

解决跨域最常见的方案是后端配置CORS（跨域资源共享）过滤器。我推荐用Spring Boot的全局配置方式，而不是在Controller上加@CrossOrigin注解，因为后者要在每个接口上重复添加，容易漏掉：

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

这里有一个细节很容易踩坑：如果前端请求携带了JWT令牌（通过Authorization header），那么allowedHeaders里必须包含Authorization，或者直接设为*。另外，如果开启了allowCredentials(true)，那么allowedOrigins不能使用*，必须使用allowedOriginPatterns指定具体的来源，这是浏览器安全策略的硬性要求。

生产环境部署时，更好的方案是使用Nginx反向代理，把/api/前缀的请求转发到后端Java服务，这样前后端同源，就完全不需要跨域配置了。我在实际部署时就是这么做的，省心很多。

4.4 事务控制与数据库操作优化

系统里的多个业务操作需要保证原子性。比如生成一份班级考勤统计，需要先统计出勤数据，再更新幼儿的月度考勤汇总表，还要生成一条操作日志，这三步必须在一个事务里，否则统计到一半报错会导致数据不一致。

Spring Boot中事务控制很简单，在Service方法上添加@Transactional注解即可。但我发现很多初学者在三个地方容易犯错误：

第一，事务注解只加在Controller上不加在Service上，而Spring的事务默认是基于Service层代理的，加在Controller上根本不生效。正确的做法是事务边界放在Service层，Controller只负责参数接收和结果返回。

第二，@Transactional默认只对RuntimeException（运行时异常）回滚，对于受检异常（如Exception）默认不回滚。如果你在Service里捕获了异常但没有重新抛出，事务会认为操作成功，数据就会产生脏数据。我的习惯是自定义一个业务异常类继承RuntimeException，在Service代码里检查到数据异常就throw new BizException("出错了")，事务自动回滚。

第三，事务方法内部调用同类中的另一个方法时，第二个方法上的@Transactional注解不会生效，因为Spring的AOP代理无法拦截同类内部调用。解决方案是把需要事务的方法拆到不同的Service类中，或者通过AopContext.currentProxy()获取代理对象后调用。这个坑在Spring Boot实际开发中出现频率极高，一定注意。

java复制// 错误示例：内部调用不走代理，事务不生效
public class StudentServiceImpl implements StudentService {
    public void updateStudentInfo() {
        // 假设这里有一些业务操作
        this.updateStudentHealthRecord(); // 内部调用，事务不生效
    }
    
    @Transactional
    public void updateStudentHealthRecord() {
        // 本应回滚的操作
    }
}

数据库操作优化方面，我总结了几条实操经验：查询列表时避免SELECT *，只查需要的字段；分页查询用MyBatis的PageHelper插件，不要手动拼接LIMIT；批量插入用MyBatis的<foreach>标签拼接多条VALUES，速度比循环单条插入快非常多；经常作为查询条件的字段一定要建索引，比如考勤表的student_id + attendance_date、通知公告表的class_id + publish_time索引等。

5. 常见问题与排查技巧实录

5.1 热词里提到的"事务失效"到底是怎么发生的

"springboot事务失效场景"确实是面试八股文里的高频题，但在真实项目中也是实实在在的坑。结合这个幼儿园系统，我当时就遇到过一个非常典型的失效场景：删除一个班级，需要同时删除该班级下的所有幼儿、相关考勤记录、健康记录，还有家长绑定关系。我当时把删除逻辑写在一个ServiceImpl里，Service方法加上@Transactional，然后调用同一个类里的私有删除方法，结果测试时发现删除到一半抛异常，前面的数据竟然已经提交了，没有回滚。

排查后确认就是同类内部方法调用导致事务代理失效。后来我调整了代码结构，把删除操作拆成独立的Service类，或者通过AopContext.currentProxy()获取当前类的代理对象再调用方法。修复后重新测试，异常出现时所有数据都正确回滚了。

另外一个很隐蔽的失效场景是@Transactional方法被final修饰，或者方法所在的类被final修饰。Spring默认使用JDK动态代理，要求被代理的类必须实现接口；如果类没有实现接口则使用CGLIB代理，CGLIB无法代理final方法。所以最好别用final修饰Service方法和类，避免这些莫名其妙的代理问题。

5.2 版本太高导致的JDK 17与源发行版报错

热词里多次出现"源发行版17需要目标发行版17"和"springboot版本太高"，这个我在做项目指导时被问过无数遍。这个报错的本质是IDEA或Maven中配置的Java编译器版本和项目实际所需的Java版本不一致。

最常见的场景是：你本机装了JDK 17，项目文件从别人那里拷贝过来，pom.xml里java.version还是1.8，但IDEA的Project Structure里选的Project SDK是17，同时IDEA的Settings里的Java Compiler版本也可能是17。启动项目时Maven编译就会报"源发行版17需要目标发行版17"。

解决方法不复杂，三步解决：第一步，统一IDEA的Project Structure里的Project SDK和Language Level；第二步，统一pom.xml里的java.version属性；第三步，在IDEA的Settings -> Build Tools -> Maven -> Runner里确认JRE选择的版本。三个位置保持一致后重启项目，问题就会消失。

还有一个热词是"springboot jdk1.8打包到docker desktop"，这个我也实践过。如果你的项目用的是JDK 8，那么Dockerfile的基础镜像应该用openjdk:8-jdk-alpine，而不是最新的openjdk:17-jdk。典型的Dockerfile是这样：

dockerfile复制FROM openjdk:8-jdk-alpine
MAINTAINER yourname
ADD target/kindergarten-system.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app.jar"]

构建时需要注意：如果本地Maven打包用的JDK和Docker基础镜像的JDK不一致，程序在容器内启动时可能会因为UnsupportedClassVersionError报错。所以一定要先确认宿主机用JDK 8打包，再用JDK 8的镜像运行。用Docker Desktop在本地调试时，还需要注意Docker Desktop自身的内存设置，默认只有2GB，启动Java应用加MySQL容器很容易内存不足。

5.3 循环依赖问题的发生场景与解决

"springboot循环依赖"虽然是Spring Boot 2.6版本以后默认禁止的特性，但很多老项目或者没升级的依赖里还是会出现。我在这个幼儿园系统里遇到过的最典型的循环依赖是A和B两个Service互相调用：班级Service需要调用教师Service获取班主任信息，教师Service又需要调用班级Service获取班级列表里的教师统计信息，结果Spring容器创建Bean时发现循环引用，报错启动失败。

Spring Boot 2.6.x及以上版本默认不允许循环依赖（spring.main.allow-circular-references默认是false），所以解决方案需要从代码层面进行重构，而不是简单地在配置里放开限制。我推荐三个方向的解决方案：

方案一：使用@Lazy注解，在其中一个Bean的注入处加上@Lazy，延迟代理的创建时机。这个方案改动最小，但治标不治本。

方案二：把互相调用的公共逻辑抽到一个新的Service或者工具类中，让A和B都依赖这个第三方的公共组件，打破循环。

方案三：如果是缓存了某些方法结果导致的循环调用，可以通过事件机制或异步的方式解耦，比如教师Service发布一个"教师更新"事件，班级Service监听这个事件做后续处理，这两个Service就彻底解耦了。

我在这个项目里最终采用方案二，把"获取班级下的教师列表"和"获取教师的负责班级"这两个查询抽到了一个独立的AssignmentQueryService里，两个Service都只调它，循环彻底消除，代码反而更清爽了。

5.4 热词"lambda函数java"与"java八股文"的思考

热词里还有"lambda函数java"和"java八股文"这些关键词，虽然不是这个项目的核心，但也有必要说几句。幼儿园系统是典型的CRUD密集型项目，Java 8的lambda表达式和Stream API在实际业务代码中相当实用。比如统计某天各班级的出勤率，用传统的for循环写要五六行，用Stream一行就能写出来：

java复制Map<Integer, Long> countMap = attendanceList.stream()
        .filter(a -> "NORMAL".equals(a.getStatus()))
        .collect(Collectors.groupingBy(Attendance::getClassId, Collectors.counting()));

"java八股文"这个词大家都不陌生，面试喜欢问，但真实项目中真正高频用到的其实就是集合操作、Stream、Optional判空、lambda表达式、线程池这几个点。作为经验,我的建议是：八股要背，但更重要的是把每个八股知识点对应到真实业务场景中去理解。比如Spring的循环依赖问题，不是让你背"A依赖B，B依赖A，三级缓存解决"，而是让你真的遇到启动失败时能快速定位并重构代码。这个幼儿园系统就是很好的练习场，每个模块都有典型的业务场景对应经典的Spring知识点。

6. 打包部署与项目交付经验

6.1 Maven 多环境配置与打包优化

项目开发完成后的打包部署，是很多初学者最后一步掉链子的地方。我习惯在application.yml里按环境拆分配置：开发环境用本地MySQL，生产环境用服务器MySQL，但连接信息不能写死在同一个配置文件里。Spring Boot支持多配置文件方案：

yaml复制# application.yml 主文件
spring:
  profiles:
    active: dev

# application-dev.yml
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/kindergarten?useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456

# application-prod.yml
spring:
  datasource:
    url: jdbc:mysql://192.168.1.100:3306/kindergarten?useSSL=false&serverTimezone=Asia/Shanghai
    username: prod_user
    password: xxxxxxxxx

打包时使用Maven的profile机制：

bash复制# 开发环境打包
mvn clean package -DskipTests -Pdev

# 生产环境打包
mvn clean package -DskipTests -Pprod

这样打出来的jar包里会自动带上对应环境的配置，部署时可以直接运行，非常省心。如果临时要改配置，也可以用--spring.profiles.active=prod启动参数覆盖，或者用--spring.config.location=指定外部的配置文件。

6.2 部署到云服务器的完整流程

这个项目的最终部署，我选择了一个比较轻量的方案：一台2核4G的云服务器，装好JDK 8、MySQL 8.0和Nginx。部署流程如下：

第一步，把本地的MySQL数据库导出SQL文件，在服务器上创建同名数据库并导入。注意MySQL 8.0后的字符集需要设置utf8mb4，否则中文可能会乱码。

第二步，构建后端jar包，通过scp命令上传到服务器的/opt/kindergarten目录，然后使用nohup java -jar app.jar > logs/app.log 2>&1 &方式启动。

第三步，配置Nginx反向代理，把前端Vue构建后的dist目录映射到80端口，把/api/请求转发到后端8080端口。

nginx复制server {
    listen 80;
    server_name your-server-ip;

    # 前端静态文件
    location / {
        root /opt/kindergarten/frontend;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    # 后端API反向代理
    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;
    }
}

第四步，配置防火墙和安全组，只开放80和22端口，数据库端口3306不对公网开放，避免被扫描攻击。这个步骤千万不要省略，很多人的数据库被勒索攻击，就是因为3306端口直接暴露在公网。

部署完成后，用curl -I http://服务器IP测试前端是否响应，再用curl http://服务器IP/api/user/info测试后端API是否通。我测试时遇到一个经典问题：前端能访问但所有接口请求报404，排查后发现是Nginx的try_files配置把非静态文件的请求都指向了index.html，而API前缀是/api/，需要把API的location放在静态文件location之前，且匹配优先级更高。

6.3 我给这套系统的后续扩展建议

项目做完后我发现，幼儿园管理系统的可扩展空间真的很大。按照"先做核心，再补外围"的思路，有价值的扩展方向至少有四个：

• 引入Redis缓存：目前考勤统计、食谱展示这类高频读接口，每次都是查数据库，性能虽然当前够用，但数据量大后会有压力。将热点数据缓存到Redis，查询速度会有质的提升，但要注意缓存与数据库的一致性，更新数据时主动删除缓存让下次查询重建。

• 接入微信小程序：家长端如果做成小程序，通知触达、签到打卡、请假审批的体验会比H5好很多，需要后端提供配套的微信登录和消息推送接口。

• 数据统计报表：当前系统有大量原始数据，但缺少多维度的分析报表，比如出勤率趋势、收费欠费分析、教职工工作量统计。这部分可以结合定时任务，每日生成汇总数据存入报表表，减少实时聚合的压力。

• 消息通知扩展：现在的通知公告只能站内查看，可以对接阿里云短信或钉钉机器人，实现幼儿缺勤、缴费提醒、健康异常的实时推送。

这些扩展不会改变系统的核心架构，只是在现有模块上做增量开发，也说明当初设计时按模块拆分的好处。

最后再说一个我个人的体会：接手这类"综合管理系统"项目，最忌讳的就是拿到需求直接写代码。我在开发前花了将近一周时间梳理业务模型和数据库设计，画出各模块的关联关系图和核心业务时序图，这个阶段投入的时间在后来的开发中省了不止一倍。你会发现自己写代码时几乎没有返工，因为表结构、接口定义、字段含义全部在图纸上定好了，编码变成了一个体力活。这个习惯我从这套幼儿园系统开始一直保持到现在，每次做系统都是先建模再动手，强烈建议你也这样做。