SpringBoot+Vue+MySQL社团管理系统：从0到1完整开发与毕设实战

看到这个标题，我第一反应是：这就是当年我毕业时花费大量时间摸索，最终做成的那类项目。SpringBoot + Vue + MySQL 的社团管理系统，可以说是我计算机毕业设计路上最典型、也最有价值的一课。这篇文章不打算只贴几张截图和一段“运行成功”的日志，我准备把整个项目的完整脉络、关键代码、实现思路和踩坑记录都摊开讲清楚，目标只有一个：让你照着做，能少吃一点我没少吃过的亏。

我做这套系统的初衷其实很简单：选一个既有业务场景、又有技术含金量、还能在有限时间内完成的课题。社团管理系统在高校里非常普遍，功能边界清晰，涉及用户、社团、活动、通知、审批等多个真实业务模块，前后端的技术点都能覆盖，非常适合作为毕业设计的切入方向。无论你是刚拿到题目准备开工，还是已经写到一半遭遇瓶颈，这篇文章都值得从头到尾看一遍。

1. 整体设计与需求拆解，一张图想清楚所有功能模块

1.1 核心需求到底是什么

在动笔写代码之前，我先把“社团管理”这个题目的核心角色和场景盘了一遍。使用这套系统的人无非三类：系统管理员、社团负责人（社长/部长） 和 普通学生用户。三类角色的需求差异非常大，刚开始很容易被“管理”两个字带偏，以为只管社团信息就行了，实际根本不是这么回事。

普通学生要的是：查社团、加入社团、查看活动、报名活动、查看自己的加入记录，不需要什么花哨功能。社团负责人的需求是：管理自己的成员、发布活动、审核新成员加入申请、发布公告。系统管理员的需求最重：要审批社团创建、管理全站用户、处理举报或违规内容、统计全校社团数据。

所以我把整个系统拆成了五个核心模块：用户认证与权限管理、社团管理、成员管理、活动管理、公告系统。再加上一个全局消息通知机制，串联起所有模块。这个模块划分是我反复调整过的结果，第一次设计时候我加了很多用不上的功能，比如在线聊天、文件云盘，后来才发现毕设项目时间本来就紧张，把无关功能删干净，反而能集中精力把主链路的代码质量做上去。

1.2 技术选型背后的思考和取舍

技术选型那段我纠结了挺久，这里把理由完整说一遍，因为选型逻辑比技术本身更重要。

后端选择 SpringBoot 而不是更轻的 Servlet + JDBC，核心原因是：SpringBoot 把繁琐的配置都封装好了，起步快，尤其适合一个人单兵作战的毕设项目。用 SpringBoot 可以用很少的配置把 Web 容器、数据源、事务、JSON 序列化全部跑起来，省下大量时间。Spring Security + JWT 做权限控制和接口鉴权，这套组合全称叫“无状态认证”，场景很贴合前后端分离的项目，JWT 用一个签名令牌完成身份识别，服务器不需要存 Session 状态，天然适合多端扩展。

前端选择 Vue 2 + Element UI，主要是考虑到上手曲线平缓、中文文档和社区资源最多、坑基本都被别人踩平了，而且 Element UI 组件库本身就把后台管理系统的常见界面组件做得非常完善，表格、表单、弹窗、分页都有现成组件，写前端界面时候能节省大量时间。再加上 Vue Router 做前端路由、Axios 做 HTTP 请求、Vuex 做全局状态管理，整套体系配合得非常顺。

数据库这块用 MySQL 是几乎所有毕业设计项目的主流选择。关于版本我多说一句，我本地用的是 MySQL 8.0，实际部署到服务器用的是 5.7，但用 ORM 框架结合得好的话，版本差异暴露出的问题非常少。存储引擎统一使用 InnoDB，因为社团管理系统的业务核心就是事务操作，比如报名活动必须同时更新报名表和活动人数统计，这个写入操作必须放到同一个事务里，否则极易出现数据不一致，InnoDB 对事务支持是 MyISAM 完全没法比的。

1.3 选型对比的直观清晰表格

经常有同学问我用 JSP 实现行不行、用 Django 行不行、用 SQLite 行不行，我就直接把这些方案的对比列出来给你看：

