企业官网建设流程全解析

1. 项目定位：志愿者招募管理系统到底要解决什么问题

说实话，看到“基于springboot的志愿者招募管理系统”这类标题，大家第一反应多半是“又是一个学生毕设项目”。但真把这个需求放到实际场景里去拆，它要承担的职责远比想象中复杂。一个完整的志愿者管理系统，不光是做一张报名表、存几条记录就完事，它要覆盖活动发布、志愿者报名、名单审核、扫码签到、服务时长记录、数据统计、组织管理这一整条链条，缺少任何一环，项目落地后都得返工。

我在规划这类系统时，习惯先问三个问题：谁来用？用的时候会经历哪些环节？哪些地方最容易出混乱？回答完这三个问题，整个项目的边界就清晰了。

1.1 系统解决的核心业务痛点

志愿活动最常见的混乱场景，我随便举几个：招募信息靠微信群接龙，管理员统计到眼花；报名人数超出活动容量，没人通知候补；活动当天用纸质签到表，结束后时长录入全靠人工；年底想出一份服务时长证明，翻聊天记录翻了半小时。

所以，志愿者招募管理系统真正要解决的问题可以收敛成四点：

• 招募信息的统一发布与曝光，让志愿者能在一个固定入口看到所有活动；
• 报名与审核流程的规范化，避免超员和重复报名；
• 活动现场的签到确认以及后续服务时长的自动累计；
• 志愿者档案与历史记录的沉淀，为评优和证明开具提供数据支撑。

明白这几点后，再回头看技术选型，就非常明确了：需要一个开发效率高、生态成熟、能快速搭建Web应用的框架，springboot自然是首选。它整合了开发中绝大多数通用能力，让我们把精力集中在业务本身而不是环境配置上。

1.2 角色划分与权限模型：管理员、志愿者、组织方

我接触过的同类系统，很多都只用“管理员”和“普通用户”两种角色，做起来确实快，但一到真实使用场景就出问题。因为发布活动的人通常是项目负责人或组织干事，他们需要查看自己活动的报名单，但又不应该看到全平台所有志愿者的个人信息；而平台管理员更多是做审核、数据维护和全局统计。

所以我在系统设计时，倾向用三种角色模型：

• 组织方（活动发起者）：发布活动、查看自己活动的报名情况、确认录取、导出签到表；
• 志愿者（用户）：浏览活动、在线报名、查看录取结果、报名签到、查看个人服务时长；
• 平台管理员：审核活动和组织方资质、管理用户、处理申诉、查看全站统计数据。

权限上我用了一套比较通用的RBAC思路，结合springboot的Spring Security来落地。实际开发中，接口层面用注解控制访问权限，比如活动发布接口要求ROLE_ORGANIZER，后台管理接口要求ROLE_ADMIN，志愿者相关接口用ROLE_VOLUNTEER。别小看权限划分，项目越往后做，这里省下的返工时间越多。

2. 技术栈与版本选型：为什么是springboot，版本怎么定

技术选型是整个项目的地基，很多刚接触springboot的人最容易在这一步踩坑。首先是版本问题。springboot 3.x已经发布，但如果你还在用JDK 8，或者项目里依赖了某些老版本Mapper插件，那直接上手3.x就会遇到javax包名变更、旧组件不兼容等问题。我个人的建议是：如果目标是快速稳定交付，选springboot 2.7.x加JDK 8的组合最省心；如果团队本来就在用JDK 17以上，那直接上springboot 3.x也没问题，只是需要注意依赖的groupId和包路径变化。

这正好呼应了springboot热词里经常被问到的问题：springboot版本太高会导致什么？常见的就是第三方starter还没适配，启动直接报ClassNotFoundException，排查半天发现不是代码问题，而是版本兼容问题。所以版本选型的第一原则不是求新，而是求稳。

2.1 核心组件清单：MyBatis、MySQL、Redis的搭配逻辑

在组件选型上，我采用的方案比较常规，但却是经过前几个项目验证过的稳定组合：

这里重点说一下为什么ORM选MyBatis-Plus。志愿活动报名这类业务，单表操作非常频繁，比如查询活动列表、插入报名记录、更新状态，用MyBatis-Plus的BaseMapper可以省掉大量重复的XML配置。而到了统计每个志愿者的累计时长这步，又需要多表聚合查询，这时候直接在Service层手写SQL，比用QueryWrapper硬拼要清晰很多。两者结合，效率和可维护性都有保障。

