校园社团管理系统毕设实战：SpringBoot+Java全流程设计指南

每年到毕业设计选题季，都会有一大批同学扎堆做"XX管理系统"。说实话，光"校园社团管理系统"这个名字，我就在不同场合看到不下几十次。Java + SpringBoot，Web版，高校社团活动管理——这几个词组合在一起，几乎是计算机毕设里最经典的配方之一。

但经典配方不等于人人都能做好。同一个题目，有人能做成答辩现场的高分项目，有人却连演示环节都跑不起来。差别不在题目本身，而在你对这个系统背后逻辑的理解深度。这篇文章我就围绕这个题目，把我实际做项目时的完整思路、技术选型理由、数据库设计、核心功能实现以及最后的部署演示方案，从头到尾拆给你看。目标读者是即将做毕设的计算机专业学生，或者想找个现成项目练手的初级开发者。

1. 毕设选这个题目的真实原因：三个确定性的来源

1.1 为什么校园社团管理系统是毕设的"安全牌"

很多人选这个题目是被老师给的范围框住了，也有人是自己查了一圈发现"管理系统"类题目最多。但我要说的是，这个题目的确定性价值，远比看起来高。

第一，业务场景你足够熟悉。你在大学里见过社团招新、活动报名、经费审批、活动场地申请，这些流程你就算没亲身参与过，也一定看别人走过。做毕设最怕什么？怕你根本不理解业务。做过商城的人如果没买过东西，做过医疗系统的人如果没去过医院，写出来的需求分析就是空中楼阁。而校园社团管理，是你天然熟悉甚至正在经历的场景，需求分析这一关天然占优势。

第二，三层角色模型足够明确。超级管理员、社团负责人、普通成员（学生），这个角色划分清晰且具有典型的权限管理特征。毕设评审老师最喜欢看到你在论文里写清楚"基于RBAC的权限模型设计"，而这套系统天然就具备RBAC的土壤。

第三，数据关系丰富但可控。社团、成员、活动、经费、通知，这些实体之间有一对多、多对多、一对一等各种关系，足以撑起数据库设计的全部考察点，又不至于复杂到你一个人做不完。

1.2 题目背后的三个典型业务场景

这个系统表面上叫"社团管理"，实际上你细想，它真正的核心是围绕三个场景转的：

场景一是社团的全生命周期管理。从社团注册申请，到审核通过，到学年更替时的换届，再到社团注销，这是一个完整的状态流转。很多同学做这个题目时只做了"增删改查"，把社团表搞了个CRUD就完事了。但真正让答辩老师眼前一亮的，是你在论文里写清楚"社团要经历待审核、已成立、活动期、休眠期、已注销"这几种状态，并且能解释每种状态的进入条件。

场景二是活动从发起到落地的审批链。一个学生想办一场活动，他要填什么信息？找谁审批？活动预算谁来确定？活动结束后要不要发新闻稿？这套审批流才是整个系统的灵魂。一个只做了"发布活动"功能而没有审批流的系统，本质上连个论坛帖子都不如。

场景三是成员的参与激励与数据沉淀。成员加入社团之后怎么记录参与度？活动考勤怎么做？学期末的积极成员评优依据从哪来？这些功能不一定每个社团系统都做，但能做到这个层级，就说明你是真的思考过"这个系统解决了什么问题"，而不是在机械堆功能。

1.3 从"能答辩"到"有亮点"的层次划分

我对毕设项目有一个三层判断标准：

第一层叫"能跑"——页面能打开，登录能进去，简单的增删改查没毛病。大概一半以上的毕设停在这一层。

第二层叫"能讲"——功能完整，业务闭环，论文里能写清楚每一个设计决策的理由，答辩时任何功能点你都能讲出"为什么这么做"。能做到这一层的，基本就是中上水平的毕设了。

第三层叫"有亮点"——在"能讲"的基础上，你有一两个超出基础教程的独特设计。比如审批流程不是写死在代码里而是配置化的，比如文件上传用到了对象存储，比如权限控制不再局限于"管理员/普通用户"两个角色而是完整的RBAC。