我最后还是锁定了第一行方案。还有一个隐藏原因：答辩时老师最想看的不只是系统能不能跑，而是你对架构是否真正理解。SpringBoot + Vue + MySQL 这种分离式架构天然就能讲出清晰的系统设计故事，我答辩时候从“接口请求流”切入，一步步把整个调用链讲明白，老师听得连连点头。

2. 数据库设计与核心表结构，系统的地基必须一次打对

2.1 全局表关系构思

数据库设计是最容易返工的一环，也是我花费时间最多的一环。经过反复思考，我最终设计了 7 张核心表：用户表、社团表、社团成员表、社团分类表、活动表、活动报名表、公告表。后面还按需加入了反馈表，但核心业务全部集中在这 7 张表里。

画 ER 图之前，我先把关系理顺了：

• 一个用户（学生）可以申请加入多个社团，一个社团有多个成员，所以用户和社团之间是多对多关系，需要中间的成员表承接；
• 一个社团拥有多个活动，一个活动只能归属一个社团，所以社团和活动是一对多关系，活动表里存社团外键；
• 用户的报名记录和活动之间是一对多关系，所以设计独立的报名表；
• 公告和社团之间也是一对多关系。

这个关系模型可以用思维导图方式手绘，但真到了建表阶段，重点还得看字段设计，字段设计一旦失败，后面索引优化和业务扩展都会受连带影响。

2.2 核心表字段设计实战示例

这是我自己项目里最核心的三张表，直接拿出来共享，每张表都经过了后面业务逻辑的验证，细节比大多数网上的教学示例更严谨。

用户表 user：

社团表 club：

活动报名表 activity_signup：

这个字段设计我用得很顺手，这里特别提两个细节：一，member_count 字段属于冗余字段，用空间换性能，每次查询社团列表要展示成员数时，直接读这个字段就行，不需要去成员表做 count 聚合；二，所有表都带 status 字段，用于软删除和审核流程，未来做数据和逻辑处理时能节省大量工作量。

2.3 避免三大建表常见致命错误

建表时的很多习惯非常重要。第一，永远不要用联合主键代替单字段主键，我的成员表刚开始把 user_id 和 club_id 联合设为主键，后面做活动报名统计时发现极为别扭，改成独立主键加唯一索引之后，问题瞬间解决。第二，时间字段建议全部用 datetime，不要用 timestamp，因为 timestamp 范围只到 2038 年，一看就是隐藏雷。第三，外键字段类型必须和被关联主键类型完全一致，我在分类表关联时一度把 category_id 写成 varchar，导致 JOIN 查询时转换开销巨大，查询速度明显下降。

3. 后端核心实现与关键代码，把每个业务链路的逻辑彻底讲透

3.1 项目工程结构与分层思想

后端工程我采用标准的 Maven 多包单模块结构，这点非常关键。代码包划分如下：

text复制src/main/java/com/example/club/
├── config/         // 全局配置类
├── controller/     // 控制层，接收前端请求
├── service/        // 业务逻辑层
├── mapper/         // MyBatis数据访问层
├── entity/         // 数据库实体映射
├── dto/            // 数据传输对象
├── vo/             // 视图返回对象
├── utils/          // 工具类
├── exception/      // 全局异常处理
└── security/       // Spring Security 相关配置

这里有一个非常重要的设计原则：接口层不能把数据库实体直接返回给前端。比如用户实体里有 password 字段，如果直接返回，就等同把密码明文泄露了。我为此专门建了 VO（视图对象）来承接返回前端的数据结构，比如 UserVO 会剔除敏感字段，额外组装一些展示需要的字段，例如加入社团的时间、活动报名状态等。这个习惯在我后来写论文和面试时都是很好的加分点。

3.2 JWT 认证与接口权限控制的完整设计

我先从认证鉴权讲起，因为后端所有接口都建立在这个基础上。方案是 Spring Security + JWT，流程这里完整讲一遍。

用户提交账号密码后，后端调用认证管理器验证身份，验证通过则生成一个 JWT 令牌返回给前端。JWT 的结构由三部分组成：Header（声明算法）、Payload（携带用户信息）、Signature（签名）。后续前端每次请求都会在 HTTP Header 中携带 Authorization: Bearer <token>，后端过滤器解析令牌、校验签名、提取用户信息、存入安全上下文。

生成 JWT 的关键配置我这里给你一个可用的代码示例：