2.2 springboot自动配置：明白了它，配置就不再靠猜

初学springboot时，很多人对“约定大于配置”这句话只停留在概念层面。真正要搞懂，就得理解springboot的自动配置原理。简单来说，当你引入了某个starter依赖，springboot会根据classpath下是否存在对应类，自动装配一组默认配置。比如引入了spring-boot-starter-data-redis，启动时自动配置类就会往容器里塞一个RedisTemplate的Bean，连接参数从application.yml中的配置项读取。

开发过程中最实用的一点是：遇到Bean初始化异常时，我会先看自动配置是否被条件装配拦截了。比如@ConditionalOnMissingBean配合自定义配置类，你一旦自己定义了RedisTemplate，springboot就会放弃默认的配置方案，转而使用你的Bean。理解了这层，以后看启动日志里的Negative matches就不会一脸懵，排错定位至少快一倍。

2.3 前后端分离：Vue如何与springboot高效协作

项目采用前后端分离的开发模式，后端只提供Restful API，前端由Vue2/Vue3配合Element UI实现页面交互。这种架构下最需要注意的就是跨域和鉴权两个问题。跨域我通常在开发环境用@CrossOrigin放过，线上则由Nginx统一分发请求，前端以/api开头的请求都代理到后端服务。鉴权则统一走JWT：登录成功后前端把token存到本地，每次请求时在请求头带Authorization: Bearer <token>，后端通过过滤器统一校验。

实际开发中，为了避免把鉴权逻辑写到每个Controller里，我会封装一个注解配合拦截器，只对需要登录的接口生效。比如活动详情页是公开的，不需要拦截；报名操作则必须要登录。这种“按需拦截”的方式，比全站拦截再放行某些URL的逻辑要直观很多，也更好维护。

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

数据库设计是这个项目成败的关键点。我见过很多版本的志愿者系统，数据库随便建几张表就开始写代码，结果做到后面，想统计一下“今年参与活动超过20小时的志愿者名单”都写不出SQL。原因就是把所有信息塞在一个宽表里，字段设计完全没有解耦。

3.1 核心表结构和字段设计思路

在我设计的方案中，核心表包括：

• sys_user：用户表，存放登录账号、密码哈希、姓名、角色类型；
• volunteer_profile：志愿者档案表，存放真实姓名、证件号、紧急联系人、技能标签等扩展信息；
• activity：活动表，存放活动名称、地点、开始/结束时间、招募人数、当前报名数、状态；
• activity_signup：报名记录表，记录志愿者与活动的报名关系，以及审核状态；
• activity_checkin：签到记录表，记录现场签到时间和服务时长来源；
• service_hour：服务时长汇总表，按志愿者维度累计有效时长。

以活动表为例，核心字段有title、location、start_time、end_time、recruit_count、applied_count、status、organizer_id。这里有一个容易忽略的点：applied_count是冗余字段，正常情况下它应该通过报名表count得到。那为什么不直接实时查呢？因为活动列表页高频展示招募进度，实时统计会导致每条活动都多一次聚合查询，数据量大时会有压力。做了冗余之后，报名成功和取消时同步更新这个字段即可，再用状态机保证一致性。这种设计在真实项目里很常见，属于典型的“用可控冗余换查询性能”。

3.2 招募流程的状态机设计

活动从发布到结束，状态绝不是“进行中”和“已结束”这么简单。我把流程阶段定义成：

• DRAFT：编辑中，尚未正式发布；
• RECRUITING：招募中，志愿者可以报名；
• OFFLINE：活动已截止报名，等待现场执行；
• ONGOING：活动进行中，支持现场签到；
• FINISHED：活动已结束，确认服务时长；
• CANCELLED：活动取消。

状态机用MySQL字段存储，在Service层统一封装状态流转方法。比如组织方点击“发布活动”时，只有DRAFT状态能流转到RECRUITING；活动到了截止时间，系统定时任务会把RECRUITING批量流转为OFFLINE。这个看似简单的设计，防止了很多越权操作：我没有提供一个通用的“修改状态”接口，而是每个流转动作对应独立方法，传入当前用户与活动ID后在方法内部校验权限和状态，避免有开发者为了方便直接暴露updateStatus接口，导致前端可以随意把活动改成任何状态。

