Spring Boot+微信小程序高校社团管理系统实战指南-代码聚汇网

看到“Java springboot基于微信小程序的高校社团管理系统”这个标题，多数人第一反应就是：毕业设计。确实，这几乎是计算机专业毕设题里的常青树。但你仔细拆一下，会发现这个题目远不止“做个系统交个差”那么简单。它天然覆盖了后端接口开发、小程序前端、数据库建模、权限控制、文件上传、微信登录鉴权、项目打包部署这一整套全栈链路，而且无论是从技术面试的考点密度，还是从实际业务落地角度，都相当能打。

这篇博客我就从“拿到这个题目该怎么落地”的角度，把整个项目从技术选型、数据库设计、接口规划到小程序端联调、常见坑位，一整套讲清楚。无论你是正在做毕设的学生，还是想拿一个完整体面项目去面试的求职者，这篇内容都能让你少走很多弯路。

1. 项目整体设计思路：先搞清楚这系统到底要管什么

1.1 核心业务角色与需求拆解

高校社团管理系统，表面上看是“管理社团”，本质上是解决三个角色之间的信息流转和审批协作问题：系统管理员、社团负责人、普通学生用户。把这个模型想清楚，数据库表和接口设计就顺了。

先从业务流程看，高校社团的日常运转大体是：学生注册登录 → 浏览社团列表 → 申请加入社团 → 通过审核成为社员 → 社团发布活动 → 学生浏览活动并报名 → 活动结束 → 围绕活动和社团产生通知公告。这里面牵涉的不只是CRUD，更关键的是审批流状态切换。比如学生提交申请后，社团管理员要能收到申请、审核通过或驳回；活动发布后，可能还需要社团内部审核或系统管理员审核。

角色层面再拆分一下：

普通学生：注册、登录、浏览社团、申请加入、查看个人社团列表、浏览活动、报名/取消报名、查看报名记录、修改个人资料。
社团管理员（通常是社长或骨干）：管理本社团基本信息、审核入社申请、发布活动、查看活动报名名单、发起通知。
系统管理员：审核社团创建申请、管理所有用户、管理所有社团、发布全局公告、数据统计。

这三种角色不是平行关系，而是层层嵌套。普通用户申请创建社团后，提交到系统管理员审核，审核通过后该用户就变成社团管理员。一个用户还可以同时是多张表的关联对象。这些关系一旦在表设计阶段没理清楚，后面写接口时就会出现“查不到数据”和“越权访问”这类经常让人崩溃的问题。

1.2 为什么选 Spring Boot + 微信小程序这套组合

说实话，做毕设或练手项目，可选的技术栈有一大把。但 Spring Boot 加微信小程序这个组合，在当下依然是最稳、最适合学生和初级开发者拿来做完整项目的选择，原因有三：

第一，Spring Boot 本身降低了企业级 Java 开发的门槛。它把繁琐的配置封装成约定，让你只需要关注业务本身，不用在一堆 XML 配置文件里挣扎。同时它也是目前国内中小型公司使用最广泛的后端框架之一，学了不亏。

第二，微信小程序可以说是中国高校场景里覆盖率最高的“App”。学生不需要额外下载客户端，微信里扫码就能用，天然适合社团这种低频但分散的使用场景。而且小程序端原生开发上手曲线相对平缓，WXML 和 WXSS 跟 HTML/CSS 高度相似，会前端基础就能快速进入状态。

第三，这套架构天然具备“前后端分离”特征。小程序是纯前端，Spring Boot 是纯后端接口，两者通过 HTTP + JSON 通信。这种模式不仅是目前企业开发的主流形态，也是面试官最希望听到你真正理解的东西。你可以在项目描述里完全自信地写上“本系统采用前后端分离架构，后端提供 RESTful API，前端通过微信小程序原生框架实现”。