这篇文章的目标，就是帮你把项目做到至少第二层，然后尽力冲击第三层。

2. 技术选型不是抄作业：围绕毕设场景逐层拆解

2.1 为什么主框架锁定 SpringBoot

题目里直接写了 Java + SpringBoot，这是大多数毕设的默认配置。但你要明白SpringBoot到底解决了什么问题，才能在论文里把它写透。

传统Java Web开发要用Servlet写接口、用web.xml配一堆拦截器、手动集成Tomcat，光是把环境搭起来就得一两天。SpringBoot把约定优于配置这套理念推到了极致：内置Tomcat、自动装配、起步依赖，你只需要一个加了@SpringBootApplication注解的主类，就能跑起一个Web服务。

答辩的时候老师常问的一句话是："SpringBoot的自动装配原理是什么？"这个必须能答上来。简单说，@SpringBootApplication是三个注解的组合，@SpringBootConfiguration继承了@Configuration，@EnableAutoConfiguration通过@Import导入AutoConfigurationImportSelector，这个Selector会去读取META-INF/spring.factories或者AutoConfiguration.imports文件里列出的所有配置类，然后根据@ConditionalOnClass、@ConditionalOnMissingBean这些条件注解判断要不要生效。

你要做的不是背下来这段话，而是能落地说："我这个项目里引入spring-boot-starter-web后，框架自动帮我配置了DispatcherServlet和内嵌Tomcat，我没管容器的事。"这种把原理和项目实际结合起来的回答，比背概念强十倍。

2.2 配套技术栈怎么选：ORM、数据库、前端、鉴权

主框架定了之后，其他配套技术栈的选择才是真正拉开差距的地方。

ORM层我用的是MyBatis-Plus，不是JPA。理由有两个：一是国内公司的Java项目用MyBatis系的比例明显更高，写原生SQL方便优化，毕设做完后续找工作也衔接得上；二是MyBatis-Plus的BaseMapper帮你把单表CRUD都封装好了，省下的时间可以去打磨业务逻辑，而不是天天写selectById。而且它的LambdaQueryWrapper写条件查询非常顺手，比如"查询所有状态为'待审核'的社团"，一行代码的事。

数据库就是MySQL 8.0，这没什么好纠结的。MySQL 8.0相比5.7在窗口函数、JSON支持方面都有提升，而且现在新机器上装8.0也是主流。唯一要注意的是驱动版本和连接字符串的时区参数serverTimezone=Asia/Shanghai，这玩意儿配不对，跑起来各种时间差八小时的问题。

前端这块，如果你的前端基础一般，就直接用Thymeleaf服务端渲染加一套现成的AdminLTE或者Layui模板。别一上来就搞Vue3 + Element Plus + Axios前后端分离。前后端分离本身没问题，但毕设答辩是一个"要同时演示代码和讲逻辑"的场景，服务端渲染的代码链路更短，你看得懂、讲得清、改得快。如果队友或者你自己前端水平不错，那可以上Vue，打包后放进SpringBoot的static目录或者单独部署都行，这个后面部署章节细说。

鉴权我用的是JWT + 拦截器，没有上Spring Security。不是Spring Security不好，而是对毕设来说它的学习曲线太陡峭，配置错了半天排查不出原因。JWT的思路非常简单：用户登录成功后后端签发一个token，前端每次请求把它放在Header里带过来，后端通过拦截器校验token的有效性，顺便把当前用户信息解析出来放进请求上下文。整个链路清晰，答辩也容易讲。

2.3 开发环境统一：IDEA 版本与 JDK 版本的真实匹配问题

这里特别提醒一个新手最容易踩的坑：JDK版本和SpringBoot版本的匹配。

我见过太多同学在IDEA里创建SpringBoot项目时，SpringBoot版本选了个最新的，结果本地JDK还是8。SpringBoot 3.x官方要求JDK 17起步，你拿JDK 8跑，启动直接报UnsupportedClassVersionError。然后你网上搜解决方案，搜到一堆让你降版本的文章，折腾一晚上还没搞明白为什么别人能跑你不能。

