基于SSM的高校社团管理系统：权限、CRUD与审核流实战

简介：这份毕业设计论文文档围绕SSM高校学生社团管理系统展开，面向计算机相关专业的本科与高职毕业生，以及需要完成课程设计、论文答辩的学生开发者，可用于毕业设计选题参考、论文写作借鉴与技术方案学习。资源包共1个docx文件，大小约4.24MB，内容为完整的毕业论文正文，涵盖摘要、系统设计、功能实现与测试总结等章节。论文所描述的系统采用B/S结构与Spring、SpringMVC、MyBatis整合框架，以MySQL为数据库、Eclipse为开发工具，划分管理员、社长、学生与教师四类角色，涉及轮播图管理、社团信息与活动组织、风采展示、教室借用、人员维护、公告发布及学生反馈等模块，并给出测试阶段对程序逻辑与代码的改进思路。目前已有73人学习参考，适合需要了解社团管理系统整体架构、模块划分与论文撰写框架的读者，可据此梳理功能清单、数据库设计和答辩要点。

1. 从手工台账到 SSM 社团管理系统：这套毕业设计到底解决什么问题

接手这套 SSM 高校学生社团管理系统时，最先卡住的不是代码，而是角色。管理员、社长、教师、学生四种身份，对着同一张社团信息表，能看的字段、能点的按钮完全不同。传统做法是给社团建一份 Excel 台账：社长找指导老师签字，老师再向教务处报备教室，一个学期下来活动记录散在五个人的聊天记录里，换届时资料就断档了。这套系统的价值在于把社团信息、社团活动、社团风采、教室借用、社团人员、社团公告和学生反馈收进一个 B/S 后台，浏览器打开就能查、能改、能审、能留痕。它适合三类人：正在做 Java Web 方向毕业设计、需要一套跑通 Spring + SpringMVC + MyBatis 全链路练手项目的人；刚接手校园信息化维护、想照抄一套权限模型的开发者；以及想把社团流程从纸面搬到线上的社团指导老师。下面按我拆源码的顺序，从框架骨架、表结构、CRUD 到审核流和部署验证一步步展开。

2. SSM 三层骨架与四角色权限模型怎么搭

SSM 不是三个框架简单叠加，而是把「对象管理、请求分发、数据持久」三件事切开，各自只做一段。很多同学装好依赖就急着写 Controller，结果事务不生效、Mapper 注入报空、页面 404，回过头才发现是配置分层没理清。这一章先把骨架立住，再谈四种角色怎么被区隔开。

2.1 Spring、SpringMVC、MyBatis 各自负责哪一段

Spring 管的是对象生命周期和横切逻辑，IoC 容器负责 new 出 Service、DAO，AOP 负责把事务织进 Service 方法；SpringMVC 站在最前面，DispatcherServlet 收请求，按@RequestMapping找到对应 Controller，再返回视图或 JSON；MyBatis 落在最底层，把 Mapper 接口和 XML 里的 SQL 绑定起来，替掉手写 JDBC 的样板代码。

Web 层的入口通常这么配：

<!-- web.xml：SpringMVC 前端控制器与 Spring 容器的装配 --> <servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <!-- contextConfigLocation 指向 SpringMVC 自己的配置，不加载 Service/DAO --> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> <!-- ContextLoaderListener 负责加载 Service、DAO、数据源，只加载一次 --> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mybatis.xml</param-value> </context-param> <!-- 字符编码过滤器必须放在最前，否则社团公告里的中文会乱码 --> <filter> <filter-name>encoding</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param><param-name>encoding</param-name><param-value>UTF-8</param-value></init-param> <init-param><param-name>forceEncoding</param-name><param-value>true</param-value></init-param> </filter>

这里的坑点集中在两个地方。第一，dispatcher的contextConfigLocation只能扫@Controller，父容器只扫@Service、@Repository，两边的component-scan往往写成：

<!-- spring-mvc.xml --> <context:component-scan base-package="com.club.controller"/> <!-- spring-mybatis.xml --> <context:component-scan base-package="com.club.service,com.club.dao"/>

如果不这样拆，Controller 会被父容器也扫一遍，事务代理和 MVC 映射都会出问题。第二，use-default-filters="false"配合include-filter是更严格的写法，避免@Controller漏到父容器。

数据源和 MyBatis 的装配放一起：