这里我要特别强调版本选择。看到热词里有“springboot版本太高”这一条，我猜已经有人踩坑了。做这种项目，建议不要一上来就追新。尽量使用 Spring Boot 2.x 系列（比如 2.7.x），配 JDK 8 或 JDK 11，这是最稳妥、教程最多、问题最容易被搜到答案的组合。Spring Boot 3.x 虽然也已经很成熟，但部分三方依赖（比如一些代码生成器、旧版 MyBatis 整合包、部分国产中间件）尚未完全适配，学生项目一旦踩到兼容性坑，排查起来非常痛苦。除非你已经有比较扎实的 Java 基础，否则没必要在版本兼容性上给自己加戏。

1.3 项目打包内容和目录规划

你标题里有个很关键的短语，叫“源码+文档+运行视频+讲解视频”。这其实已经揭示了这类项目的标准交付物形态。也就是说，这不仅仅是一个程序，更是一套“可讲解、可演示、可打分”的完整成果物。

所以在动手写代码之前，我强烈建议你先按这个思路来规划项目的目录结构和配套资料：

后端工程（springboot 项目，标准 Maven 目录结构）。
小程序前端工程（微信开发者工具可直接导入的目录）。
数据库初始化脚本（建库建表语句 + 部分演示数据）。
项目文档（开题报告 / 任务书 / 需求分析 / 数据库设计 / 系统演示脚本之类，按学校要求来）。
运行视频（录屏：从启动后端到小程序模拟器正常跑通）。
讲解视频（PPT + 核心代码讲解，通常8-15分钟左右，讲需求、讲架构、讲亮点、讲演示）。

如果一开始就按这个总盘子去安排时间，而不是只埋头写代码，你会轻松很多——因为文档和视频完全可以从开发过程中直接沉淀素材，最后一天不用熬夜补材料。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据库设计与核心功能模块拆解

2.1 核心数据表怎么设计

数据库设计是这种全栈项目里最值得花心思的环节。表设计好了，接口就是往里面填数据；表设计得乱，后面每个查询都像在走迷宫。社团管理系统我建议至少包含下面这几张表：

用户表（sys_user）：主键、微信 openid、昵称、头像、真实姓名、学号、学院、专业、手机号、角色、创建时间。
社团表（club）：主键、社团名称、社团简介、社团图标、指导老师、成立时间、所属分类、状态（待审核/已通过/已拒绝）、创建人ID、活动人数上限等。
用户-社团关联表（user_club）：主键、用户ID、社团ID、加入时间、身份（普通成员/社团管理员/社长）、审核状态（待审核/已加入/已拒绝/已退出）。
社团活动表（activity）：主键、社团ID、活动标题、活动封面、活动详情、活动地点、活动开始时间、活动结束时间、报名截止时间、报名人数上限、当前报名人数、状态（草稿/已发布/已结束/已取消）、创建人。
活动报名表（activity_join）：主键、活动ID、用户ID、报名时间、状态（已报名/已取消/已签到）。
通知公告表（notice）：主键、类型（系统公告/社团通知）、发布人、标题、内容、关联社团ID、发布时间。

这里有几个容易犯错的地方，我在带很多人做类似项目时反复见到，提前帮你避雷：

第一，用户与社团是多对多关系，必须用中间表。有的同学会把“所属社团”做成用户表里的一个字段，一个学生只能在一个社团里，这显然不符合真实场景。加入中间表后，用户-社团的申请状态也自然有了归属地，不用挤在用户表里。

第二，活动报名表要有独立的状态。一个用户报名了一个活动，后面也可能取消；活动当天可能需要签到。这些状态变化都是有时间线的，所以状态字段、时间字段必须保留，不要省。

第三，角色权限不建议做成复杂的 RBAC 表。学生项目里把角色放在用户表一个字段就够了（比如 0-学生，1-社团管理员，2-系统管理员），把“社团身份”和“系统角色”两套东西分开处理。过度设计在毕设里不是加分项，它只会让代码复杂化。

2.2 业务模块怎么划分

按业务逻辑把整个系统拆分，大致可以分为六个模块：

用户中心模块：微信登录、注册、资料修改、我的社团、我的活动。
社团模块：社团列表、社团详情、创建社团申请、审核社团（管理员）、申请加入社团、审核入社申请。
活动模块：活动列表、活动详情、发布活动、编辑/取消活动、报名活动、取消报名、查看报名名单。
通知模块：系统公告列表、社团通知发布与查看。
管理后台模块（小程序内嵌管理员功能或单独的后台页面）：用户管理、社团管理、活动管理、数据统计。
文件模块：图片上传接口（社团图标、活动封面），配合腾讯云 COS 或本地存储。

