企业官网建设流程全解析

社区志愿者管理系统是计算机专业毕业设计里非常经典的一类选题。它表面上只是一个前后端分离的管理系统，但拆开看会涉及用户注册、角色权限、活动发布、报名审核、签到签退、服务时长统计、公告管理这一整条业务链，足够覆盖一个 SpringBoot + Vue 项目从设计到落地的完整过程。如果你正准备做这个方向的 Java 毕设、课程设计或者新人练手项目，建议把这篇文章看完。我会按业务拆解、环境准备、后端开发、前端对接、联调部署、答辩准备这个顺序，把每个环节里真正容易踩坑的地方说清楚。

先说一个最基本的判断：这类管理系统难度不算高，核心不在某个单独的技术点，而在业务流程有没有做完整、状态流转有没有闭环、前后端接口有没有对清楚。很多人代码写完了还处于“能登录、能查列表”的阶段，面试或答辩一问活动状态、报名审核边界、重复签到怎么处理，就答不上来。所以下面不会只讲“怎么运行起来”，更会讲清楚为什么要这样设计。

1. 先搞清楚系统要解决什么业务问题

1.1 志愿者管理系统的角色与典型使用场景

社区志愿者管理系统面向的使用者通常是社区居委会、物业服务中心、志愿团队或公益组织。系统要解决的现实问题有三个：活动信息怎么发布、志愿者怎么报名并参与、服务时长和记录怎么留痕。

围绕这三个问题，系统角色其实只需要两类：普通志愿者和管理员。志愿者可以看到活动列表、报名活动、查看自己的报名状态、进行签到签退、查看累计服务时长和个人信息。管理员负责管理活动、审核报名、管理志愿者账号、查看统计数据和发布公告。

有人会把管理员再拆成超级管理员和普通管理员，比如一个管用户一个管活动。这种设计没有问题，但如果是毕业设计，建议不要一开始就把 RBAC 权限模型铺得太大。角色多、权限点多，工作量会翻倍，而答辩时反而不容易把主链路讲清楚。先把“志愿者 + 管理员”两套角色跑通，再考虑扩展，这是更务实的路线。

1.2 核心业务链路和状态流转

一个社区志愿者活动从发布到结束，完整流程是这样的：

1. 管理员创建活动，活动状态默认为“招募中”。
2. 志愿者浏览活动列表，点击报名。
3. 管理员在报名管理页面看到待审核记录，选择通过或拒绝。
4. 活动开始前，志愿者到达现场，在系统中签到。
5. 活动结束后，志愿者签退。
6. 系统根据签到签退时间自动计算服务时长，并累加到该志愿者的总时长中。
7. 整个流程结束后，管理员可以关闭活动或归档活动。

这个过程里有几个状态字段要提前设计好，后面写代码会省很多事。

活动状态可以用整数或字符串保存，建议用字符串加枚举语义，看到代码就能懂：

• 0 或 DRAFT 表示草稿，未发布
• 1 或 RECRUITING 表示招募中
• 2 或 ONGOING 表示进行中
• 3 或 FINISHED 表示已结束
• 4 或 CANCELED 表示已取消

报名状态也建议单独保存：

• 0 待审核
• 1 已通过
• 2 已拒绝
• 3 已取消

签到状态则可以设计成三种：未签到、已签到、已签退。只保存一个状态字段会丢失“签到但还没签退”这个中间态，而中间态恰恰是计算服务时长的关键。

很多人容易漏掉一个细节：活动开始时间早于审核通过时间，或者志愿者在活动结束后才点击签到，这类异常情况如果不做判断，系统会产生脏数据。所以接口层至少要做三层校验：活动是否处于招募中、报名是否通过、当前时间是否在允许签到签退的时间窗口内。

1.3 功能模块和页面关系

从页面角度拆，前台志愿者端大概需要这些页面：

• 登录注册页
• 活动列表页，支持按状态筛选
• 活动详情页，显示活动内容、报名人数、剩余名额
• 我的报名页，展示报名记录和审核结果
• 我的时长页，展示累计时长和按月明细
• 个人中心页，修改密码和基本资料

后台管理端需要这些页面：