我的建议非常朴素：用JDK 8 + SpringBoot 2.7.x。原因有二：一是这个组合的教程数量最多，你踩坑时几乎一定能搜到答案；二是很多学校机房和老电脑上装的还是JDK 8，你用17写的代码拿到实验室演示可能就跑不起来。等到项目做完想升级再升级，别在毕设阶段用最新的技术栈给自己制造不必要的麻烦。

IDEA版本的话，2022到2024的都行，2024版本创建SpringBoot项目时选择Spring Initializr服务地址，如果默认地址访问不了，就改成阿里云的镜像地址https://start.aliyun.com，速度瞬间就上来了。

3. 业务边界与功能矩阵：把"管理系统"做厚还是做薄

3.1 三种角色权限模型：超级管理员、社团负责人、普通成员

这个系统的角色模型，往简单了说就是三种：超级管理员、社团负责人、普通成员。但"简单"不等于"粗糙"，关键在于你能否把角色的权限边界说清楚。

超级管理员管的是"平台本身"。用户管理（禁用、启用账号）、所有社团的审核、所有活动的监督、系统参数的配置。他不需要管某个社团的具体事务。

社团负责人管的是"本社团的运营"。成员审核（新人申请入社）、活动发起（提交审批）、本社团公告发布、本社团成员的移除与角色分配。

普通成员能做的是"参与"。浏览所有社团信息、申请加入某个社团、查看社团内的活动日历、报名活动、查看自己的参与记录。

我在实际做这个项目时，把权限控制落实到两个层面。菜单层面，不同角色登录后看到的导航栏不一样；接口层面，后端每个接口都通过拦截器校验当前用户角色，不允许的直接返回403。很多同学的毕设只做了菜单层面的控制——页面按钮隐藏了，但接口不设防，其实那只是"看起来有权限控制"。

3.2 核心业务闭环拆解：社团创建 → 成员招募 → 活动审批 → 活动执行 → 数据归档

拿到需求之后别急着建表写代码，先把业务闭环画清楚。这个系统完整的业务链是这样走的：

第一步，社团创建。一个学生想成立一个新社团，填写申请单（社团名称、类别、宗旨、创始人信息）。管理员审核通过后，社团成立，创始人和审核时指定的指导老师信息进入系统。

第二步，成员招募。社团成立后公开招新，学生浏览社团列表，发起加入申请。社团负责人审核申请，通过后成为正式成员。

第三步，活动审批。社团负责人发起活动，填活动名称、时间、地点、人数上限、经费预算。这里有个审批层级的问题：经费超过某个阈值（比如500元）需要管理员审批，没超过的社团负责人自己确认就行。这个设定很贴近真实业务，而且答辩时能讲出东西来。

第四步，活动执行。活动发布后，成员报名参与，活动当天签到考勤。签到数据最终回到成员的参与记录里。

第五步，数据归档。活动结束后生成活动总结，成员的参与次数、活动积分沉淀下来，作为学年评优的数据源。

这个闭环你不用全做完，但论文里必须有这个整体架构图（手画也行），否则老师一眼就看出来你只是把几个CRUD页面拼在一起，根本没有在"管理"什么。

3.3 功能矩阵表：给你的第一个落地清单

下面的功能表格，是我个人建议的最低完成标准。你照着这个清单做，做完再考虑增加亮点功能。

别一上来就想着做满这个表。我的建议是先把登录、用户、社团、成员、活动这五大模块做完跑通，这就是"能跑"的标准。再去补通知和数据统计，达到"能讲"。最后看时间余量加亮点。

4. 数据库设计：角色、社团、活动的三角关系拆解

4.1 核心表结构与字段设计

数据库设计是毕设论文里占篇幅最多、老师也最爱抽查的部分。这个系统我拆成了十二张表，但核心就五张：用户表、角色表（或直接在用户表里存角色标识）、社团表、成员关系表、活动表。其余都是辅助表，我来逐一说明核心表的字段设计思路。