此外，报名记录的状态设计也同理：PENDING（待审核）、APPROVED（已录取）、REJECTED（已拒绝）、CANCELLED（已取消）、CHECKED_IN（已签到）。志愿者取消报名只能发生在PENDING或APPROVED且活动未开始时，管理员后补名额则会将最先候补且状态为REJECTED的报名记录重新置为APPROVED。这一套细节，就是系统从“能跑”到“好用”的区别。

3.3 活动热度与推荐：引入Redis提升体验

只要活动数量一多，多数用户都会只盯着最新最热的活动看，如果每次请求都去MySQL里做一次多表关联的分页查询，越到后面性能越难看。我的做法是在活动详情被访问时，用Redis的ZSet结构维护活动ID的热度分，访问一次加1分。首页的“热门活动”直接取TopN，秒级返回后再从MySQL补全活动详情字段。

这个方案的实现门槛很低，但对体验的提升却很直观。而且Redis的数据结构是天然的排行榜实现，不需要额外引入搜索引擎或大数据组件。等你有天发现数据量真的大到扛不住了，再引入Elasticsearch也不迟，因为Redis层只是加了个缓存加速，底层表结构完全不用动。

4. 后端业务实现：分层架构与关键功能拆解

这部分我讲一下实际写代码时怎么拆包、怎么写逻辑、以及几个核心功能点如何落地。我会用日常开发的习惯来讲，不是教科书式的包结构，但层次足够清晰。

4.1 分包结构与SpringBean的生命周期理解

我习惯的分包如下：

com.example.volunteer ├── common // 通用类：统一返回结果、异常处理、常量 ├── config // 配置类：跨域、安全、Swagger等 ├── controller // 接口层：接收参数、校验入参格式 ├── service // 业务层：核心业务逻辑 │ └── impl ├── mapper // 数据访问层：MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 请求/响应对象：避免把实体直接暴露给前端 ├── vo // 视图对象：聚合多个表的数据展示 └── util // 工具类：时间处理、导出等

controller只负责参数接收与结果包装，service层处理业务流程，mapper层做数据操作。很多新手写代码喜欢把所有逻辑堆在controller里，一开始没问题，活动表一旦要加一个审核字段，全链条都得跟着改，维护成本直线上升。分层架构的价值不是在项目初期体现的，而是项目改到第三个版本时，你才会庆幸当初没乱来。

4.2 核心接口逻辑：发布活动与报名的完整链路

这里举一个最核心的链路：组织方发布活动、志愿者报名、组织方审核。发布活动的service方法核心逻辑大概是：