在真实的毕设项目里，我通常把管理后台做进小程序一个“管理”页面入口，根据用户角色动态显示不同菜单。这样比单独再做一个 Vue 管理后台工程要省力得多，而且微信小程序天然可以实现移动端管理，场景上也说得通。如果你时间充裕、想让项目看起来更“完整”，再加一个基于 Vue3 + Elment Plus 的 Web 管理后台也完全可以，但从毕设答辩和演示角度看，小程序内嵌管理功能已经足够拿分。

2.3 状态机的设计思路

这个系统里有三处明显的状态流转，你在写接口时一定要用状态机思维去约束，否则很容易出现“已审核的申请还能再审核”“已结束的活动还能报名”这类逻辑漏洞。

社团申请状态：待审核（0）→ 已通过（1）/ 已拒绝（2）。
用户入社状态：待审核（0）→ 已加入（1）/ 已拒绝（2）/ 已退出（3）。
活动状态：草稿（0）→ 已发布（1）→ 已结束（2）/ 已取消（3）。

每个状态的合法性转移只有几条路径。比如报名活动时，必须先判断活动状态是已发布，且当前时间在报名截止前，且活动报名人数未满，且该用户没有重复报名。把这些校验写成一个独立的方法或 Service 层逻辑，比散落在 Controller 里强得多。这也是答辩时你可以主动讲给老师听的“代码设计亮点”。

3. 后端接口设计：从登录到活动报名的完整链路

3.1 微信登录的完整过程

微信小程序登录是整个系统里最核心也最容易出问题的环节。很多人第一次做，分不清 wx.login、openid、code、session_key 这些概念，直接写代码，结果怎么调都拿不到用户身份。

登录的时序应该是这样的：

小程序前端调用 wx.login()，拿到一个临时凭证 code。
前端把这个 code 发送到自己的后端接口（比如 POST /api/user/login）。
后端拿着 code 调微信官方的 jscode2session 接口，把 code、appid、secret 一起发过去。
微信服务器返回 openid（用户唯一标识）和 session_key（会话密钥，通常不用我们处理）。
后端拿 openid 去用户表查询，如果查不到，说明是首次登录，自动创建一个新用户；如果查到了，就正常走登录逻辑。
后端生成一个自定义登录态（推荐用 JWT），返回给前端。
前端把 token 存到小程序的 storage 中，后续所有请求的 Header 里带上 token，后端通过拦截器校验用户身份。

这里有一个非常重要的经验：你拿到的 openid 才是用户的唯一身份标识，而不是 code。code 是一次性的，有效期只有五分钟，而且你不可能拿 code 去重复登录。所以“去微信服务器换 openid”这个动作必须放在后端完成，因为小程序的 appid 和 secret 是不能暴露在前端代码里的，一旦别人通过抓包拿到你的 secret，你的小程序身份就完全暴露了。

3.2 RESTful API 怎么组织

后端接口的组织方式，推荐按资源来设计，语义清晰，也方便答辩时讲。比如：

POST /api/user/login 微信登录
GET /api/user/info 获取当前用户信息
PUT /api/user/info 修改用户信息
GET /api/club/list 分页查询社团列表
POST /api/club 创建社团（提交审核）
PUT /api/club/audit 系统管理员审核社团
POST /api/club/{clubId}/join 申请加入社团
PUT /api/club/join/{id}/audit 社团管理员审核入社申请
GET /api/activity/list 分页查询活动列表
POST /api/activity 发布活动
POST /api/activity/{activityId}/join 报名活动
DELETE /api/activity/join/{id} 取消报名

这些接口都返回统一的 JSON 结构。我建议封装一个 Result 类，比如：

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    
    public static <T> Result<T> success(T data) {
        Result<T> r = new Result<>();
        r.setCode(200);
        r.setMessage("success");
        r.setData(data);
        return r;
    }
    
    public static <T> Result<T> error(Integer code, String message) {
        Result<T> r = new Result<>();
        r.setCode(code);
        r.setMessage(message);
        return r;
    }
}