• 登录页
• 仪表盘，展示活动总数、报名总数、志愿者总数和最近活动
• 活动管理页，支持新增、编辑、上下架、查看报名列表
• 报名审核页，对待审核记录逐条审核或批量审核
• 签到管理页，可以手动标记签到，也支持查看某场活动的签到明细
• 志愿者管理页，查看所有注册的志愿者账号
• 公告管理页，发布和编辑社区公告

页面之间不要做太多层级嵌套，让用户拿着手机就能完成大部分操作。如果前端用 Vue 写响应式布局，那志愿者端尽量按移动端屏幕习惯设计，管理员端则按桌面端表格来设计。这样项目看起来会有很强的实用性，答辩展示时观感也好。

2. 技术选型和环境搭建怎么弄才不容易翻车

2.1 JDK、SpringBoot、Vue 的版本怎么配

毕业设计最怕什么？最怕版本太新，网上找不到对应资料，或者安装后出现兼容性问题。

后端我建议直接用 JDK 1.8 + SpringBoot 2.7.x。这个组合最稳定，资料最多，很多现成模板也是基于这个配置。

SprinBoot 3.x 虽然已经发布很久了，但它要求 JDK 17 以上，并且部分第三方库的版本需要跟着升，比如 MyBatis-Plus、Druid、FastJSON 这些。对毕设项目来说，没必要为了新版本去折腾兼容问题。

前端的选择取决于你更熟悉 Vue 2 还是 Vue 3。

如果你看的是老教程、学校里讲的是 Vue 2，那用 Vue 2.7 加 Element UI 是比较稳妥的选择。Vue 2.7 是官方最后一个支持 Vue 2 的版本，实际上把 Vue 3 的 Composition API 也兼容回来了，写起来空间很大。

如果学校要求新或你想学 Vue 3，那就用 Vue 3 + Vite + Element Plus。Vite 比 Webpack 快很多，启动很舒服，但要注意 Node.js 版本不能太低，建议用 16 以上，更稳的话直接用 18 LTS。

前端依赖安装命令建议用 npm 或 pnpm。如果在国内网络环境下载慢，可以把 npm 源切到国内镜像，这一步很多同学一开始就卡住了。

2.2 数据库表结构设计思路

数据库是毕设的重头戏。表不用设计太多，但每一张表都要有明确用途。我建议至少包含以下几张：

• user：用户表，保存志愿者和管理员账号
• activity：活动表
• enrollment：报名表
• attendance：签到签退表
• notice：公告表

如果你希望逻辑更清晰，可以把用户表和志愿者扩展信息分开，用 user 保存登录账号，用 volunteer_info 保存真实姓名、身份证号、联系方式、紧急联系人等。但在毕设级别，合在一起也能跑，看你怎么权衡。

这里给一个用户表的核心字段设计参考：

• id：主键
• username：用户名或手机号，登录用
• password：加密后的密码
• real_name：真实姓名
• phone：手机号
• role：角色，1 表示管理员，0 表示志愿者
• avatar：头像地址
• status：账号状态，1 正常，0 禁用
• create_time：注册时间

活动表的核心字段：

• id
• title：活动标题
• description：活动内容
• location：活动地点
• start_time：开始时间
• end_time：结束时间
• sign_in_start：允许签到开始时间
• sign_in_end：允许签到截止时间
• max_people：最大报名人数
• current_people：当前已报名通过人数
• status：活动状态
• create_by：创建人
• create_time

报名表的核心字段：

• id
• activity_id：活动ID
• user_id：报名志愿者ID
• status：报名状态
• apply_time：报名时间
• review_time：审核时间
• review_by：审核人

签到表的核心字段：

• id
• activity_id
• user_id
• sign_in_time：签到时间
• sign_out_time：签退时间
• duration_minutes：服务时长，分钟数

这里的 duration_minutes 建议存放整数分钟，而不要用时间字符串，后面做统计聚合会很方便。

2.3 Maven 依赖和前端依赖清单

后端需要在 pom.xml 中引入的核心依赖：

• spring-boot-starter-web
• spring-boot-starter-validation
• mybatis-plus-boot-starter
• mysql-connector-java
• jjwt 或 java-jwt，用于生成和校验 Token
• lombok，减少实体类 Getter/Setter 代码
• hutool 可选，里面有很多开发中会用到的工具方法，比如日期处理、随机数、Bean 拷贝