用户表sys_user的字段除了老生常谈的id、username、password、email、phone、create_time、status之外，我建议加上avatar字段，很多人注册后想换头像，没这个字段就得改表，很麻烦。password存的必须是BCrypt加密后的密文，这是Spring Security自带的加密工具类，直接拿去用。另外加一个user_type字段标识角色类型，1是管理员，2是社团负责人，3是普通成员。虽然更规范的做法是做独立的角色表做多对多关联，但毕设阶段你把这个字段直接放用户表里，大大降低实现复杂度，论文里也能自圆其说——"本系统角色数量固定，采用用户表直接存储角色标识，避免不必要的关联查询"。

社团表club字段有name、category（社团类别）、description、created_by（创建人ID）、advisor_name（指导老师姓名）、status（社团状态：0待审核、1成立、2已注销）、member_count（冗余统计字段，方便列表页显示人数）。这里member_count是冗余字段，不要实时去count成员表，而是成员加入或退出时更新这个值，列表页查询压力小很多。这是典型的空间换时间思路，答辩时可以提一句。

活动表activity字段有title、description、start_time、end_time、location、club_id、creator_id（发起人ID）、budget（经费预算）、status（活动状态机）、max_participants（人数上限）。这个status字段是整个系统的核心之一，下面专门说。

4.2 一对多、多对多的关系落表

用户和社团的关系不是简单的多对多，我建议拆成一张club_member表来承载"成员关系"这个业务概念。

club_member表的字段包括id、club_id、user_id、role_in_club（在社团内的角色：1社长、2副社长、3普通成员）、join_time、status（申请状态：0待审核、1已通过、2已拒绝、3已退出）。为什么要单独的status字段？因为一个学生点击"申请加入"这个动作，他还没有正式成为成员，这期间的状态必须能存储。如果你只用一张club_member表做简单关联，申请和通过就分不开了。

用户报名活动的activity_signup表同理——id、activity_id、user_id、signup_time、attendance_status（0未签到、1已签到、2已取消报名）。注意这里attendance_status和活动本身的状态要区分开，一个记录的是活动进行状态，一个记录的是单个用户的参与状态。

这些表的设计逻辑其实就一句话：凡是有"状态流转"的业务动作，都要单独拆表，而不能只做一个中间键。 这句话你能写进论文，数据库设计这一章基本就稳了。

4.3 活动状态机与审批状态流转

活动表里的status字段我设计成六个取值：

• 0待提交：社团负责人在编辑活动草稿，还没正式发起
• 1待审批：已提交给管理员，等待审核
• 2审批驳回：管理员驳回，需修改后重新提交
• 3已通过/招募中：审批通过，成员可以报名
• 4进行中：活动开始
• 5已结束：活动完成，归档

很多同学做活动管理就只分"未开始"和"已结束"，有审批流程做不了。其实把状态机画出来之后，代码逻辑就变得非常清晰：每个状态允许哪些操作、操作之后跳到哪个状态，一查状态机就知道。

审批记录别只存一个审批结果，我加了一张approval_record表，字段有biz_type（业务类型：社团创建/活动审批）、biz_id（关联的业务主键ID）、approver_id、approval_status（通过/驳回）、comment（审批意见）、create_time。这样答辩时你就能展示"这条活动经历了从发起到审批通过的全过程留痕"，这在真实系统里叫操作审计，是一个加分项。

5. 核心功能实现：权限、审批、消息这三座大山怎么翻

5.1 登录认证与 JWT 签发的完整流程

登录接口的逻辑要写清楚，不然拦截器那边会出问题。我的做法是这样：

用户提交username和password，后端用MyBatis-Plus的selectOne根据用户名查用户，查到后用BCryptPasswordEncoder.matches()比对密码，比对成功就把用户ID、用户名、角色类型封装进一个LoginUser对象，然后用Jwts.builder()生成token，signWith用HS256算法，密钥写死在配置里（毕设场景就写死，别上RS256那套非对称加密），再设置过期时间比如24小时。