所有接口的响应都走这个统一包装，前端小程序端做统一拦截处理也会非常干净。前端在请求封装里，先判断 code 是否为 200，再决定是拿 data 还是弹错误提示。这种统一的返回约定，也是企业项目里的基本要求。

3.3 JWT 鉴权与拦截器实现

因为 HTTP 接口本身就是无状态的，所以每次请求都要能识别出“你是谁”。JWT（JSON Web Token）在这儿的做法是：登录成功后，后端把用户ID、角色这些信息放进 token 里，用密钥签名返回给前端。前端之后每次请求把 token 放在 Header 的 Authorization 字段里，后端写一个拦截器，在请求进入 Controller 之前，先解析 token，把用户信息放到 ThreadLocal 或请求上下文里。

这里我建议用拦截器配合自定义注解做权限控制。比如定义三个注解：@RequireLogin、@RequireAdmin、@RequireClubAdmin，分别对应“需要登录”“需要系统管理员”“需要社团管理员”。拦截器根据当前请求路径和用户角色判断是否有权限访问。这样做的好处是，你不用在每个 Controller 方法里重复写权限校验代码，直接在方法上标注解即可，代码简洁且规范。这在求职面试时是可以拿出来讲清楚的“亮点设计”。

但要注意一个细节：JWT 的密钥不要硬编码在代码里，最好放配置文件 application.yml 里，属于常规规范。另外 token 要设置过期时间，前端在收到 401 错误时要能自动跳转登录页或重新登录。小程序的 token 过期场景常常被忽略，我后面会专门讲这个问题。

3.4 文件上传的实现细节

社团图标和活动封面肯定要支持上传。小程序的 wx.uploadFile API 会把文件以 multipart 方式 POST 到后端，后端用 Spring Boot 的 MultipartFile 接收即可。

存储方式有两种选择：本地磁盘存储或对象存储。本地存储就是服务器上建一个 upload 目录，把文件保存进去，然后把访问路径返回给前端。这种方式最简单，不需要额外配置，如果项目里没有自己的服务器，部署在自己电脑上演示也完全够用。