前端依赖：

• vue 或 vue3
• vue-router
• axios
• element-ui 或 element-plus
• pinia（Vue 3）/ vuex（Vue 2）
• dayjs，时间处理比原生 Date 方便得多

依赖不要一上来全部安装，先搭骨架，跑通一个登录接口，再逐个加功能。

这里有一个很实在的建议：不要一上来就追求大而全，先把“管理员登录 -> 发布活动 -> 志愿者报名 -> 管理员审核 -> 签到签退 -> 查看时长”这条主链路跑通，再加公告、统计、导出这类辅助功能。主链路通了，项目就成功了一大半。

3. 后端 SpringBoot 开发顺序和关键接口设计

3.1 项目目录结构怎么划分

很多同学后端代码写着写着就变成一个 Controller 几百行，全部逻辑往里面堆。这不是不行，但后期维护和答辩都会很难受。

我更建议按下面这种结构组织：

com.example.community ├── controller // 接收前端请求 ├── service // 业务逻辑 ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── dto // 请求/响应参数对象 ├── config // 配置类，比如跨域、MyBatis-Plus分页、JWT拦截器 ├── common // 通用工具、统一返回结果、全局异常 └── utils // JWT、密码加密等工具类

Controller 里面只做参数接收和返回结果，业务判断放在 Service，数据访问全部走 Mapper。这样做的好处是：接口报错时，你能快速定位是参数问题、逻辑问题还是数据库问题；答辩时老师问“你这个模块怎么实现的”，你可以很清晰地按三层去讲解。

3.2 统一返回结果和全局异常处理

前后端分离项目，最重要的就是接口返回格式要统一。不要让一个接口返回{code:200, data:{...}}，另一个接口返回{success:true, data:[]}，还有报错时直接返回一段字符串。这样前端写起来会非常痛苦。

建议定义一个统一的返回类 Result，结构大致如下：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String message) { ... } }

返回状态码也可以用 HTTP 状态码，但更常见的是业务状态码。比如 code 为 200 表示成功，400 表示参数错误，401 表示未登录，500 表示服务器异常。这样前端拦截器可以统一根据 code 判断是否弹出错误提示。

全局异常处理使用@RestControllerAdvice，把业务异常和系统异常分开处理。业务异常比如“活动名额已满”“当前时间不能签到”，直接返回提示信息；系统异常统一记录日志，返回“系统繁忙，请稍后重试”。

3.3 登录认证和 JWT 使用逻辑

管理系统很大概率要被问到登录认证是怎么设计的。如果只是把用户名密码存 Session，确实比较适合传统 Web 项目，但前后端分离项目里更常用 JWT。

JWT 的逻辑不复杂：

1. 用户提交用户名密码。
2. 后端校验通过后，生成一个 Token，把用户 id、角色放进去。
3. 前端把 Token 保存起来，每次请求在请求头里带上Authorization: Bearer {token}。
4. 后端写一个拦截器，拦截需要登录的接口，解析 Token 并校验身份。

这里要注意几个细节：

• 密码不能明文保存，必须加密。可以用 BCryptPasswordEncoder，也可以用 MD5 加盐。作答时建议用 BCrypt，它足够安全，而且 Spring Security 可以直接集成，SpringBoot 里默认支持。
• 拦截器里要放行登录注册接口，其他接口都要校验 Token。
• 管理员接口必须校验角色字段是管理员，只校验“登录了”不够。

JWT 的 key、过期时间这些配置建议写到 application.yml 中，不要硬编码在代码里。过期时间一般设置为 24 小时，前端路由守卫在 Token 过期时自动跳回登录页。

3.4 核心接口列表和参数设计

下面是一个比较完整的最小接口清单，按业务模块划分：

认证模块：

• POST /api/auth/login：登录
• POST /api/auth/register：志愿者注册
• GET /api/auth/info：获取当前登录用户信息
• PUT /api/auth/password：修改密码

活动管理：

• GET /api/activity/list：分页查询活动列表
• GET /api/activity/detail：活动详情
• POST /api/activity：新增活动，仅管理员
• PUT /api/activity：修改活动，仅管理员
• DELETE /api/activity：删除活动，仅管理员
• PUT /api/activity/status：修改活动状态，仅管理员