返回给前端的数据结构我建议是{ "token": "...", "userInfo": { "id": 1, "username": "admin", "userType": 1, "avatar": "..." } }。前端把token存到localStorage或者sessionStorage，之后每个请求在请求拦截器里统一加上Authorization: Bearer <token>。

这里有个细节：写JWT的工具类方法要考虑token解析失败的情况，Jwts.parser().setSigningKey(secret).parseClaimsJws(token)这个方法在token过期或篡改时会抛异常，你在拦截器里要捕获这个异常然后返回401，而不是让错误一路抛到全局异常处理器返回500。这个细节很多人不注意，但演示时最容易出问题——明明登录过期了，页面却报服务器错误。

5.2 自定义拦截器实现接口级权限校验

SpringBoot里实现拦截器非常简单：实现HandlerInterceptor接口的preHandle方法，然后通过WebMvcConfigurer注册到InterceptorRegistry。

我的拦截器逻辑是这么写的：先从HttpServletRequest的Header里拿token，拿不到就直接返回401，写了response.setStatus(401)然后返回false阻止请求继续执行。能拿到token就解析，解析失败同理返回401。解析成功就把用户信息放进request.setAttribute("userId", ...)，然后通过HandlerMethod拿到当前处理的方法上的自定义注解@RequireRole，读取注解里要求的角色类型，跟当前用户的角色比对，不匹配返回403。

这个流程用大白话讲就是：先看你有没登录，再看你有没有资格做这件事。 分别对应认证和授权两个概念。你论文里如果把"认证"和"授权"分开写清楚，再配一个时序图，答辩老师基本没法挑毛病。

5.3 审批流实现的正确思路：状态字段 + 时间线，而非工作流引擎

有些同学一看到"审批流"三个字就紧张，想着要不要引入Flowable、Activiti这种工作流引擎。千万别，那是给自己找罪受。

这个系统的审批需求本质上是两级审批：社团创建审批和管理员对活动的审批。用状态字段加一个审批记录表就能完美解决，完全没有必要引入一个重型框架。你把流程写进代码里，状态机驱动，每一步操作后更新业务表的状态、插入一条审批记录。如果未来要支持复杂流程再演进成工作流引擎，这个演进路径在论文的"系统展望"里提一句就行。

实际操作时，我建议把"审批"这个动作封装成一个Service方法：传入业务类型、业务ID、审批结果、审批意见，方法内部统一处理状态更新和记录写入。这样无论是社团审批还是活动审批都复用同一套逻辑，代码很干净。

我在某次答辩模拟时被问到过一个很刁钻的问题："如果社团负责人提交活动后管理员一直没审核，活动状态卡在待审批怎么办？"这个问题问得很好，能答上来就是加分项。我的方案是：在定时任务里扫描超过24小时仍未处理的审批单，自动通知管理员，或者在活动开始前24小时如果还没审批就自动置为"审批驳回"并通知发起人。这个功能不复杂，但能体现你对异常流程的考虑，强烈建议做进去。

5.4 消息通知模块：简单不等于低分

消息通知是很多毕设的盲区——没人做，但做了就超出预期。你的系统里规范的做法是：当活动审批状态变化、入社申请被通过或拒绝时，系统给对应用户生成一条通知。实现方式也很简单，一张sys_notification表，字段有user_id、content、is_read、create_time，在关键业务动作里插入记录即可。

前端显示的话，用户登录后进入主页，查询最近未读通知列表，已读状态点击后更新。如果你用了WebSocket可以做成实时推送，做到这个级别已经可以作为亮点写进摘要里了。

但我不建议在毕设里为了"实时"而引入WebSocket，除非你时间非常充裕。普通的轮询就够用了，用户每次刷新页面或者进入通知页面时拉取最新数据，响应速度完全感知不到差别。你可以在论文里加一句话："系统采用主动拉取方式获取通知消息，兼顾实现简洁性与实时性要求；后续可扩展WebSocket实现真正的服务端推送。"进可攻退可守，非常稳妥。

