企业官网建设流程全解析

1. 项目概述与需求分析

1.1 这个系统到底解决了什么问题

社团管理这事儿，做过学生工作的人都懂。传统模式下，社团招新靠摆摊填表，活动报名靠群接龙，经费审批靠纸质单据来回跑，社团档案散落在各个部门的Excel里。一旦社团数量超过二三十个、成员规模到几百人，这套纯人工流程就会彻底失控——表格丢失、消息漏看、审批周期长、数据对不上，每一个坑我都踩过。

所以这个基于SpringBoot+Vue的社团管理系统，核心目标就是把这些线下流程线上化：社团创建、成员管理、活动发布与报名、审批流、公告通知、数据统计，全部收进一个Web系统里。技术上选型SpringBoot+Vue是目前Java全栈开发最主流、生态最成熟的组合，既能满足学校课程设计或毕业设计的复杂度要求，也有足够的工业级基因，学完这套东西求职时写进简历也不虚。

1.2 适合谁来学习和参考

如果你是正在做课程设计、毕业设计的在校生，这个系统的完整度正好卡在"功能够丰富但不过度膨胀"的区间——包含三个角色（管理员、社团负责人、普通成员）、四五个核心业务模块、完整的权限控制和审批流，既有讲头又有深度。如果你是在职开发者想快速搭一个后台管理类项目作为脚手架，这套前后端分离的目录结构和通用CRUD思路也能直接复用。整篇我会按实际开发流程来讲，从建表到接口到前端页面，配合我实操中踩过的坑一起说，尽量让你少走弯路。

2. 整体架构设计与技术选型解析

2.1 为什么选择前后端分离架构

我最早做这类管理系统用的还是JSP+Servlet那套，页面和服务端代码揉在一起，改个按钮样式都要重启Tomcat，多人协作时冲突不断。后来换到前后端分离，体验是质的提升。

这个项目的架构可以概括为标准的"前后端分离 + RESTful API"模式：

• 后端：SpringBoot 2.x + MyBatis + MySQL，提供纯JSON接口
• 前端：Vue 2.x + Element UI + Axios，通过HTTP请求消费接口
• 通信：JSON格式数据，JWT（JSON Web Token）做身份认证

后端通过SpringSecurity或拦截器做权限控制，Vue路由守卫控制页面访问权限，二者配合实现"接口级 + 页面级"双重保护。为什么这么设计？核心原因是社团管理系统天然有角色差异——普通成员只能看自己的报名记录，社团负责人能管理本社团的活动和成员，管理员能审批社团申请和查看全校数据。如果权限逻辑不分开，代码会迅速腐烂成一坨无法维护的if-else。

2.2 后端三大件的分工逻辑

SpringBoot负责装配一切，它内置的Tomcat让开发者省去了繁琐的XML配置，一个main方法就能把服务跑起来。MyBatis则专注于数据持久化层，它最讨喜的地方是SQL自己写，复杂查询（比如多条件筛选社团活动）完全可控，不像JPA那样容易生成一堆低效的自动SQL。MySQL是存储层，结构化的社团数据、成员关系、活动记录用关系型数据库管理最合适不过。

一个典型的请求链路我画在脑子里是这样的：Vue页面点击按钮 → Axios携带JWT发出HTTP请求 → SpringBoot的Controller接收 → Service处理业务逻辑 → Mapper接口调用MyBatis映射的SQL → MySQL返回数据 → 逐层回传 → Vue渲染页面。这条链路里，任何一个环节出问题，排查路径都很清晰。

2.3 前端技术栈的取舍

Vue + Element UI这个组合，算是后台管理系统的事实标准。Element UI的表格、表单、对话框、分页组件开箱即用，对设计能力不强的开发者特别友好。Vuex做全局状态管理（存用户信息、权限标识），Vue Router做路由控制，Axios做HTTP封装。

要特别说一句：这里不用Vue 3+Element Plus，而选Vue 2+Element UI，是因为网上开源的社团管理系统案例和学习资料绝大多数是基于这个组合的，遇到问题容易搜到答案。等你吃透了这套，再迁Vue 3无非是API差异和组件库换皮，核心的组件通信、生命周期思想完全通用。

3. 数据库设计与核心表结构