public void publishActivity(ActivityPublishRequest request) { // 1. 判断当前用户是否具备组织方权限 // 2. 设置活动初始状态为DRAFT // 3. 插入activity记录 // 4. 写入操作日志 }

志愿者报名时，具体流程要比想象中繁琐：

public SignupResult signup(Long activityId, Long userId) { // 1. 校验活动是否存在且状态为RECRUITING // 2. 校验当前用户不是该活动的组织者 // 3. 校验该用户没有重复报名（状态不是CANCELLED的才算） // 4. 报名人数是否已达上限 // 5. 插入报名记录，状态为PENDING或直接APPROVED // 6. 活动表applied_count加1 // 7. 若报名人数达到上限，自动将活动状态流转为OFFLINE }

注意第四步和第七步，这是整个报名链路中最容易被忽略的并发问题。如果同一个活动有大量用户同时报名，两个请求同时读到applied_count = 99，活动上限100人，两个请求都判断没满，分别插入成功，最终报名人数变成101，超员了。解决思路有两个方向：一是数据库行锁，给活动表加for update，在事务内锁定记录再判断；二是用Redis分布式锁加在活动ID维度。我建议先实现数据库行锁，简单可靠，等真的到了高并发场景再上分布式方案。别忘了给报名表加上activity_id + user_id的唯一索引兜底，即便锁逻辑写漏了，数据库也会拦住重复报名。

4.3 文件上传、Excel导出等通用能力的接入

系统的活动报名汇总往往需要导出成Excel，方便组织方打印或留档。这个能力我用的是EasyExcel，它是阿里开源的工具包，相比传统的POI写法，API更友好、内存占用更小。核心思路：把报名数据查出来转成List，然后定义好实体字段的注解顺序，一行代码写文件输出到响应流：

EasyExcel.write(response.getOutputStream(), SignupExportVO.class) .sheet("报名名单") .doWrite(dataList);

可能还有人会问，做上传组件时需不需要考虑到大文件？如果只是活动封面图片、报名附件等，默认使用springboot的MultipartFile接收，再配合nginx的上传大小限制设置就完全足够，没必要一开始就上分片上传、断点续传那套重型方案。很多开发者和面试者会纠结热词里的“springboot如何上传下载大文件”，其实是把场景看得太重了。真正遇到超大文件场景，直接引入MinIO或者OSS，用预签名URL直传对象存储，比自己在springboot里写文件流要靠谱得多。系统开发的价值在做业务链路，而非重复造轮子。

4.4 定时任务与系统时钟设计

活动招募截至后，需要自动把活动状态从RECRUITING改成OFFLINE；活动结束时间到了，需要自动触发时长确认提醒。这种“到点自动处理”的场景，我直接用springboot自带的@Scheduled注解实现，没有引入Quartz等重量级定时框架。具体做法是在启动类或配置类上开启@EnableScheduling，然后写个独立的任务类，每分钟扫描一次活动表，命中条件就更新状态。这种轻量方案足以覆盖绝大多数中小型管理系统。

有个面试官常问的点：@Scheduled默认是单线程执行的，多个任务会互相排队阻塞。如果系统里有多个定时任务，我建议你配置一个线程池，设置@Scheduled的taskScheduler，否则哪天扫表任务跑慢了，另一个按时推送消息的任务就会延迟。具体配置在配置类里声明一个TaskScheduler类型的Bean即可，网上有大量现成例子可参考，这里就不做重复搬运。

5. 前端对接的核心衔接点与接口联调细节

一个springboot后端项目如果只是后端写完接口，离交付还差得很远。现在的管理系统基本都是前后端分离，所以必须把前端怎么对接、联调中的关键细节讲清楚，否则单独拿后端代码根本跑不起来完整演示。

5.1 前端项目结构与登录态对接思路

前端我用Vue + Element UI这套组合，做后台管理类项目非常顺手。项目内部分为几个核心视图：首页展示活动列表，提供分类筛选和关键词搜索；活动详情页展示活动介绍、剩余名额、报名按钮；个人中心展示我的报名记录和累计服务时长；后台管理页面由管理员或组织方按角色看到不同菜单。

登录态接管这块是前后端协作的重头戏。前端在用户登录成功后，把后端返回的token存入localStorage，同时在axios的请求拦截器里加上：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config })

后端再通过JWT过滤器校验请求头。这个方案的好处是后端接口可以做成无状态的，前端随便部署到哪台静态服务器都能对接，不需要考虑Session共享问题。

5.2 前后端联调时易踩的坑：跨域、时间格式、数据字典

联调阶段有几个高频问题，几乎每个项目都会踩到。第一个是跨域。开发环境前端跑在8080，后端跑在9090，直接发请求必然是跨域。处理办法我在前面提过，后端配置一个CorsFilter，放行前端地址和必要的请求头字段。千万别为了省事在Controller上加@CrossOrigin(origins = "*")还允许allowCredentials=true，这在浏览器端是非法的，请求会直接被拦截。

第二个是高危的日期格式问题。Java后端默认序列化LocalDateTime时，如果不加特殊配置，返回给前端的是类似2025-05-10T09:00:00的ISO格式，而很多前端组件默认期望的是yyyy-MM-dd HH:mm:ss。所以我会在配置里统一处理：

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

同时在实体上对时间字段使用@JsonFormat注解做兜底。这个坑在导出报名名单时更明显，因为Excel单元格里显示的是一串时间戳数字，一看就懵了。

第三个是数据字典的联动。活动状态字段在数据库存的是RECRUITING这种英文字符串，前端不能直接展示给用户，需要前后端约定好一组字典映射。我后端的做法是提供了一个/common/dict接口，返回所有状态对应的中文名称，前端在渲染时动态替换，防止硬编码。例如状态为RECRUITING显示“招募中”，OFFLINE显示“报名截止”。前期花点时间维护好这份字典，后面新增一个状态时，只改一处就行。