对象存储（比如阿里云 OSS 或腾讯云 COS）就更接近生产环境，但需要开通服务、配置 Bucket、密钥等。你在毕设阶段如果没有特殊要求，直接在本地存储就够了。不过有一点必须注意：本地存储生成的图片 URL 要求后端静态资源映射能够访问到该目录，否则小程序端图片加载不出来。Spring Boot 里的配置通常需要重写 WebMvcConfigurer 的 addResourceHandlers 方法，把 /upload/** 映射到磁盘目录。

一个小技巧是，保存文件时给文件名加上时间戳或 UUID 前缀，避免文件名冲突。比如：

java复制String originalFilename = file.getOriginalFilename();
String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
String fileName = System.currentTimeMillis() + "_" + UUID.randomUUID().toString().replace("-", "") + ext;

4. 后端实现要点：MyBatis Plus、分页与事务

4.1 持久层框架选型和配置

持久层我推荐用 MyBatis Plus，而不是纯 MyBatis，更不是 Spring Data JPA。原因很简单：MyBatis Plus 在兼容 MyBatis 习惯的前提下，内置了 BaseMapper，单表 CRUD 直接继承就有，不用写 XML，非常省时间。它的分页插件、条件构造器也很适合做列表查询场景。做毕设或中小型项目，MyBatis Plus 几乎是效率最优解。

依赖引入后，在 Spring Boot 启动类或配置类里加一个分页插件的 Bean：

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

有了分页插件之后，查询社团列表或活动列表就非常方便：

java复制Page<Club> page = new Page<>(current, size);
LambdaQueryWrapper<Club> wrapper = new LambdaQueryWrapper<>();
// 按状态过滤，按创建时间倒序
wrapper.eq(Club::getStatus, 1).orderByDesc(Club::getCreateTime);
IPage<Club> result = clubMapper.selectPage(page, wrapper);

这里有个经验：列表接口最好从第一行就设计成分页查询，哪怕现阶段数据量很小。因为小程序端通常需要上拉分页加载，你接口改成 Page 结构后，前端分页就顺理成章了。分页结果一般包含 total、size、current、records 这些字段，前端根据 total 和已加载数量判断是否还有更多数据。

4.2 事务控制与并发报名

活动报名就是典型的写操作，必须放在事务里。比如活动报名这一步，既要给 activity_join 插入一条记录，又要对 activity 表的 current_join_count 做 +1 操作，这两个动作必须同时成功或同时失败。你只需要在 Service 方法上加上 @Transactional 注解，Spring 就会帮你管理事务。

但真正容易翻车的是并发场景：两个用户同时报名，同时读到 current_join_count 为 19，活动上限 20，结果两个人都报名成功，人数超了。这在高并发场景下是致命问题。毕设项目虽然不一定要求你解决，但如果你能在答辩时主动提出来并说明解决方案，绝对是加分项。

解决方案通常就是加锁或使用数据库原子操作。其中最简单的一种就是，更新活动人数时用一条原子性 SQL，而不是先 select 再 update：

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

这条 SQL 在数据库层面保证了人数不会超上限，即使并发请求同时进来，也只会有一条更新成功。然后再根据更新行数判断是否报名成功。这个设计能体现你考虑问题是有深度的，在面试里同样很能打。

4.3 业务校验放 Service 层，别放 Controller

很多新手喜欢把判断逻辑写在 Controller 里，比如：

java复制if (activity.getStatus() != 1) {
    return Result.error("活动不在报名中");
}

这种写法最大的问题是，一旦有多个入口调用同一个业务方法（比如小程序端报名和管理员代报名），校验逻辑就会重复或遗漏。正确做法是：Controller 只做参数接收和结果返回，所有业务规则、校验逻辑放在 Service 层。比如报名活动的 Service 方法内部，依次校验：活动是否存在 → 活动状态 → 是否在报名时间内 → 人数是否满 → 是否已经报名。任何一个校验不过就抛业务异常，由全局异常处理器统一返回提示。

全局异常处理器的实现也很简单，写一个 @RestControllerAdvice 类，捕获业务异常和兜底的 Exception，转换成统一的 Result 结构返回。这样前端拿到的错误信息永远是同一个格式，不会出现“堆栈直接抛到前端”这种尴尬。

5. 微信小程序端实现细节：从登录到页面渲染

5.1 小程序项目结构和公共方法封装

小程序端建议按照页面维度组织目录，比如：

pages/login/login（登录页）
pages/index/index（首页，社团列表）
pages/club/detail/detail（社团详情）
pages/activity/list/list（活动列表）
pages/activity/detail/detail（活动详情）
pages/my/my（个人中心）
pages/manage/manage（管理面板）
utils/request.js（请求封装）
utils/auth.js（登录态管理）

其中最核心的是 request.js 请求封装。统一封装后，不用在每个页面里重复写 wx.request，同时可以统一处理 token 注入、错误码提示、登录态过期。核心代码如下：

javascript复制const request = (url, method, data) => {
  return new Promise((resolve, reject) => {
    const token = wx.getStorageSync('token')
    wx.request({
      url: 'http://localhost:8080/api' + url,
      method: method,
      data: data,
      header: {
        'Content-Type': 'application/json',
        'Authorization': token ? 'Bearer ' + token : ''
      },
      success: (res) => {
        if (res.data.code === 200) {
          resolve(res.data.data)
        } else if (res.data.code === 401) {
          // token 过期，重新登录
          wx.removeStorageSync('token')
          wx.navigateTo({ url: '/pages/login/login' })
          reject(res.data)
        } else {
          wx.showToast({ title: res.data.message, icon: 'none' })
          reject(res.data)
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络请求失败', icon: 'none' })
        reject(err)
      }
    })
  })
}

module.exports = { request }

注意这里的 baseURL。如果你是在微信开发者工具的模拟器里调试，后端在你本地电脑上，那 127.0.0.1 或 localhost 是能直接访问的。但如果你用手机真机预览，手机访问不到你电脑的 localhost，需要把 baseURL 改成电脑在局域网里的 IP，比如 http://192.168.1.100:8080/api。这也是最常被问到的问题，后面我统一列进排查清单。

5.2 登录态设计与“静默登录”

微信小程序里最理想的情况是：用户打开小程序，什么都不用做，就已经登录了。官方术语叫“静默登录”。实现方式是：启动时调用 wx.login 获取 code，后端用 code 登录，如果查不到用户就自动注册，全程不需要用户授权手机号或填表单。

所以登录页往往只是“加载中”的状态，或者干脆在首页 onLoad 时直接走登录流程。如果后端处理失败（比如网络错误），就提示用户并可重试。

关键代码：

javascript复制onLoad() {
  this.checkLogin()
},
async checkLogin() {
  const token = wx.getStorageSync('token')
  if (!token) {
    await this.login()
  }
  // 刷新用户信息
  const userInfo = await request('/user/info', 'GET')
  this.setData({ userInfo })
},
login() {
  return new Promise((resolve, reject) => {
    wx.login({
      success: async (res) => {
        const data = await request('/user/login', 'POST', { code: res.code })
        wx.setStorageSync('token', data.token)
        resolve(data)
      },
      fail: reject
    })
  })
}

从我实际经验看，“静默登录 + 业务页面自动登录”这种交互方式是最适合社团类小程序的，用户来是为了看社团和活动，不是来看注册表单的，登录环节越透明越好。

5.3 页面流转和核心交互

首页通常是一个社团列表，可以采用卡片式布局。用户点进社团详情后，看到社团介绍、成员数、组织的活动列表，以及“申请加入”按钮。申请入社后，按钮变成“已申请，等待审核”，并且不能再重复点击。

活动列表页承担了系统的核心流量。建议做成顶部 tab 切换：全部活动 / 已结束 / 我报名的。活动卡片上展示封面、标题、社团名、报名截止日期、当前报名人数/总人数。点击进入活动详情页，详情页展示活动完整内容，底部有一个固定按钮，根据状态变化显示为“报名参加”“取消报名”“活动已结束”“活动已取消”。

管理端则放在了“我的”页面里的管理入口。社团管理员登录后，能看到“入社审核”“活动管理”“报名名单”“发布通知”等菜单。这里需要注意的是页面按钮和数据的可见性要严格跟着角色走。前端靠后端返回的用户角色字段来控制显示，真正的权限校验一定是在后端接口里做的。

5.4 数据列表的分页加载

小程序列表页的分页加载是标配，不要让用户一次性看到全部数据。做法是在 onReachBottom 触底时，current + 1，再去请求下一页数据。

我建议列表数据统一用这样一个结构来管理：

javascript复制data: {
  list: [],
  current: 1,
  size: 10,
  total: 0,
  loading: false,
  finished: false
}

每次请求前判断 finished 是否为 true，如果已经加载完了就不再请求。请求返回后：

javascript复制const newList = current === 1 ? records : [...this.data.list, ...records]
this.setData({
  list: newList,
  current: res.current + 1,
  total: res.total,
  finished: this.data.list.length + records.length >= res.total
})

这个逻辑虽然基础，但出现 bug 的频率很高。最常见的问题是翻页时 current 没有重置，导致筛选条件变化后翻到第二页还带着旧的 current。所以切 tab 或筛选条件变化时，一定要记得把 current 重置为 1，list 清空。

6. 项目部署运行与常见问题排查

6.1 本地快速跑通项目的完整步骤

不管你是拿别人的源码还是自己写的，第一步要保证项目能在本地完整跑起来，这是后续一切工作的基础。我整理一份非常细的部署清单：

安装 JDK 8（如果你用 Spring Boot 2.x）和 Maven 3.6+。
安装 MySQL 5.7 或 8.0，建一个数据库，比如 club_system，把项目里的 sql 文件导入进去。
打开 application.yml，修改数据库地址、用户名、密码，确认 Redis 相关配置如果不需要就注释掉。
在后端项目根目录运行 mvn spring-boot:run，或者在 IDE 里直接启动主类。
用浏览器访问 http://localhost:8080，看到 Spring Boot 默认的欢迎页或接口文档说明，说明后端启动正常。
打开微信开发者工具，导入小程序前端目录，把 baseURL 改成 http://localhost:8080/api。
在小程序后台（mp.weixin.qq.com）申请测试号，或者你已经有正式小程序 AppID，在开发者工具里填上。
编译运行，如果能看到社团列表数据，说明整个链路已经打通。

这里提醒一个关键点：你在微信公众平台上创建的小程序或测试号，必须要在 app.js 或 utils/config.js 里把 wx.request 的合法域名配置好。开发模式下可以勾选“不校验合法域名”，但真机预览或体验版就不能这么干了。若你还没注册小程序账号，可以直接用测试号，但测试号的部分 API（比如消息推送）能力会有差别，对学生项目没有影响。

6.2 高概率遇到的报错和解决办法

这一类项目我见过的报错，来来回回就那么几个，提前告诉你，等于提前给你排雷。

第一，微信登录后拿不到 openid。最常见的锅是 appid 和 secret 不匹配，或者后端拿着 code 调微信接口时网络不通。还有一个小概率问题是，你在微信公众平台上把服务器域名配置错了，导致接口访问不了。排查这个问题的思路是，先在后端把接收到的 code 打日志，看是否为空；再手动在浏览器里模拟请求微信 jscode2session 接口，看能否返回 openid；最后确认后端请求微信接口时是否被防火墙拦截。

第二，Spring Boot 启动时报数据库连接失败或者时区错误。数据库连接失败先检查 MySQL 服务是否启动，username 和 password 是否正确。时区报错（server time zone）通常在连接字符串后面加上 serverTimezone=Asia/Shanghai 解决。另外，如果你用的是 MySQL 8.x，driver-class-name 要写成 com.mysql.cj.jdbc.Driver。

第三，微信开发者工具里报“不在以下 request 合法域名列表中”。这个就是前面说的域名校验问题。临时解决方法是右上角“详情 → 本地设置 → 勾选不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。但正式发布一定要在公众平台配置 request 合法域名，而且必须是 HTTPS。学生项目在本地演示时，可以直接勾选不校验，现场演示前记得把这个设置调好。

第四，接口请求成功但图片不显示。这个九成是文件上传后返回的是相对路径，或访问的静态资源映射没配好。你要确保返回给前端的图片是完整的 URL，且这个 URL 能在浏览器里直接访问到。如果不行，检查 Spring Boot 的静态资源映射配置有没有生效。

第五，小程序端明明调用了 wx.request，但后端没收到请求。先不要怀疑后端，先看开发者工具 Network 面板里请求的状态码和响应内容。如果请求显示 pending 或失败，多半是 IP 地址没配对。真机预览时 baseURL 写成了 localhost 是必挂的，一定改成电脑局域网 IP。

6.3 部署到服务器上的思路

如果你有云服务器，想把项目部署到公网体验，整体的思路是：后端打包成 jar，前端小程序做成体验版。后端打包命令很简单：

bash复制mvn clean package -DskipTests

打包完在 target 目录下生成 xxx.jar，上传到服务器，使用 nohup java -jar xxx.jar > log.txt 2>&1 & 方式后台运行。但是这里有个关键点，小程序生产环境的 request 合法域名必须为 HTTPS。所以你还得在服务器上配一个 Nginx，把域名解析到服务器，在 Nginx 里配置 SSL 证书，再把 /api 路径反向代理到 Spring Boot 的 8080 端口。这一步对很多学生来讲是最费时间的，建议时间不够就用“不校验合法域名”来做演示，或者在后端直接不走域名，仅用 IP 形式在局域网演示。

一个比较折中的方案是：花钱买一台轻量服务器，通过 Nginx 的 HTTP 方式反代给后端，演示时继续用开发者工具的不校验域名模式。等答辩或演示结束后，如果老师需要线上体验，你再考虑正式配 HTTPS。

6.4 演示录像与项目讲解的准备

很多同学以为做完系统就算大功告成，实际上从毕设角度讲，会演示、会讲比单纯功能跑通更重要。我的建议是准备一份约15分钟的演示脚本，按这个节奏推进：

30秒：介绍项目背景和目的。
1分钟：展示系统架构图（小程序端 → 后端 → 数据库）。
2分钟：演示学生端功能：注册登录、浏览社团、加入社团、浏览活动、报名活动、取消报名。
3分钟：切换社团管理员账号，演示入社审核、活动发布、报名名单查看。
2分钟：切换系统管理员账号，演示社团创建审核、数据概览。
1分钟：讲解核心代码亮点：JWT 鉴权、分页、事务、状态校验。
剩下时间：回答提问。

运行视频建议用录屏工具，分辨率不低于 1920x1080，帧率 30 即可。注意在录像时不要暴露后端日志中的敏感信息。讲解视频用 PPT 配合屏幕录制，说话时放慢语速，每个模块讲清“它是干嘛的、怎么设计、遇到什么问题、怎么解决的”，这个结构远比干念代码有说服力。

7. 项目亮点提炼与经验总结

7.1 在答辩时你可以主动讲清楚的亮点

一个平平无奇的社团管理系统变成“有亮点”的项目，差距通常就在下面这些点上：

第一，状态驱动的业务流设计。你能讲清楚社团审核、入社审核、活动状态之间如何流转，并说明为什么在 Service 层做状态校验，而不是前端隐藏按钮。这就是一个完整的业务闭环思维。

第二，统一鉴权方案。JWT + 拦截器 + 自定义注解，你能现场指出哪个注解控制哪类接口的权限，并说出为什么不用 Shiro 或 Spring Security（对一个中小型项目而言，它们偏重，JWT 更轻量）。

第三，数据库设计的规范化。用户、社团、活动、报名、状态，这些表之间如何通过外键逻辑（不一定要物理外键）关联，如何用中间表解决多对多，这些都是可以拿来讲的。

第四，并发安全的活动报名方案。哪怕你只是写了一条 update 语句做原子操作，也要能说出来“我考虑过并发报名导致人数超限的问题，采用了数据库原子更新的方式解决”，这句话一出口，档次就上去了。

第五，模块化与小步迭代的开发流程。你先做登录认证，再做社团模块，再做活动模块，最后加管理端，这种递进过程讲出来，说明你不是在网上找了一个源码就跑，而是真的理解开发节奏。

7.2 我对这类项目的一些个人体会

做了无数个类似管理系统项目之后，我的真实感受是，真正卡住学生的往往不是技术本身，而是“不知道下一步该干什么”和“遇到环境问题没人讲”。比如版本不兼容、端口占用、包导不进来、数据库连不上、图片加载不了……这些是消耗时间最多的部分，每一个都能让人心态爆炸。

所以我建议开发过程中尽量减少花式操作。能用 Spring Boot 2.7 + JDK 8 解决，就不要追新到 Spring Boot 3；能用原生小程序实现，就不要强行引第三方组件库；能用本地文件存储图片，就不要先折腾对象存储。先把主体流程跑通，再去考虑优化和美化。项目最基本的目标是“完整跑通”，在此基础上再让它“好看”“好讲”“显深度”。

最后分享一个小技巧。不论你在开发中遇到什么问题，第一件事不是去问别人，而是看日志。后端看控制台或 log 文件，前端看开发者工具的 Console 和 Network。90% 的问题通过日志都能定位到“是环境问题、语法问题、还是逻辑问题”，定位准确之后，解决方案基本就出来了。如果你能把自己项目里排查过的问题系统整理成文档，那这不仅是答辩时的素材，也是未来工作里非常宝贵的习惯。

这个项目做完之后，如果你有兴趣，还可以往很多方向扩展，比如导出活动报表、按分类统计社团活跃度、基于用户兴趣做活动推荐、接入订阅消息做活动提醒。每一个点展开都是一个小项目，也是你简历上很好的素材库。但不管怎么扩展，先把眼前这套基础链路做扎实，这是最重要的事。

Spring Boot+微信小程序高校社团管理系统实战指南