java复制// JWT 工具类核心方法
public class JwtUtil {
    // 密钥，实际项目中必须放入配置文件，不能硬编码
    private static final String SECRET = "your-secret-key-change-it";
    private static final long EXPIRATION = 24 * 60 * 60 * 1000; // 有效期24小时
    
    // 生成令牌
    public static String generateToken(String username, String role) {
        return Jwts.builder()
                .setSubject(username)
                .claim("role", role)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRATION))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }
    
    // 解析令牌
    public static Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

权限控制的思想上是这样：自定义一个 JwtAuthenticationFilter，继承 OncePerRequestFilter，在每个请求进来时先从 Header 取令牌，解析成功后把用户信息塞进 SecurityContextHolder。然后在接口上用 @PreAuthorize("hasRole('ADMIN')") 注解控制访问权限，只有管理员角色能调用社团审批接口，只有社团负责人能操作本社成员管理。

实测下来，这套权限链路最大的好处是，权限逻辑完全和业务逻辑解耦，不需要在每个 Controller 里不断判断用户身份，也很好地服务了多角色在线协作的场景。配置文件里还需要把 /api/auth/** 路径设置成完全放行的。

3.3 社团创建审批与成员管理的落库细节

社团创建功能，是整个系统中业务逻辑最曲折的接口。普通用户填写社团名称、分类、简介后提交，数据进入 club 表且 status 字段是 0（待审核）。管理员通过后，status 变为 1。但这里有个坑，管理员审核通过后，创建人会自动成为该社团的社长，并生成一条社团成员记录，成员角色字段为 LEADER。

这意味着，审批接口必须在一个事务里执行两步写入操作：第一步，更新社团状态；第二步，插入成员表记录。任何一步失败，整个事务必须回滚。我在实现中通过 @Transactional 注解搞定，由于用的是 Spring 的声明式事务，代码很短，逻辑却非常严谨。

成员管理的核心接口是申请加入社团。用户点击加入后，往社团成员表插入一条状态为 PENDING（待审核）的记录。社长看到申请列表后，逐个审核，批准后状态改为 ACTIVE。这里我偷偷用了数据库层面的唯一索引来兜底：(club_id, user_id) 建唯一索引，同一个用户只能对同一个社团有一条申请记录，如果重复申请，数据库会直接抛 DuplicateKeyException，服务层捕获后统一返回友好提示“请勿重复申请”，防止并发情况下的重复加入问题。这个体验优化虽然小，但在真实验收演示时很加分。

3.4 活动发布与报名功能的并发防超卖处理

活动模块是老师和评委最看重的亮点模块之一，因为它的业务逻辑中包含典型的并发一致性挑战。活动表中有两个字段很关键：max_people（最大人数限制）和 current_people（当前已报名人数）。

发布活动的逻辑是：社长填写活动名称、时间、地点、人数上限，系统写入活动表，状态默认 DRAFT（草稿），再手动发布后改为 PUBLISHED。学生端只展示已发布的活动。

真正棘手的是报名接口。如果直接用：

sql复制UPDATE activity SET current_people = current_people + 1 WHERE id = ?

在多用户同时请求时，会发生超卖问题，所有请求都读到同一个 current_people 值，最后报名人数超出 max_people。

解决方案我用了两种组合拳：第一，UPDATE ... WHERE current_people < max_people 这种条件更新语句放在事务中执行，如果受影响行数为 0，说明活动名额已满，直接返回“活动人数已满”；第二，在代码层面使用分布式式乐观锁，即更新前先查版本号，更新时比对版本号，如果不相等则重新加载或直接报错。具体代码如下：

java复制@Transactional
public Result signUp(Long activityId, Long userId) {
    // 条件更新，原子操作防止超卖
    int updated = activityMapper.increaseCurrentPeople(activityId);
    if (updated == 0) {
        throw new BusinessException(500, "活动名额已满");
    }
    // 插入报名记录
    signupMapper.insert(new ActivitySignup(activityId, userId, new Date()));
    return Result.success("报名成功");
}

对应 SQL：

sql复制UPDATE activity 
SET current_people = current_people + 1 
WHERE id = #{activityId} AND current_people < max_people

这个方案实测下来效果很稳，高并发场景压测也没有出现超卖数据。数据库事务本身提供了行级锁，条件更新保证并发环境下只有一个人能修改成功，这个思路在真实生产系统中也完全可行。

3.5 基于 MyBatis-Plus 的数据访问层优化

数据访问层我选用了 MyBatis-Plus，而不是原生 MyBatis。原因非常简单：它对单表的 CRUD 操作做了极好的封装，直接继承 BaseMapper 接口就能自动获得 insert、selectById、updateById、deleteById 方法，能省掉非常多的重复 XML 编写。同时它还内置了分页插件，这是后台管理列表页的灵魂组件。

分页插件配置也简单：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

复杂多表查询仍需编写自定义 SQL。比如活动列表展示时，前端需要展示社团名称而不是社团 ID，就需要活动表关联社团表查询。MyBatis-Plus 也支持在 Mapper 接口方法上直接写注解 SQL，思路清晰，不搞复杂 XML 文件：

java复制@Select("SELECT a.*, c.club_name FROM activity a LEFT JOIN club c ON a.club_id = c.id WHERE a.status = 1 ORDER BY a.created_at DESC")
List<ActivityVO> selectPublishedActivities();

我整套系统跑下来，发现 MyBatis-Plus 的代码风格和团队里其他成熟项目也一致，写起来效率明显高一截，推荐毕设项目直接采用。

4. 前端界面与交互实现，从路由到组件到请求的完整链路

4.1 前端工程结构与路由权限设计

前端使用 Vue CLI 搭建工程，目录结构是我按照通用后台管理系统模式组织的：

text复制src/
├── api/           // 接口请求封装模块
├── assets/        // 静态资源
├── components/    // 公共组件
├── router/        // 路由配置
├── store/         // Vuex状态管理
├── views/         // 页面视图
│   ├── admin/     // 管理员页面
│   ├── club/      // 社团相关页面
│   ├── activity/  // 活动相关页面
│   ├── user/      // 个人中心页面
│   └── login/     // 登录注册页面
├── utils/         // 工具函数（含Axios封装）
└── App.vue

路由权限设计是前端一个很重要的环节。用户未登录时只能访问登录页，登录后根据角色动态生成可访问的路由表。我的方案是，在路由配置中用 meta.roles 字段标识该路由允许哪些角色访问，然后在全局前置守卫里判断：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  if (!token && to.path !== '/login') {
    next('/login');
  } else if (token) {
    const role = localStorage.getItem('role');
    if (to.meta.roles && !to.meta.roles.includes(role)) {
      next('/403');
    } else {
      next();
    }
  } else {
    next();
  }
});

注意暴露给用户的 localStorage 是可以被手动修改的，所以前端路由守卫只作为体验优化，真正的权限控制必须在后端接口层面实现，前端只是把越权页面拦截在前面，绝不替代后端安全校验。

4.2 Axios 封装与 Token 自动携带

Axios 封装是前端能顺畅工作的关键一环。我在 utils/request.js 文件中统一创建 Axios 实例，配置了基础 URL、超时时间，以及核心的拦截器逻辑：

javascript复制const service = axios.create({
  baseURL: '/api',
  timeout: 10000
});

// 请求拦截器：自动携带Token
service.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  if (token) {
    config.headers['Authorization'] = 'Bearer ' + token;
  }
  return config;
}, error => {
  return Promise.reject(error);
});

// 响应拦截器：统一处理业务错误
service.interceptors.response.use(response => {
  const res = response.data;
  if (res.code !== 200) {
    if (res.code === 401) {
      localStorage.removeItem('token');
      router.push('/login');
    }
    Message.error(res.message || '系统错误');
    return Promise.reject(new Error(res.message));
  }
  return res;
}, error => {
  Message.error('网络异常，请稍后重试');
  return Promise.reject(error);
});

这段封装的收益非常大，所有页面调接口时完全不用关注 Token 携带和错误处理，只专注于业务数据即可。我后来接手其他项目时也一直沿用了这套实践。

4.3 核心页面实现要点：社团列表与活动报名

社团列表页是一个典型的信息展示加操作页，里面用了 Element UI 的卡片布局和弹窗组件。我在页面初始化时调用了社团列表接口，传入当前页码和每页条数，后端返回数据后用分页组件承载数据，这个交互方式非常高效。

活动详情页是另一个核心页面。用户进入后，前端先调用活动详情接口，拿到活动信息、报名状态、当前人数上限，然后根据状态动态渲染“立即报名”或“已报名”按钮。这里有一个容易忽略的细节，按钮的状态判断不能只用活动状态判断，还需要根据当前用户是否已报名来渲染，这个信息我在后端返回时通过一个字段 signup_status 一并返回，避免了前端额外又一次请求，体验更好。

4.4 状态管理 Vuex 的合理应用边界

很多同学喜欢把所有数据全部塞进 Vuex，其实这是过度设计。我采取的策略是：只把全局性的用户信息、登录状态、角色信息放进 Vuex，比如：

javascript复制const store = new Vuex.Store({
  state: {
    userInfo: null,
    role: '',
    token: ''
  },
  mutations: {
    SET_USER_INFO(state, info) {
      state.userInfo = info;
    },
    SET_ROLE(state, role) {
      state.role = role;
    }
  },
  actions: {
    // 登录成功后调用
    async loginAction({ commit }, formData) {
      const res = await loginApi(formData);
      const { token, userInfo } = res.data;
      localStorage.setItem('token', token);
      localStorage.setItem('role', userInfo.role);
      commit('SET_TOKEN', token);
      commit('SET_USER_INFO', userInfo);
      commit('SET_ROLE', userInfo.role);
    }
  }
});

像某个社团的成员列表、活动报名详情这类页面级数据，我直接在每个页面组件内部维护，不需要全局共享就不放进 Vuex，减少状态耦合。这样的设计让我后期维护省了大量时间。

5. 答辩展示、论文撰写与部署上线的完整链路

5.1 部署完整流程，用最稳妥方式让系统跑起来

部署这块可以说是整个项目中最容易出意外的地方。我采用前后端分离部署方式，前端打包成静态文件，交 Nginx 托管；后端打成 JAR 包，运行在服务器上；MySQL 独立部署。

前端构建命令大家都很熟悉了：

bash复制npm run build

生成的 dist 目录上传到服务器后，配置 Nginx 转发规则。这里要给一个前后端分离场景下的通用 Nginx 配置：

nginx复制server {
    listen 80;
    server_name your-domain.com;
    
    # 前端静态资源
    root /var/www/club-frontend;
    index index.html;
    
    # 前端路由 history 模式回退
    location / {
        try_files $uri $uri/ /index.html;
    }
    
    # 后端接口反向代理
    location /api/ {
        proxy_pass http://localhost:8080/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

注意 try_files 指令非常重要，Vue Router 如果是 history 模式，刷新某个子路由时没有这个配置就会直接 404，这是我踩过一次就记住的坑。

后端打包成可执行 JAR：

bash复制mvn clean package -DskipTests

然后通过 nohup java -jar club-api.jar > app.log 2>&1 & 命令启动，日志输出到文件中便于排查问题。更专业的做法是写成 Systemd 服务，但毕设阶段用 nohup 完全够用，我最后为了展示管理能力，还把后端环境做成了 Docker 镜像，这条线可以作为加分点简单提一下。

5.2 论文结构撰写技巧，让正文有足够的血肉支撑

论文写得好的前提是系统实际实现得有内容可写。我当时的论文结构是这样安排的：

第一章 绪论：研究背景以高校社团数量增长和传统管理方式低效作为切入点，研究意义分理论意义和实践意义两条线，国内外研究现状梳理从纸质管理到信息化管理的发展脉络；第二章 相关技术介绍：分别介绍 SpringBoot、Vue、MySQL、前后端分离架构；第三章 系统分析：需求分析加可行性分析；第四章 系统设计：总体架构、功能模块设计、数据库设计；第五章 系统实现：按功能模块逐步描述实现过程，结合核心代码和界面截图；第六章 系统测试：功能测试用例表格加测试结论。

论文到了系统实现章节，一定要把核心逻辑写清楚。比如我描述活动报名功能时，不只是说“用户可以报名”，而是把条件更新 SQL 的防超卖机制写进正文，把事务边界画清楚，把异常处理方案写明白，这些细节才是论文的加分亮点。测试章节要制作一个规范的测试用例表，包含测试编号、测试模块、预置条件、操作步骤、预期结果、实际结果、结论，这个看似刻板，但评分人很喜欢一目了然的效果。

5.3 答辩演示时的操作流程与项目特色讲解

答辩环节，我准备的实操演示顺序经过特别设计，每步都和论文互相呼应。第一步，演示登录功能，说明 JWT 认证过程，强调无状态、跨平台的特点；第二步，演示三个角色的不同权限菜单，直观展示 RBAC 权限设计；第三步，重点演示活动报名模块，说明并发控制策略；第四步，演示社团创建审批流程，完整走完从用户提交到管理员审核到成员自动关联的全链路；第五步，展示数据库中的数据变化，用 SQL 查询证明写入逻辑正确。

这里给一个容易被忽略的建议：答辩前一定要准备真实测试数据，至少准备两三个社团、五六个活动、十几个测试用户，界面效果会丰满很多。空数据库演示时页面满屏空白，观感上会瞬间减分。

6. 实际操作中的高频问题排查与避坑心得

6.1 后端启动失败与数据库连接异常专场

后端启动时最常见的异常就是数据库连接失败。报错 Communications link failure 时，第一反应不是去改代码，而是按这个顺序排查：第一步，确认 MySQL 服务是否启动，命令行执行 systemctl status mysqld；第二步，确认数据库连接配置，application.yml 中的 host、port、database、username、password 逐一核对；第三步，远程数据库情况下确认防火墙是否放行 3306 端口；第四步，确认账号授权。

依赖冲突问题同样容易出现，我用 Spring Boot 2.7 版本搭配 MyBatis-Plus 时遇到过启动周期性报错的情况，最终定位是 starter 版本和 mybatis-plus 版本不兼容。建议直接使用官网推荐的版本组合：SpringBoot 2.7.x 对 MyBatis-Plus 3.5.x，这两个版本组合已经被大量项目验证过。

6.2 前端跨域与代理配置的极容易踩坑点

跨域问题在前端分离架构里几乎必然碰到。浏览器打开页面后接口请求报 CORS 错误，解决方案有两种。第一种，开发环境下配置 Vue CLI 的代理：

javascript复制// vue.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
};

这样开发环境的请求路径 /api/login 会被代理到后端服务器的同路径接口，避免跨域。第二种，生产环境用 Nginx 反向代理，如上一节中的配置，前后端共用同一个域名，从根本上规避跨域问题。开发环境尽量不要依赖后端 CORS 全局配置，容易埋下安全漏洞。

6.3 生产环境的优化方向与实际心得

毕设做到上线可运行的程度已经及格，但想做出亮点，我建议优先优化这两方面：一是接口性能优化，列表页加上后端字段筛选排序，分页查询只返回必要字段；二是安全优化，密码加密统一用 BCrypt，前端提交的字段在后端全部做参数校验，登录接口要加验证码机制。

我自己在实际操作中发现，加一个简单的图形验证码，对答辩的加分远超想象，因为它展示了全面的安全思维。另外，后台管理系统的日志框架建议统一使用 SLF4J + Logback，并在关键操作（审批通过、活动发布、成员审核）的 Service 方法中记录日志，后续论文写系统测试和运维时很有用处。

7. 关于选题与时间规划的最后忠告

这种规模的毕设项目，我给一个合理的时间分配方案：第一周做需求分析和数据库设计，第二周完成后端基础框架和认证模块，第三四周完成核心业务接口，第五周完成前端页面联调，第六周进行整体测试和 Bug 修复，最后一周准备论文和答辩材料。这个节奏我已经帮多名学弟学妹验证过，完全可以在六周内走完整个周期。

如果再让我做一次，我会把项目从一开始就纳入 Git 版本管理，每次功能开发都提交一次，出现问题时可以快速回滚，写论文时查提交记录还能辅助回忆开发过程。我还建议把接口文档用 ApiPost 或 Swagger 管理起来，后端接口一多，没有文档的维护成本会呈指数级上升。

做毕设这几个月是我大学阶段成长最快的一段时间，回过头看，真正的收获不是那个最终能运行的 JAR 包，而是你终于有能力把一整个从无到有的项目完整落地。别人的代码始终是别人的，只有自己一行一行敲出来的，碰到问题分析、解决、复盘的整个闭环，才是真正属于你的工程能力。这套社团管理系统在技术上完全够得上级别，业务上又具备明确的现实意义，你照着以上思路一步步实现，毕业答辩时一定能给出一个让老师眼前一亮的系统。