3.1 实体关系梳理

动手写代码之前，我习惯先画实体关系图。一个社团管理系统，核心实体无非这几个：用户、社团、社团成员关系、活动、活动报名记录、公告、入社申请、经费记录、分类标签。

实体间的关系可以这样描述：

这里最关键的中间表是t_club_member，它不能只存userId和clubId两个字段，还要带上角色标识（社长/副社长/普通成员）、入社时间、状态。这为后面实现"一个用户在不同社团里有不同身份"提供了数据结构支撑，这是我最初设计时漏掉、后来返工补上的重要字段。

3.2 关键表结构详解

用户表t_user是系统地基。除了id、username、password、realName、phone、email这些基础字段，我建议加上avatar（头像URL，前端存OSS或本地路径）、status（启用/禁用）。密码绝对不能明文存，我用的是BCrypt加密——具体实现后面会讲。

社团表t_club包含clubName、description（社团简介）、categoryId（所属分类）、presidentId（社长ID，逻辑外键）、memberCount（成员数冗余字段）、status（申请中/已成立/已解散）。设计冗余字段memberCount是刻意为之：列表页显示社团数量时，如果每次都用count查询，数据量大时性能会明显下降。牺牲一点存储空间换取查询速度，在这个场景下是划算的。

活动表t_activity字段较多：title、description、activityTime（活动时间）、location（活动地点）、maxPeople（报名人数上限）、currentPeople（已报名人数）、status（报名中/进行中/已结束）、clubId。这里有个并发问题——当多人同时报名时，currentPeople可能被超卖。解决方案是数据库层面加锁，我在Service层用@Transactional+ 乐观锁（update时带上version版本号），保证报名人数不超过上限。

核心SQL示例：