5.3 Swagger接口文档的配置与权限放行

接口联调离不开API文档。我在项目中引入Knife4j（Swagger的增强版），启动后访问/doc.html就能看到可视化的接口文档页面。要注意的是，Spring Security如果全站拦截，需要把Swagger需要的静态资源路径放行，否则前端连接口文档都打不开。在Security配置中放行这些路径：

.antMatchers("/doc.html", "/webjars/**", "/v3/api-docs/**", "/swagger-resources/**").permitAll()

这里也呼应了热词里“springboot jwt放开swagger”的需求。很多人被这个卡了很久，其实只要思路理清：Swagger资源路径是公开的，不需要登录态；业务接口需要JWT校验。不要图省事把所有接口全放行了，否则生产环境接口文档裸奔也是个安全隐患。关于上线前的安全收口，还有个实用小技巧：可以用Spring Boot的spring.profiles.active区分环境和配置，开发环境开启Swagger，生产环境彻底关闭。这会比手动删注解、改配置靠谱得多。

6. 常见问题与避坑实录：从启动失败到数据错乱

这部分我按真实开发中遇到的高频问题整理一个速查表，供大家搜问题的时候直接对照。

6.1 启动类与Mapper扫描问题

现象：启动时报Invalid bound statement (not found)，或者提示Mapper接口没有注入Bean。
原因：大多数情况下是启动类没有被扫描到，或者MyBatis的Mapper接口路径配置遗漏。
解决：启动类上加@MapperScan("com.example.volunteer.mapper")，或者在每个Mapper接口上加@Mapper注解。两者选一种即可，不要同时混用还疑神疑鬼。

6.2 数据库连接与时区问题

现象：数据库能连上，但插入时间数据时，时间整体晚8小时或直接报错说时区不识别。
原因：MySQL 8.0的连接驱动校验了服务端时区参数，而JDBC连接串没带serverTimezone。
解决：连接串统一使用：

jdbc:mysql://localhost:3306/volunteer?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

顺便检查一下服务器时间的时区配置。这一锤子下去能解决大部分“时间对不上”的灵异事件。

6.3 MyBatis-Plus的字段自动填充失效

现象：插入数据时，create_time、update_time字段是null，明明加了@TableField(fill = FieldFill.INSERT)。
原因：没有编写MetaObjectHandler的实现类去设置字段值，或者实现类没被Spring管理。
解决：实现一个MetaObjectHandler并注册为Bean，在insertFill中设置createTime与updateTime。这个问题在每届项目里几乎必现，大多是因为教程里只提了注解写法，没提触发注解的机制。

6.4 JWT过滤器重复放行和无限递归问题

现象：请求不是401，就是500，或者控制台报StackOverflowError。
原因：过滤器或拦截器配置里，某个路径匹配规则写错，导致请求在过滤器和业务之间反复循环；或者OncePerRequestFilter被注册到多个过滤链路中。
解决：JWT的校验推荐继承OncePerRequestFilter，确保每次请求只执行一次；同时在配置类中明确过滤范围，不让所有接口都进入过滤器后再内部判断。之前我排查过一个诡异的循环依赖问题，就是Security的配置和自定义过滤器互相引用导致的，最后把自定义过滤器改成构造器注入而不是字段注入解决。这也是springboot热词里经常提到的循环依赖典型场景。

6.5 前后端时间差8小时问题

现象：前端页面上显示的时间和数据库里的时间总差8个小时。
原因：前端JavaScript在显示时间时会默认转成本地时区，如果后端返回的字符串中没有带时区信息，不同浏览器解析出的结果不一致。
解决：最推荐的方式是后端返回时间戳毫秒值，前端负责格式化为本地时间。这种方式彻底绕开时区解析差异，但对改造量要求较高。如果项目快交付不想大改，就固定后端序列化格式为yyyy-MM-dd HH:mm:ss，前端拿到后直接当字符串展示，不经过new Date()转换。记住：对于管理系统，时间显示精度比时区语义更重要，直接展示不转换也能接受。

6.6 跨域请求拿不到token响应头

现象：前端发起登录请求成功后，想读取响应头里的token字段，结果读取到null，代码逻辑看着没问题。
原因：浏览器的跨域安全策略默认不允许JavaScript读取非白名单的响应头。
解决：后端CORS配置中增加暴露响应头的配置：