<!-- spring-mybatis.xml --> <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource"> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://127.0.0.1:3306/club_db?useUnicode=true&amp;characterEncoding=utf8&amp;serverTimezone=Asia/Shanghai"/> <property name="username" value="root"/> <property name="password" value="123456"/> <!-- 连接池参数按并发量调，毕设场景 initialSize=5、maxActive=20 足够 --> <property name="initialSize" value="5"/> <property name="maxActive" value="20"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> <property name="typeAliasesPackage" value="com.club.entity"/> <property name="plugins"> <array> <!-- PageHelper 分页插件，社团信息列表靠它 --> <bean class="com.github.pagehelper.PageInterceptor"> <property name="properties"> <value>helperDialect=mysql</value> </property> </bean> </array> </property> </bean> <!-- MapperScannerConfigurer 把接口批量注册成 Bean，不用一个个写 --> <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.club.dao"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean>

serverTimezone=Asia/Shanghai不加，社团活动的开始时间会差 8 小时；useUnicode和characterEncoding不加，社团公告的中文存进去就是问号。

2.2 四类角色的权限边界与登录拦截器

系统把用户切成管理员、社长、教师、学生四类。与其在每个 Controller 里写 if 判断角色，不如统一交给 SpringMVC 拦截器。角色按菜单维度划权：

拦截器的核心逻辑是「先看登录态，再看角色白名单」：