-- 社团表 CREATE TABLE `t_club` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `club_name` varchar(50) NOT NULL COMMENT '社团名称', `description` varchar(500) DEFAULT NULL COMMENT '社团简介', `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID', `president_id` bigint(20) DEFAULT NULL COMMENT '社长用户ID', `member_count` int(11) DEFAULT '0' COMMENT '成员数量冗余', `status` tinyint(4) DEFAULT '0' COMMENT '状态：0待审核 1已成立 2已解散', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意这里CHARSET一定要用utf8mb4，因为社团简介和活动详情里难免有emoji表情，utf8mb4才能存得下，这是很多人踩过的坑。

3.3 为什么要冗余字段而非实时统计

数据库设计时，资深开发者会考虑"读多写少"的业务特征。社团列表、活动列表属于高频读接口，而成员加入、活动报名属于低频写操作。如果每次读列表都去做COUNT(*)聚合查询，数据库压力呈指数级上升。所以我在社团表里冗余了memberCount，活动表里冗余了currentPeople，写入时通过事务保证数据一致性。

冗余字段的坑在于必须保证一致性。我用的是"事务内更新+补偿任务"双重策略：事务提交后立即更新冗余字段，若失败则记录日志，由定时任务扫描修复。学校项目规模不大，这套策略完全够用。

4. 后端核心功能实现

4.1 权限控制的完整实现方案

权限设计是这个系统最核心的部分，也是面试时最常被问到的点。我采用RBAC（基于角色的访问控制）简化版：用户-角色-权限三层模型。

后端通过自定义拦截器实现JWT认证：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录和注册接口 if (request.getRequestURI().contains("/login") || request.getRequestURI().contains("/register")) { return true; } String token = request.getHeader("Authorization"); // 解析token，验证身份和有效期 if (token == null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 将用户ID放入request上下文，供后续业务取用 Long userId = JwtUtil.getUserId(token); request.setAttribute("userId", userId); return true; } }

拦截器解决"你是谁"的问题，但没解决"你能干什么"。操作权限我通过Service层注解控制：在需要权限的方法上加自定义注解@RequirePermission("club:audit")，AOP切面根据当前用户的角色ID去查权限表，没有权限直接抛异常。

前端配合Vue Router的路由守卫，根据登录用户的role字段动态生成可访问的路由表。管理员能看到"社团审核"菜单，普通成员就看不到。这是体验层的控制，真正的安全边界必须由后端守住——前端隐藏菜单只是给人看的，后端接口校验才是安全底线。

4.2 社团审批流的设计

审批流是业务流程里最容易写乱的地方。我的做法是把状态机思想揉进去。入社申请的状态流转是这样设计的：

申请提交（PENDING） → 社长审批 → 通过（APPROVED）/ 拒绝（REJECTED）

社团创建申请的状态流转：

提交（PENDING） → 管理员审批 → 通过（ESTABLISHED）/ 拒绝（REJECTED）

具体实现时，我在申请表t_club_apply里放了apply_type字段区分是"入社申请"还是"创建社团申请"，用status字段表示当前状态。审批接口长这样：

@PostMapping("/audit") @RequirePermission("club:audit") public Result audit(@RequestBody AuditDTO dto) { // 1. 校验当前用户是否有权限审批该申请 // 2. 根据applyType找到对应申请记录，校验status必须为PENDING // 3. 更新状态，若通过则创建社团成员关联记录 // 4. 消息通知申请人 }

这里有个关键细节：审批动作必须是幂等的。也就是说，同一笔申请被重复提交审批时，第二次必须给出"该申请已处理"的提示，而不是再执行一遍通过逻辑。我在代码里通过UPDATE ... WHERE status = 'PENDING'的方式，用数据库行锁确保并发场景下只有一次状态变更成功，受影响行数为0时说明已被处理过。

4.3 活动报名与并发控制

活动报名是并发压力最集中的接口。学生活动报名通常集中在某个时间点爆发，比如中午12点开放报名，一秒内可能涌入几百个请求。如果不加控制，currentPeople字段必然超卖。

我用的方案分三层：

第一层，前端控制：报名按钮在达到人数上限后置灰禁用，这只解决正常人操作，防不了脚本刷接口。

第二层，后端乐观锁：

@Update("UPDATE t_activity SET current_people = current_people + 1 WHERE id = #{activityId} AND current_people < max_people") int updateActivityCount(@Param("activityId") Long activityId);

这条SQL的妙处在于，current_people < max_people这个条件是数据库判断的，确保并发下不会超过上限。受影响行数为0说明名额已满，返回"已满员"错误码。

第三层，报名记录唯一约束：在t_activity_apply表设置联合唯一索引UNIQUE KEY uk_user_activity (activity_id, user_id)，防止同一个用户重复报名刷出多张票。

三层叠加，才算是把报名这个场景做扎实了。

4.4 文件上传的坑与方案

社团Avatar、活动海报、公告附件都需要文件上传功能。SpringBoot接收MultipartFile后，我存在本地磁盘的upload/目录，用UUID重命名文件避免中文名乱码和路径穿越问题。

一个容易忽略的点是SpringBoot的默认上传大小限制只有1MB，大图直接报错。必须在配置文件里放开：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

同时，静态资源映射也要配置好，否则上传成功但前端访问不到：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + System.getProperty("user.dir") + "/upload/"); } }

注意这里写的是绝对路径，部署到服务器上时要用Linux路径格式，Windows和Linux的斜杠方向不一样，容易踩坑。

5. Vue前端实现与联调实操

5.1 前端工程结构规划

前端我用Vue CLI创建工程，目录结构是实践总结出来的，组件按模块划分：

src/ ├── api/ # 所有接口请求封装，按模块拆文件 │ ├── user.js │ ├── club.js │ ├── activity.js │ └── announcement.js ├── assets/ # 静态资源 ├── components/ # 公共组件（上传组件、分页组件、富文本编辑器） ├── router/ # 路由配置 ├── store/ # Vuex状态管理 ├── views/ # 页面级组件 │ ├── login/ │ ├── admin/ # 管理员后台 │ ├── club/ # 社团管理 │ ├── activity/ # 活动管理 │ └── profile/ # 个人中心 ├── utils/ # 工具类（request.js封装Axios，auth.js存储token） ├── App.vue └── main.js

src/utils/request.js封装Axios是必须做的一件事。我在拦截器里统一注入token，统一处理错误码，避免每个页面重复写错误弹窗：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：注入token service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) // 响应拦截器：统一错误处理 service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { if (res.code === 401) { // token过期，跳转登录页 router.push('/login') } else { Message.error(res.message || '系统错误') } return Promise.reject(new Error(res.message)) } return res }, error => { Message.error('网络请求失败，请检查后端服务是否启动') return Promise.reject(error) } ) export default service

这个封装能省掉你后面80%的联调痛苦。没做统一封装的后果是每个页面都重复处理错误状态，代码冗余且容易漏掉401场景。

5.2 一个典型页面的完整实现链路

以活动列表页为例拆解一下完整链路。页面打开时，created生命周期里调用接口拉取活动列表，展示成Element UI的表格。点击"报名"按钮时，先检查登录状态，然后调用报名接口，成功则刷新列表并提示，失败（如已满员）则弹出对应错误信息。

核心逻辑如下：

<template> <div> <el-table :data="activityList" v-loading="loading"> <el-table-column prop="title" label="活动名称" /> <el-table-column prop="activityTime" label="活动时间" width="180" /> <el-table-column prop="location" label="地点" /> <el-table-column prop="currentPeople" label="已报名" width="80" /> <el-table-column prop="maxPeople" label="人数上限" width="80" /> <el-table-column label="操作" width="120"> <template slot-scope="{ row }"> <el-button type="primary" size="mini" :disabled="row.currentPeople >= row.maxPeople" @click="handleApply(row.id)"> 报名 </el-button> </template> </el-table-column> </el-table> </div> </template> <script> import { listActivity, applyActivity } from '@/api/activity' export default { data() { return { loading: false, activityList: [] } }, created() { this.fetchList() }, methods: { async fetchList() { this.loading = true try { const res = await listActivity() this.activityList = res.data.records } finally { this.loading = false } }, async handleApply(id) { const res = await applyActivity({ activityId: id }) this.$message.success(res.message) this.fetchList() } } } </script>

前端联调时最烦的就是跨域问题。我开发环境用vue.config.js里的devServer代理解决：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这样前端访问/api/activity/list时，开发服务器会代理转发到后端的8080端口，浏览器无跨域报错。部署时用Nginx反向代理，把前后端合到同一个域名下，彻底消除跨域。

5.3 富文本编辑与图片上传的联调细节

平台公告和社团活动详情需要富文本支持。我用的方案是vue-quill-editor，它集成方便，工具栏可配置。坑在图片上传——编辑器默认把图片转成base64存到数据库，一两条长文就把数据库撑爆了。

我的解决方式是重写编辑器的图片上传逻辑，把图片先传到后端拿URL，再插入编辑器内容：

methods: { onEditorChange({ editor, html }) { this.form.content = html }, async handleImageUpload(file) { const formData = new FormData() formData.append('file', file) const res = await uploadImage(formData) // 拿返回的URL，插入编辑器 const quill = this.$refs.myQuillEditor.quill const range = quill.getSelection() quill.insertEmbed(range.index, 'image', res.data.url) } }

核心思路是：数据库只存富文本HTML字符串，图片以URL形式嵌入，文件本身落在磁盘或OSS。这样做的好处是数据库体积小、备份快、加载时不阻塞。

6. 常见问题排查与性能优化心得

6.1 联调阶段的典型报错实录

前后端联调永远是项目里最磨人的阶段。我把自己遇到的高频问题整理成一张速查表，你照着排雷能省大量时间：

尤其要说下第三条。MySQL乱码是新手最常遇到、又最不易发现的问题——界面看着正常，但存进数据库就变问号。原因十有八九是JDBC连接串里少了useUnicode=true&characterEncoding=utf8这个参数。方案是jdbc:mysql://localhost:3306/club?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai。serverTimezone同样不能省，否则高版本MySQL驱动会报时区错误。

6.2 登录接口的SQL注入与密码安全

有过一次安全审计经历后，我对登录接口格外敏感。MyBatis的#{}预编译机制能有效防SQL注入，但如果你图省事用了${}，用户输入的内容直接拼接进SQL，后果就是可以万能密码登录。

正确的写法：

<select id="selectByUsername" resultType="com.example.pojo.User"> SELECT * FROM t_user WHERE username = #{username} </select>

#{}会被MyBatis编译成预编译语句的占位符?，参数由JDBC驱动转义，SQL注入无从谈起。这一点务必检查全项目，原则就是：能用#{}绝不用${}。

密码安全方面，仓库里开源的很多项目用的是MD5加盐，但MD5早已被彩虹表爆破风险笼罩。我这里用Spring Security内置的BCryptPasswordEncoder。BCrypt是自适应哈希算法，每次加密会随机加盐，同一密码两次加密结果不同，而且计算速度可用strength参数调节，暴力破解成本极高。

// 注册时加密存储 String encodedPwd = bCryptPasswordEncoder.encode(user.getPassword()); user.setPassword(encodedPwd); // 登录时校验 boolean match = bCryptPasswordEncoder.matches(loginDTO.getPassword(), user.getPassword());

6.3 列表查询性能优化

社团列表分页查询是最常用的接口。最开始我直接SELECT * FROM t_club然后分页，数据量到几千条后明显变慢。做了三处优化：

第一，数据库层面加索引。status字段虽然区分度低，但列表页最常见的就是按状态过滤，加上索引能避免全表扫描。活动表的club_id外键必须加索引，因为"社团详情页查活动列表"是高频操作。

第二，列表接口不查大字段。把description这种大文本字段从列表查询中剔除，只有点击详情时才查，减少IO压力：

<select id="selectClubPage" resultType="com.example.vo.ClubVO"> SELECT id, club_name, category_id, president_id, member_count, status, create_time FROM t_club ORDER BY create_time DESC </select>

第三，分页查询用PageHelper插件。它底层自动生成带LIMIT的SQL，比自己手动拼OFFSET优雅得多，也避免了内存分页的陷阱。这里提醒一句：PageHelper只对紧跟着的第一条查询语句生效，如果你在Mapper方法里先执行了别的查询，分页就会错乱，这是这个插件最著名的坑。

6.4 前后端时间格式不一致

后端返回的时间是2025-01-10T08:22:31这样的带T格式，前端显示出来非常丑。解决办法是在后端的JSON序列化配置里统一格式化：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

配合实体类上@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解双保险，两个地方都配好，无论在本地还是部署到服务器，时间显示都不会偏移。

7. 测试与部署实操

7.1 自测清单与冒烟测试

学生项目常见的通病是"写完代码就交，提测时一堆低级bug"。我习惯在交付前走一遍冒烟测试清单，这里分享我整理的核心条目：

• 注册一个新账号，数据库里密码是否为BCrypt密文而非明文
• 未登录访问任意接口，是否返回401而不是500
• 社团负责人创建活动后，成员列表刷新能否看到待报名活动
• 报名人数达上限后再点报名，是否提示"活动已满"
• 同一用户重复报名同一活动，是否提示已报名
• 审批通过社团创建后，社长是否自动成为该社团第一位成员
• 禁用用户后，该用户Token是否立即失效
• 富文本里插入图片，刷新页面后图片是否正常加载
• 通过PC浏览器、手机浏览器分别访问关键页面，布局是否错乱

这些条目覆盖了权限、并发、数据一致性、文件存储等最容易出问题的环节。每一条都实测过，再交付，基本不会被打回。

7.2 打包部署与常见部署坑

后端打包这一步也有讲究。直接在IDE里run是开发模式，部署都需要打成jar包：

mvn clean package -DskipTests java -jar target/club-system-0.0.1.jar

前端构建：

npm run build

生成dist目录，里面是纯静态文件。部署方案我用的是Nginx托管前端静态文件 + 反向代理后端接口：

server { listen 80; server_name localhost; # 前端静态文件 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; # Vue History路由需要这行 } # API反向代理 location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

部署到服务器上最常见的坑，一是后端启动后外网访问不了——多半是防火墙没放行8080端口，或者云服务器安全组规则没配置；二是后端能访问但前端接口请求500——检查MySQL是否配置了远程访问权限，很多云数据库默认只允许本机连接；三是Nginx反代后前端能打开但接口404——检查proxy_pass后面是否以斜杠结尾，带不带斜杠的转发路径规则完全不同。

7.3 数据库备份与恢复

部署上线后，数据库备份是必须做的功课。我写了个简单的备份脚本：

#!/bin/bash # 每日凌晨备份数据库 mysqldump -u root -p'密码' club > /backup/club_$(date +%Y%m%d).sql # 保留最近7天备份，删除更早的 find /backup -name "club_*.sql" -mtime +7 -exec rm {} \;

配合crontab定时任务：

0 2 * * * /usr/local/bin/backup_club.sh

凌晨两点备份，避开业务高峰。这步很多人不做，等到哪天真误删了数据才追悔莫及。学校项目数据量不大，mysqldump完全够用，不需要搞复杂的备份集群。

8. 实战心得与进阶方向

8.1 我在这个项目中踩过的三个关键坑

做这个社团管理系统前后花了四周，说几个记忆最深的坑。

第一个坑是数据结构设计时偷懒，社团成员表只存了userId和clubId，后来要实现"社团负责人查看本社团成员"时才发现查不到身份信息，被迫加字段、改代码、迁移数据，前后折腾了两天。这个教训是：中间表设计时，除了关联ID，业务过程中可能会用到的属性，比如角色、加入时间、备注，一次设计进去，宁多勿缺。

第二个坑是事务失效。我在活动报名的方法上加@Transactional，想当然地以为只要方法里抛异常就会自动回滚。后来发现报名成功了但成员关联表没写进去，排查了半天才意识到，@Transactional默认只对RuntimeException回滚，如果异常被try-catch吞掉了，事务根本感知不到。

正确写法是，要么让异常自然抛出，要么在catch块里手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()标记回滚。

第三个坑是前端打包后路由模式问题。我用的是Vue Router的History模式，部署到Nginx后刷新页面就404。这个坑典型到几乎所有部署教程里都提到——前端静态服务器必须配置所有路由都返回index.html。就是上文Nginx配置里那行try_files $uri $uri/ /index.html;的由来。

8.2 从课程设计到工程化项目，还差这几步

如果你学完这套基础系统想往工程级靠拢，我建议按以下顺序进阶：

第一，引入Redis做缓存。社团信息、活动列表这类热点数据缓存到Redis，降低MySQL压力。当前用户信息也用Redis存，替代JWT的无状态设计，实现登录态可强制下线。

第二，引入消息队列（如RabbitMQ或Kafka）做异步化。比如活动报名成功后发送通知消息，不用同步等待，削峰填谷，提升系统响应速度。

第三，文件存储从本地磁盘迁移到OSS对象存储。本地方案在单机部署时没问题，但做了负载均衡后，请求落在不同节点，文件存储就可能不一致。OSS天然支持分布式场景。

第四，引入工作流引擎（在复杂审批场景下，比如经费报销多级审批）替换手写状态机。手写状态机在状态少时简洁清晰，一旦审批链路变长、加减分支，维护成本会迅速失控。

8.3 针对学科竞赛和答辩的建议

如果是毕业设计答辩场景，评委老师的关注点集中在三个层面： 一是你项目解决的问题是否真实存在，二是技术选型是否合理，三是你本人对系统架构是否有透彻理解。

建议你在答辩前重点梳理这几个问题的答案：为什么选MyBatis而不是MyBatis-Plus？如果选了Plus，那就不存在手写复杂SQL的必要性，你要能答上来二者的差异和取舍逻辑。为什么用JWT而不是Session？JWT适合前后端分离的无状态场景，但token吊销麻烦，Session适合传统单体应用，两种方案要能对比分析优劣。项目里哪些地方存在并发风险？活动报名如何解决超卖问题？这些具体到代码层面的问题，比宏观的架构问题更能检验你到底是自己做的还是抄来的。

从实践角度说，我强烈建议你不要满足于把项目跑通就交差，而是自己动手造一遍核心模块——特别是报名并发控制、审批状态机、JWT权限过滤这三个部分。这三块恰好覆盖了全栈开发里"数据库并发、业务状态建模、安全认证"三大知识域。你把这些真正吃透，简历里写这个项目时，面试官多问几层也问不倒你。

我个人在实际开发里最大的体会是：课程设计、毕业设计其实不是靠复杂度取胜的，靠的是逻辑自洽和细节完整。一个能正确处理并发超卖的活动报名，比十个空空荡荡的CRUD接口有价值得多。你把这个社团管理系统按我讲的思路完整实现一遍，收获的绝不只是一个能交差的Demo，而是一套可以扩展到任何后台管理系统的通用方法论。