config.setExposedHeaders(Arrays.asList("token", "Authorization", "Content-Disposition"));

这个细节很小，但排查起来真的很费时间。我遇到过好几次前端同事拿着代码来找我，说“响应里明明有token，前端就是读不到”，其实后端就缺了这一行。

7. 部署与交付：从Windows开发到Linux服务器上线

项目写完了还只是第一步，真正检验系统是否健壮，要看能不能顺利部署运行。这部分很多同学会忽略，其实面试时问的“docker部署springboot项目”正是这里。我把基础的部署思路分享下，不需要太复杂但足够可靠。

7.1 环境准备和打包的细节

打包时我最常用的命令是mvn clean package -DskipTests，打包前先确认application.yml中数据源、Redis地址切换为生产环境配置。推荐的做法是把公共配置放在application.yml，不同环境的环境差异放在application-prod.yml，打包前手动指定profile或者用Maven的profile功能动态替换。系统做成Docker镜像时，在项目根目录写Dockerfile，制作基础镜像使用JDK8或JDK17，注意你的jar包版本要和基础镜像JDK版本匹配，否则启动报UnsupportedClassVersionError。之前见过有人用JDK17编出的jar包放在JDK8镜像里跑，排查了半小时才反应过来，相当委屈。

7.2 Nginx反向代理与前端静态资源托管

前端项目构建后会生成dist目录，通常部署方式是交给Nginx托管，同时把/api路径的请求反代到后端。

一个常见的Nginx配置片段如下：

server { listen 80; server_name your_domain; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:9090/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

注意proxy_pass http://127.0.0.1:9090/;末尾的斜杠，它表示将/api/user/info重写为/user/info，而不是/api/user/info。如果你的后端接口本身统一加了/api前缀，那proxy_pass结尾就不加斜杠。这是很多联调时后端接口一直404的高频原因，前后端两边来回甩锅，最后发现其实是Nginx路径写错了。

8. 项目扩展方向：从毕设到可落地系统的进阶之路

如果只是按课程设计的要求来，上面这些内容已经足够交差。但如果你想在简历上把它作为亮点项目，或者真的打算部署给一个实际组织使用，我建议再做一些扩展。第一是消息通知。目前大多数此类系统是站内信模式，用户很少会登录进去看，导致报名通过、活动取消这类重要消息无法及时触达。可以考虑接入邮件通知或微信模板消息，实现难度不大，但对系统价值的提升很明显。

第二是服务时长证明的自动生成。志愿者最看重的“证明”常常是纸质版加盖公章的，系统如果能提供在线生成、下载、二维码校验的功能，会让它比市面上一部分小型志愿者平台更有竞争力。实现思路不复杂，后端用EasyExcel输出记录表，再加一个PDF生成模板渲染即可，但这些细节看着小，却决定了系统能不能在实际场景里长期用下去。

第三是数据统计的可视化。可以用后端统一输出按月度、按活动的数据统计接口，前端用ECharts展示。给管理人员一个直观的仪表盘，无论是月度服务人次，还是活动类型分布，都能一眼看清。这个扩展往往能让项目在答辩或汇报时给评委/领导留下非常好的印象，因为大多数同类系统还停留在“列表+报表”阶段。

最后说一下我自己在多个志愿者类项目中沉淀的经验：这类系统的业务逻辑本身不强，真正的价值在于把招募流程中的沟通成本降到最低。所以开发时永远要记住，不要光盯着代码写得漂不漂亮，要多去现场和用户聊，了解组织方是怎么管理候补名单的、志愿者是怎么知道要穿什么衣服几点到场的，每一个诉求落进系统里，都比单纯堆上10张表有意义得多。项目交付后通常真实用户试运行一个月，哪些界面是摆设、哪些流程根本没走通，都会浮出水面，这时候再回头改，成本往往比一开始多想两天高出许多。

这个项目后续还可以往小程序方向扩展，毕竟现在使用频率高的工具一定是移动端优先的，后端接口做好抽象，前端再套一层uni-app外壳，就能把PC管理端和移动报名端同时覆盖。到时候核心逻辑一行不用改，springboot后端继续稳定输出，整个系统的适用范围又能扩大一圈。