报名管理：

• POST /api/enrollment/apply：志愿者报名
• GET /api/enrollment/my：我的报名记录
• GET /api/enrollment/list：按活动查看报名列表，管理员
• PUT /api/enrollment/review：审核报名，管理员

签到管理：

• POST /api/attendance/signIn：志愿者签到
• POST /api/attendance/signOut：志愿者签退
• GET /api/attendance/activityList：某活动的签到明细，管理员

统计与管理：

• GET /api/stats/dashboard：仪表盘统计数据
• GET /api/volunteer/list：志愿者列表，管理员
• GET /api/volunteer/duration：某个志愿者的时长明细
• POST /api/notice：发布公告

这些接口已经能覆盖一个完整管理系统的大部分功能。写代码时建议按模块推进，每写完一个模块就手动调一次接口，不要等到全部写完再一起调。

3.5 签到签退和服务时长的计算逻辑

签到签退是这个项目里最容易出问题的地方，因为涉及到时间和状态两套逻辑。

如果活动是线下社区打扫、环保宣传这类，志愿者到场后需要到场签到，管理员也可能会在后台手动标记到场。签到时生成一条 attendance 记录，记录 activity_id、user_id 和 sign_in_time。签退时更新这条记录，补上 sign_out_time，然后计算 duration_minutes。

计算时长的时候不要用 endTime 减去 startTime 这种粗暴方式，因为志愿者可能迟到早退，也可能活动结束后忘了签退。稳妥的做法是：

if (signInTime != null && signOutTime != null) { long diff = signOutTime.getTime() - signInTime.getTime(); int minutes = (int) (diff / 60000); if (minutes < 0) { minutes = 0; } // 如果活动时长上限有约定，这里还可以做一个 clamp }

建议再加一个“补签”逻辑。现实中总有志愿者手机没电或者忘记签退，管理员可以在后台补录。补录时要记录操作时间和操作人，以免数据被随意篡改。

4. 前端 Vue 项目怎么搭，怎么对接后端不混乱

4.1 页面路由和权限控制

前端页面结构建议直接按角色拆成两个布局：

• 志愿者端布局，包含底部导航或侧边菜单，页面包括活动列表、我的报名、我的时长、个人中心。
• 后台管理端布局，包含完整侧边菜单，页面包括仪表盘、活动管理、报名审核、签到管理、志愿者管理、公告管理。

Vue Router 里要配置路由守卫。当用户没有登录时，访问任何需要登录的页面都重定向到登录页。当管理员访问志愿者页面时，可以限制也可以不限制，但管理员端页面必须做角色校验。

一个简化版的路由守卫思路：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else if (to.meta.requiresAdmin && token) { const role = localStorage.getItem('role') if (role === 'admin') { next() } else { next('/') } } else { next() } })

不要把所有页面都写在 App.vue 里，按登录页、志愿者端、管理端分别设置 Layout 组件。页面一多，这样拆会清晰很多。

4.2 Axios 请求封装和统一处理

前端和后端交互，直接在每个页面里写 axios.get 也能跑，但容易出现重复代码。更好的做法是把 axios 封装成一个 request 模块。

基本思路：

• 创建一个 axios 实例，设置 baseURL。
• 请求拦截器里从 localStorage 取出 Token，加到请求头。
• 响应拦截器里统一处理 code。code 为 401 时清除本地登录信息并跳转登录页；code 为 400 时弹出 message；code 为 200 时直接返回 data，减少页面里的嵌套判断。

const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.clear() window.location.href = '/login' return Promise.reject(new Error('未登录')) } if (res.code !== 200) { ElementMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { return Promise.reject(error) } )

这样做的好处非常明显：业务页面只需要关心请求成功后的数据，不用在每次请求后都写一遍错误处理。

4.3 跨域问题怎么处理

前后端分离项目一定会遇到跨域。

一种解决方式是在后端写一个 CORS 配置类，允许前端地址访问。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

另一种方式是在前端开发环境下配置代理，把/api开头的请求转发到后端端口。

如果是 Vite 项目，在 vite.config.js 里配置：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