5.5 文件上传与资源管理：关于MinIO的取舍

校园社团管理系统里难免有图片上传的需求——社团Logo、活动海报、用户头像。最简单的方案是存本地磁盘，用一个upload目录存放，数据库里存文件的相对路径，访问时通过/static/upload/**映射过去。

但如果你想让项目多一些企业级味道，把MinIO加进来做对象存储是很好的亮点方向。MinIO是一个兼容Amazon S3协议的开源对象存储服务，它在本地就能轻松部署起来，不像OSS那样需要云服务账号。SpringBoot整合MinIO的主要操作就几步：引入minio依赖，配置MinioClient，封装上传、下载、删除方法，然后在文件上传接口里调用。把图片传到MinIO后返回一个可以访问的URL存进数据库。

我当时做的时候多花了半天时间搭MinIO，但答辩时讲到"系统采用对象存储服务管理静态资源，解耦了应用服务器与文件存储"，那个气场是完全不一样的。不过要提醒你一句：如果目标就是顺利毕业、平稳答辩，这个功能可以放到最后有时间再做，绝对不要因为它卡住开发进度。

6. 部署与演示：让答辩现场真正"跑起来"的完整方案

6.1 环境准备：避开版本雷区

部署到答辩演示机器之前，先把你的开发环境整理干净。JDK 8就装JDK 8，Maven 3.6以上，IDEA配置好本地的Maven仓库。你的项目如果是别人给的或者从网上找的，第一件事看pom.xml里的SpringBoot版本和java.version，跟你本地的JDK对不上就果断改。

很多网上下载的源码，一打开就报一堆红。最常见的报错就是Maven依赖下载不下来。解决方案也很简单，检查Maven的settings.xml，确保mirror节点指向阿里云的中央仓库镜像。国内网络环境下去repo.maven.apache.org拉依赖真的会等到绝望，换成阿里云镜像后基本秒下。这个配置不是可有可无，是必须的。

6.2 打包发布：SpringBoot 内置 Tomcat 的优势

项目开发完成后，本地跑起来只是第一步，答辩当天你不可能指望在场的电脑都装好了IDEA和Maven。正确的做法是打成jar包直接跑。

SpringBoot项目的打包太简单了：Maven面板里双击package，或者命令行mvn clean package -DskipTests，等构建完成，target目录下会生成一个xxx.jar。这个jar是Fat Jar，内嵌了Tomcat和所有依赖，直接在命令行执行java -jar xxx.jar就能启动完整Web服务。

启动之后SpringBoot会打出那个非常经典的ASCII艺术字banner。这个banner其实是可以自定义的，你可以在src/main/resources/banner.txt里放一段自己的ASCII艺术字。网上有在线生成器，把自己名字的拼音放进去生成一个，启动的时候显示"Welcome to XXX Club Management System"，这个小细节特别能给答辩老师留下印象。

端口问题也顺便说一句：默认端口是8080，如果你的演示机器上8080被占了，启动的时候加--server.port=8888参数就能换。部署相关的配置都放到application.yml里，把数据库连接串改成演示机器的MySQL地址（一般是localhost:3306），然后提前把SQL脚本在演示机器上执行一遍，建好库表和测试数据。

6.3 演示数据准备技巧：千万别用空数据库演示

我得反复强调一件事：答辩演示前，一定要准备一套有"故事感"的演示数据。什么叫故事感？就是你打开社团列表，能看到十几个社团信息，社团名称风格要统一；打开活动列表，能看到过去两周有好几场活动，状态分别是"已结束""招募中""待审批"；点开成员管理，能看出来哪个是社长、哪个刚申请还没通过。

这套数据的作用是什么？是让评委的眼睛有事可做。你演示"活动审批"功能时，如果数据库里一条待审批的数据都没有，你就得现场造数据，造完才能演示，整个过程又卡顿又尴尬。提前把数据备好，演示时一点管理员的审核按钮，界面立刻出现"通过"，完美。

演示数据别用"测试1""测试2"这种名字。我见过有同学数据库里社团叫"asdf"、活动叫"123"，演示的时候老师瞥了一眼，你就知道这个项目的态度有问题。花十分钟把数据起得像真实校园里存在的社团一样：篮球社、摄影协会、英语角、动漫社、青年志愿者协会，活动就叫"秋季篮球联赛""摄影作品征集展"。这些细节，正是把毕设从"交差"变成"作品"的分水岭。

6.4 常见运行故障与快速排查

最后把我在部署过程中遇到过的几个高频故障列出来，遇到别慌，基本都是套路问题。

一是启动时报Access denied for user 'root'@'localhost'，这说明数据库连接配置不对或者密码不对。先检查application.yml里的spring.datasource.username和password，再去MySQL命令行里试一下能不能用这个账号登录。还有一种情况是账号密码都对但你用的MySQL 8.0的驱动和你引用的mysql-connector-java版本不一致，8.0以上版本的驱动类名是com.mysql.cj.jdbc.Driver，不是旧的com.mysql.jdbc.Driver。

二是启动时报Port 8080 was already in use，端口占用。这个最简单，换个端口就行，或者把占用进程杀干净。Windows下命令是netstat -ano | findstr 8080，查到PID后taskkill /PID <pid> /F。

三是前端页面样式加载不出来。如果你用了Thymeleaf，模板文件放在src/main/resources/templates/，静态资源放在static/，引用路径写/css/style.css加Thymeleaf的th:href="@{/css/style.css}"。千万别在模板里写死相对路径，否则你从/user/list这个路径访问页面时，浏览器解析的相对路径全错，样式全丢。这个坑看起来小，但找起来特别费时间。

四是数据库时间字段差8小时。检查连接字符串有没有serverTimezone=Asia/Shanghai，同时实体类里的时间字段确认用的是java.time.LocalDateTime。如果你还是用java.util.Date，建议全部换掉。LocalDateTime是线程安全的、API也丰富，SpringBoot对它的序列化和反序列化支持也很好，是现代Java开发的标配。

7. 条形码与核心经验：这个项目之外的三个建议

做这个项目给我最大的一个体会是：毕设不是写代码比赛，而是"表达能力"的比赛。你花三个月写的系统，评委只有十五分钟看。怎么在十五分钟里让他觉得你的东西是完整的、有逻辑的、值得这个学分的？靠的就是你对自己系统的理解深度和表达能力。

所以我建议你做完项目之后，至少花半天时间做一件事：把系统每个页面打开，对照着用一句话说出"这个页面解决什么问题、为什么这么设计"。如果哪个页面你说不出来，那它要么是这个系统不需要的功能，要么是你没真正理解它。这个过程，比多写一个功能模块要值钱得多。

另外一个建议是：代码注释一定要写。不是写那种流水账"// 查询用户"，而是写"// 根据用户名查询用户，用户不存在时返回null，由调用方决定是否抛出业务异常"。注释的质量就是逻辑思维的质量。答辩时你完全可以点开一个方法说"老师您看这里，我在校验用户状态前先判断账号是否被禁用，这个顺序是为了避免未禁用用户也能进入系统这种边界情况"。有注释才有底气说这种话。

最后再说一句关于代码风格的建议：命名要规范，别再用a、b、temp这种变量名。实体类名用驼峰，数据库字段用下划线，方法名用动词短语。getUserByUsername比getUser好十万倍，因为好代码的意图是自解释的。这个习惯从毕设开始养成，受益整个职业生涯。

校园社团管理系统这个题目，难度不高不低，刚好适合一个人独立完成。它给了你充分的业务表达空间，又不至于让你陷入底层技术泥潭。只要把业务闭环想清楚、把技术选型理由讲明白、把部署演示准备到位，这个项目的上限其实非常高。按照这篇文章的思路一步步走下来，我相信答辩那天的你，会比现在的你自信得多。