public class AuthInterceptor implements HandlerInterceptor { // 免登录白名单：登录页、验证码、静态资源 private static final String[] WHITE = {"/login", "/captcha", "/static/"}; @Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception { String uri = req.getRequestURI(); for (String w : WHITE) { if (uri.startsWith(w)) return true; } // 关键：session 里存的不是简单 boolean，而是带角色的用户对象 Object user = req.getSession().getAttribute("LOGIN_USER"); if (user == null) { resp.sendRedirect(req.getContextPath() + "/login"); return false; } // 角色白名单拦截：教师端不允许写社团信息 String role = ((UserVO) user).getRole(); if (uri.startsWith("/club/audit") && !"teacher".equals(role) && !"admin".equals(role)) { resp.setStatus(403); resp.getWriter().write("{\"code\":403,\"msg\":\"无权审核\"}"); return false; } return true; } }

preHandle返回false就直接截断请求链，不会再进 Controller。注意区分重定向（页面跳转）和直接写 JSON（前后端分离接口），Element UI 前端拿到 403 需要弹提示，不能傻跳登录页。

2.3 从 E-R 图落到物理表

E-R 图里的实体主要有：管理员、社长用户、教师用户、学生用户、社团信息、社团活动、社团风采、教室借用、社团人员、社团公告、学生反馈，外加一张access_token表。实体的关系是：一个社长管理一个社团（1:1），一个社团有多个成员（1:n），一个社团有多个活动（1:n），一个社长可以提交多条教室借用申请（1:n），教师审核这些申请。

access_token表容易被忽略，它是登录会话的落库版本：

把 token 落库而不是只放 session，好处是服务重启后会话还能校验，也方便做「他在哪里登录过」的排查。社团信息表通常会带audit_status（0 待审、1 通过、2 驳回）和teacher_id，这是后文审核流的基础字段。

3. 社团信息、活动、教室借用的 CRUD 落地

权限骨架搭好之后，真正占代码量的是增删改查。这套系统里社团信息、社团活动、教室借用三块结构相似，都是「列表 + 条件检索 + 新增/编辑弹窗 + 删除」。把其中一块写透，另外两块就是复制粘贴改字段。

3.1 实体类与表字段的映射规范

先看社团信息表的核心字段怎么对应 Java 实体：

命名要统一按驼峰转下划线，mybatis-config.xml里打开mapUnderscoreToCamelCase=true，能省掉大量<result>映射。别一边用驼峰一边在 XML 里手写resultMap，字段一多必然对不上。

3.2 Mapper XML 与动态 SQL 条件检索

社团列表页一般带三个检索条件：社团名称模糊查、类型下拉筛选、审核状态筛选。全写成 if 拼接，就是 MyBatis 的<where>+<if>组合：

<select id="selectClubPage" resultType="com.club.entity.ClubInfo"> SELECT club_id, club_name, club_type, president_id, member_count, club_honor, audit_status, cover_img FROM club_info <where> <!-- 逻辑删除标记，查列表永远带这一条 --> is_deleted = 0 <if test="clubName != null and clubName != ''"> AND club_name LIKE CONCAT('%', #{clubName}, '%') </if> <if test="clubType != null and clubType != ''"> AND club_type = #{clubType} </if> <if test="auditStatus != null"> AND audit_status = #{auditStatus} </if> <!-- 社长只能看自己的社团，管理员不传 presidentId 就不加这个条件 --> <if test="presidentId != null"> AND president_id = #{presidentId} </if> </where> ORDER BY create_time DESC </select>

这里的逻辑是：<where>会自动去掉开头多余的AND，不用手写WHERE 1=1。参数上的#{}是预编译占位符，能防注入；如果哪天想按字段名动态排序，那种必须用${}的地方，一定要在 Java 侧用枚举白名单校验字段名，不能直接把前端传的字符串拼进去。

分页配合 PageHelper 只写一行：

// Service 层：调用前紧跟查询方法，PageHelper 只对第一条 SQL 生效 public PageInfo<ClubInfo> page(Integer pageNum, Integer pageSize, ClubQuery query) { PageHelper.startPage(pageNum, pageSize); List<ClubInfo> list = clubMapper.selectClubPage(query); return new PageInfo<>(list); }

pageNum从 1 开始，pageSize传 0 会触发 PageHelper 查全部，线上要限制上限，比如最大 100。PageInfo返回的total才是分页组件要的总条数。

3.3 新增、修改要盯住的三件事

新增社团信息时，社长用户提交后audit_status必须强制置 0，不能信任前端传值，否则有人改个参数就绕过审核。做法是在 Service 里显式覆盖：

// 新增：无论前端传什么，状态一律重置为待审核 club.setAuditStatus(0); club.setPresidentId(loginUser.getId()); club.setCreateTime(new Date()); clubMapper.insert(club);

修改接口则要防越权：先按主键查原记录，比对presidentId是否等于当前登录用户，管理员放行，其他人直接拒绝。删除用逻辑删除（is_deleted = 1）而不是物理DELETE，换届后还能追溯历史数据。教室借用的表结构多三个字段：borrow_date（借用日期）、borrow_remark（借用备注）、audit_status（审核状态），CRUD 逻辑和社团信息同构，只是审核人换成教师。

4. 审核流、反馈与状态机：社长提交、教师审核的实战

社团信息和教室借用都牵扯「提交—审核」两方，这是整套系统里最容易出并发问题的地方。一个社团被教师点通过的同时，社长又点了一次编辑提交，状态就乱了。把状态机显式定义出来，再配合乐观锁或条件更新，问题基本能压住。

4.1 三态审核模型与状态迁移规则

审核状态统一定义为三态，四类角色只能触发允许的迁移：

驳回状态必须允许社长修改后重新提交，否则被驳回一次就等于作废，实际使用中老师会投诉。迁移逻辑集中写在一个方法里：

// 审核：用条件更新防止并发覆盖，WHERE 带上原状态 public int audit(Integer clubId, Integer targetStatus, Integer auditorId) { if (targetStatus != 1 && targetStatus != 2) { throw new IllegalArgumentException("非法审核状态"); } ClubInfo update = new ClubInfo(); update.setClubId(clubId); update.setAuditStatus(targetStatus); update.setAuditorId(auditorId); update.setAuditTime(new Date()); // 关键：只更新 audit_status = 0 的记录，返回 0 说明已被别人审过 int rows = clubMapper.auditWithStatusCheck(update); if (rows == 0) { throw new IllegalStateException("该记录已被审核，请刷新后重试"); } return rows; }

对应 SQL 里WHERE club_id = #{clubId} AND audit_status = 0，这就是最朴素的乐观锁。返回影响行数为 0，前端提示「已被审核」，用户刷新即可，比加分布式锁简单得多。

4.2 审核与事务边界

教师通过一个教室借用申请，往往要同时做两件事：改申请状态、写一条审核日志。这两步必须在一个事务里，否则改了状态没写日志，排查时无从下手。事务加在 Service 方法上：

// Service 方法上加事务，传播行为默认 REQUIRED @Transactional(rollbackFor = Exception.class) public void approveBorrow(Integer borrowId, Integer auditorId) { int rows = borrowMapper.updateStatus(borrowId, 1, auditorId); if (rows == 0) { // 抛运行时异常才能触发回滚，被 catch 掉就白写了 throw new IllegalStateException("申请状态已变更"); } auditLogMapper.insert(new AuditLog("borrow", borrowId, auditorId, "pass")); }

两个常见错误：一是自己try-catch把异常吞了，事务不回滚；二是把@Transactional加在 Controller 上，Controller 不经过 Spring 代理，注解无效。事务只加在 Service 层，且方法必须是 public。

4.3 反馈、公告与消息联动

学生反馈模块是「学生提交—管理员回复」的单向流，字段包含feedback_content、reply_content、reply_time。公告模块本质是带置顶和有效期的富文本，管理员和社长都能发，区别是社长只能发本社团公告。两个模块之间可以做个联动：管理员回复反馈后，顺手往公告表插一条已回复提示，或者用站内消息表推送，避免学生反复刷新页面看回复。用户管理模块的删除接口要连带处理关联数据，删社长账号前先确认其名下社团是否已移交，否则社团信息的president_id会指向一个不存在的用户，列表页显示空社长。

4.4 联调阶段高频报错与定位

列表页一次查 20 条社团，每条又要查社长姓名、类型名称，就会触发 N+1 查询。常见做法是在 Mapper 里用LEFT JOIN把社长昵称和类型名一次带出来，别在循环里调单条查询。

5. 部署验证与压力自测：把毕业设计跑成可交付系统

代码写完只是开始，答辩前最怕的是演示现场 404 或者数据串了。上线前按下面的顺序做一遍可交付验证，能挡掉八成现场事故。

5.1 从零初始化数据库与部署包

先建库建表，再灌一份种子数据，验证空库到有数据的完整路径：

# 1. 建库并导入表结构，字符集必须显式指定 mysql -uroot -p123456 -e "CREATE DATABASE club_db DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -uroot -p123456 club_db < sql/club_db.sql # 2. 灌入管理员和测试账号，密码用明文占位一条，其余走加密 mysql -uroot -p123456 club_db -e "INSERT INTO sys_user(username, password, role) VALUES('admin','123456','admin');" # 3. Maven 打包，注意跳过测试前先确认测试类不会连生产库 mvn clean package -DskipTests # 4. 部署到 Tomcat，检查 war 是否解压成功 cp target/club.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh && tail -f $TOMCAT_HOME/logs/catalina.out

打包时常见的坑是pom.xml里 MySQL 驱动作用域写成provided，Tomcat 里没这个 jar，启动直接ClassNotFoundException。改成默认 compile 作用域，让它打进WEB-INF/lib。启动日志里如果能打印出数据源初始化和 Mapper 注册条数，说明 Spring 容器起来了。

5.2 用接口脚本验证四角色权限闭环

手工点页面容易漏，写个脚本把四种角色的关键接口都过一遍，比点一遍页面可靠：

# 管理员登录后应能删社团；社长登录后删同一个社团应返回 403 curl -c admin.txt -d "username=admin&password=123456" http://127.0.0.1:8080/club/login curl -b admin.txt -X POST http://127.0.0.1:8080/club/club/delete?id=1 curl -c shezhang.txt -d "username=sz001&password=123456" http://127.0.0.1:8080/club/login curl -b shezhang.txt -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:8080/club/club/delete?id=1 # 期望输出 403，若返回 200，说明拦截器白名单或角色判断写漏了

重点验证三条线：越权删除是否被拦、教师审核后状态是否落库、社长被驳回后能否重新提交。三条都通过，权限模型就没有结构性漏洞。

5.3 用 JMeter 摸一下登录接口的承接能力

毕设系统不需要高并发，但答辩老师问「能扛多少人同时登录」时，有个数字比空口说强。用 JMeter 建一个线程组，50 个并发循环 10 次打登录接口，观察平均响应和错误率：

50 并发出现错误时，把 Druid 的maxActive从 20 提到 50，再加maxWait=3000，错误率能压下去。登录接口反复查用户表，可以给用户查询加一级本地缓存，命中后不再走数据库。测完记得清掉压测产生的脏数据，别把测试账号和假社团留在演示库里。最后一条经验：答辩前把数据库导出留一份备份，演示环境当场崩了能五分钟恢复。

本文还有配套的精品资源，点击获取