两种都可以。后端 CORS 配置适合接口部署后仍然需要访问的场景，前端代理适合本地开发。生产环境如果通过 Nginx 部署，更推荐在 Nginx 层面做反向代理，这样前端和后端看起来就是同一个域，不存在跨域问题。

5. 联调、测试和部署阶段的核心排查思路

5.1 联调时先确认哪些东西

前后端联调，报错不一定在后端代码上。很多情况下是网络、参数名、接口路径或数据格式的问题。

我一般会按这个顺序排查：

1. 打开浏览器开发者工具，看 Network 面板里请求到底发出去了没有。
2. 看请求 URL 是否和后台 Controller 的路由一致。
3. 看请求方法是不是 POST、GET、PUT 对应正确。
4. 看请求参数名是否和 DTO 字段一致。
5. 看请求头有没有带 Token。
6. 看后端控制台有没有异常日志，异常信息是第一排查线索。
7. 如果返回 500，错误堆栈往往会直接告诉你空指针、SQL 语句问题还是参数转换问题。

最容易出现但最容易被忽略的问题是字段名不一致。后端实体类字段是 createTime，前端参数写成 createtime，或者 JSON 格式不对，报错信息就会是“请求体格式错误”或 400。遇到这种提示先别改代码，先去对比前后端字段名。

5.2 数据库连接和配置容易踩的坑

MySQL 连接报错，大部分情况是这几类：

• 驱动版本和数据库版本不匹配。MySQL 8 用 com.mysql.cj.jdbc.Driver，MySQL 5.7 以及之前的版本用 com.mysql.jdbc.Driver。
• URL 里没有加时区参数，或者加了错误的时区。建议直接使用 serverTimezone=Asia/Shanghai。
• 密码不对，或者密码中有特殊字符没转义。
• 数据库还没建立，或者表名和实体类对不上。

application.yml 里数据库配置大概类似这样：

spring: datasource: url: jdbc:mysql://localhost:3306/community_volunteer?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver

建库时建议使用 utf8mb4 字符集，这样 Emoji 和生僻字不会变成乱码。

5.3 一键启动和演示数据的准备

毕业设计最后是要演示的。不要等到演示前才来准备数据，那样很容易手忙脚乱。

建议把数据库脚本写成 sql 文件，里面不仅包含建库建表语句，还要插入几段演示数据。比如创建一个管理员账号 admin，创建一个志愿者账号 testUser，准备两三场不同状态的活动。这样每次演示，只需要执行一次 sql 文件，就能快速回到可演示状态。

后端可以写一个 CommandLineRunner 或初始化接口，系统启动时判断管理员表是否为空，为空则自动创建一个默认管理员。这个小细节在答辩或重新部署时很加分。

前端也要有默认登录信息提示，比如登录页下面写一行“管理员测试账号：admin，密码：123456”。省得演示时临时找账号。

5.4 部署到云服务器时的常见难点

很多学校不会强制要求服务器部署，但如果你把项目部署到云服务器上，项目完成度会明显提升不少。

部署方案大概两种：

第一种是后端打成 Jar 包，前端 build 之后把 dist 目录放到 Nginx，Nginx 配置反向代理把 /api 转发到后端端口。

第二种是直接把前后端都放到一个服务器上，前端 dist 静态文件直接用 Nginx 托管，后端 Java 进程通过 systemd 或 nohup 后台运行。

部署时要特别留意防火墙端口：后端 8080 端口如果不对外公网开放，前端 Nginx 无法转发；如果对外开，又可能被扫描攻击。稳妥的方式是生产环境只开放 80/443 端口，其他端口只在服务器内部访问。

6. 毕业设计交付时，源码和论文怎么写才站得住脚

6.1 源码结构和注释怎么整理

源码不是写完就结束了，交付和答辩前要花时间整理。评委导师看源码，第一眼看的是整体结构，第二眼看的是命名规范，第三眼才可能翻复杂逻辑。

整理源码时注意几点：

• 类名要能直接表达含义。ActivityController、VolunteerService、EnrollmentMapper，一看就知道是干什么的。
• 实体类字段和数据库表字段对应关系要在注释里写清楚。
• Controller 每个接口上写清用途和参数含义，至少写关键注释。不用每行都写，但接口级别注释必须有。
• 排除掉 IDE 自动生成的 target、node_modules 目录，不要在压缩包里带上这些无意义文件。
• 提供一个 README 文件，写明 JDK 版本、Maven 版本、Node 版本、MySQL 版本、数据库导入方式、启动顺序、默认账号密码。

6.2 论文开题报告和正文的关注点

项目标题里有“论文开题”，说明这个毕业设计是要求写开题报告和论文正文的。

开题报告通常包含课题背景、国内外研究现状、研究目标、研究内容、技术路线、时间安排。写的时候不要大段抄百度百科，导师一眼就能看出来。像“社区志愿服务的数据化管理”这种背景，可以结合你所在城市或社区的志愿服务需求写，让内容更真实。

论文正文建议重点写这几块：

1. 需求分析：说明角色、功能需求、非功能需求。
2. 系统总体设计：总体架构图、功能模块划分、技术选型。
3. 数据库设计：E-R 图、表结构说明，重点讲几张核心表之间的关系。
4. 系统详细设计与实现：按模块介绍，配核心代码片段和界面截图。
5. 系统测试：功能测试用例表、测试结果、问题修复记录。

写实现细节时，每个模块要能对应到你自己的代码，不要空谈技术。比如写“报名审核模块”，就说清楚审核通过了之后前端列表状态会变化，志愿者收到“报名通过”的提示；审核拒绝时前端显示拒绝原因。这些细节越真实，论文越经得起推敲。

6.3 答辩时容易被问到的高频问题

根据我做过的项目和帮助过的同学经验，答辩现场老师不会问太多偏门内容，基本集中在下面这些方向：

• “系统有哪些角色，权限是怎么控制的？” 答案：JWT 里放角色字段，后端拦截器校验角色。
• “为什么要用 JWT 而不用 Session？” 重点回答前后端分离、无状态、扩展性好。不用说得太难，但要说清区别。
• “活动报名会不会有并发问题？怎么处理？” 至少要说用数据库事务，更新活动当前报名人数时加条件判断，比如 update activity set current_people = current_people + 1 where id = ? and current_people < max_people。这个回答很加分。
• “服务时长是怎么算的，人工改时长怎么防篡改？” 回答签到签退自动计算 + 管理员补录留痕。
• “数据库表之间是什么关系？” 答出 user 与 enrollment 是一对多，activity 与 enrollment 是一对多，enrollment 和 attendance 是一对一或一对多即可。

如果不会的问题不要硬编。可以直接说“这个点我还没有深入验证过，我的思路是……”这种表达比沉默或乱答要好得多。

6.4 项目还能往哪些方向扩展

如果你的时间充足，或者想把这个项目写得更突出一点，可以在现有基础上做扩展。扩展方向不需要多，一两个就够。

比较适合这个项目的扩展方向：

1. 服务时长排行榜和积分体系。志愿者参与活动后获得积分，积分可以兑换社区礼品或作为评优依据。这个功能能用到排序、统计、缓存，实现起来不复杂。
2. 二维码签到。管理员在活动页面生成二维码，志愿者现场扫码签到。可以引入一个二维码生成依赖，前端展示二维码，后端根据活动 id 生成签到链接。答辩时演示效果很直观。
3. 导出 Excel 数据。管理员把某个月的活动记录、志愿者时长导出为 Excel 文件。用 EasyExcel 写一个导出接口，前端点击按钮下载。
4. 消息通知。活动审核通过后，给志愿者发站内消息通知。可以加一张 message 表，在审核接口里同步插入消息记录。虽然不太复杂，但能体现系统完整性。

扩展功能时关键是要写在论文和答辩 PPT 里，让导师看到你这个项目不是停留在登录和增删改查。但也不要贪多，功能太多导致主链路出 bug，反而得不偿失。

回到最开始那个观点：社区志愿者管理系统真正考验的不是你会用几个框架，而是你能否把一个实际业务从需求梳理到代码实现，再回归到数据闭环。只要把角色权限、活动生命周期、报名审核、签到时长这四条线走通，系统的价值就完全体现出来了。希望这篇内容能帮你少走一些弯路。