1. 预报名系统的业务边界与需求拆解先聊一个很多初学者容易忽略的问题预报名管理系统到底解决的是什么痛点说实话我第一次接到类似需求的时候脑子里浮现的就是一个简单的表单页面用户填姓名、电话、备注提交完事。真正做过一轮之后才发现预报名场景远没有想象的那么简单。预报名和正式报名最核心的区别在于不确定性。正式报名通常已经确定了课程表、考场安排、缴费标准系统侧只需要做名额锁定和记录。而预报名阶段往往连最终的开班时间都还没定用户只是表达我有意向有好消息请通知我后台需要根据预报名的热度反向决定要不要开班、开几个班、安排在哪个时间段。这就让系统的业务逻辑比单纯的信息登记复杂了一个层级。从模块划分来看这套基于SpringBoot Vue MySQL的预报名管理系统核心围绕着三条主线活动/项目维度后台管理员创建预报名的项目或者活动设置报名起止时间、人数上限、是否需要审核、是否需要填写扩展字段。用户报名维度前端用户浏览可报名的项目填写报名信息查看自己的报名状态支持取消报名。管理审核维度后台人员查看报名列表筛选、导出、审核通过或驳回并能够统计报名数据。技术栈的组合本身并不复杂——SpringBoot负责提供RESTful接口Vue负责页面交互MySQL负责持久化存储。这套架构之所以在中小型管理系统中被广泛应用是因为它有一个非常务实的优点每个环节都有大量成熟方案碰到问题能快速找到答案不会卡在某个只有作者会用的冷门技术上。对于想拿这套源码做毕业设计、课程设计或者学习前后端分离开发模式的人来说不建议一上来就钻进代码细节里。先把这个系统的业务闭环走通——谁能做什么、数据怎么流转、状态怎么变化——再去看代码会发现每一行都顺理成章。这也是我这篇文章想带着你做的事情。2. 技术选型逻辑这套组合为什么不用更新的2.1 SpringBoot的优势不是因为它最强而是因为它省心我在不少技术交流群里见过类似的问题SpringBoot版本太高怎么办、SpringBoot 2.x和3.x差别大吗。这些问题背后其实暴露了一个普遍困惑——SpringBoot的版本迭代太快了跟着教程做往往在第一步环境配置就垮掉。就预报名管理系统这个场景来说选择一个稳定、资料丰富、社区讨论量大的版本远比追求最新版本重要。SpringBoot最核心的价值在于自动装配机制——它通过EnableAutoConfiguration配合大量的spring.factories配置把原本Spring MVC项目中繁琐的XML配置、Bean声明、组件扫描全部自动化了。你只需要引入对应的starter依赖框架就能根据classpath下的jar包自动推断你要做什么。以这套系统的后端为例核心依赖就几个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency引入spring-boot-starter-web之后内嵌的Tomcat就自动配置好了你不需要单独安装一个Tomcat再部署war包。spring-boot-starter-validation帮你在Controller层直接做参数校验不用自己写一堆if判断。这种开箱即用的体验对于业务逻辑相对标准化的管理系统来说非常合适。有些人可能会问为什么不用Spring Cloud或者微服务架构这个问题我在做技术方案评审的时候被问过很多次。答案很简单预报名系统的并发量和业务复杂度根本到不了需要拆微服务的程度。微服务解决的是团队协作、独立部署、弹性伸缩的问题但它带来的服务发现、配置中心、链路追踪、分布式事务这些复杂度在一个单体应用就能搞定的事情上纯粹是负担。单体应用 合理的模块划分已经覆盖了90%的中小系统需求。2.2 Vue的价值渐进式框架如何降低前后端协作成本前端选择Vue一个很务实的理由是目前国内中小团队的Vue熟练度普遍高于React而且Element UI这类的组件库让后台管理页面的开发效率提升得非常明显。Vue的设计哲学是渐进式——你可以只用它的模板语法做简单的页面渲染也可以配合Vue Router做单页应用再进一步用Vuex或Pinia做状态管理。对于预报名管理系统这种页面数量在十到二十个之间的项目Vue的组件化开发方式尤其舒服公共的表格、弹窗、表单校验逻辑抽成组件每个页面的代码量能压缩一半以上。这里我特别想强调一个点也是我在实际开发中踩过的坑Vue项目的组件划分粒度要有边界。有些新手喜欢把所有东西都抽象成组件一个简单的输入框也要包一层v-model再透传结果项目里全是嵌套层级很深的组件父子通信能把人绕晕。预报名管理系统里页面级别的功能差异足够大组件抽到报名表单、报名列表、状态标签这个粒度就够了再细就没有必要了。2.3 MySQL的选择关系型数据库在这个场景下的不可替代性报名数据的核心特点是强结构化姓名、手机号、报名时间、报名状态、关联的活动ID每一列的类型和长度都是明确的。这正是关系型数据库最擅长处理的场景。MySQL在这个项目里的角色不只是存数据那么简单它还承担了数据一致性保障。预报名系统有一个非常典型的并发场景一个活动报名名额只剩最后一个同时有十个用户提交报名请求。如果没有数据库层面的事务和锁机制超卖问题几乎是必然的。在MySQL中通过SELECT ... FOR UPDATE或者乐观锁版本号机制就能解决这个问题这类成熟方案是NoSQL数据库很难替代的。另外管理后台的统计报表功能——按日期的报名趋势、不同活动的热度排行、审核通过率——这些都需要对结构化数据做聚合查询MySQL的GROUP BY和COUNT配合索引查询性能在万级数据量下完全是毫秒级响应不需要引入额外的OLAP组件。项目基础数据量几千到几万条报名记录数据关联复杂度活动、报名人、审核记录三层关联查询模式以条件筛选和统计聚合为主一致性要求名额不能超卖状态不能错乱这个清单一列选MySQL就是顺理成章的事。技术选型不是选最炫的而是选最匹配业务特征的。3. 数据库模型设计预报名系统的核心表结构与关系梳理3.1 四张核心表的分工预报名管理系统的数据库设计几乎所有变体都逃不出四张核心表的框架活动表、报名表、用户表、审核记录表。这里我把每一张表的关键字段设计思路拆开讲因为有太多人拿到的源码里SQL脚本写得云里雾里看不明白为什么要建这些字段。-- 活动/预报名项目表 CREATE TABLE activity ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键ID, title varchar(100) NOT NULL COMMENT 活动标题, description text COMMENT 活动详情描述, start_time datetime NOT NULL COMMENT 报名开始时间, end_time datetime NOT NULL COMMENT 报名结束时间, quota int NOT NULL DEFAULT 0 COMMENT 名额限制0表示不限, need_review tinyint(1) NOT NULL DEFAULT 1 COMMENT 报名是否需要审核, status tinyint NOT NULL DEFAULT 0 COMMENT 状态0草稿1发布中2已结束, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status_time (status, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预报名活动表;活动表里的need_review字段很有意思它代表了预报名系统的两种运营模式。模式一是低门槛收集意向用户提交即成功后台只看数据做分析这种场景need_review设为0模式二是需要筛选参与人员比如名额有限的高质量培训后台要逐个审核报名信息这时need_review就设为1。一个布尔字段就把系统的两种业务流程统一起来了这是设计上的一个巧思。报名表是整个系统里数据量增长最快、查询压力最大的表核心字段包括报名人信息、关联活动、报名状态、自定义表单内容CREATE TABLE enrollment ( id bigint NOT NULL AUTO_INCREMENT, activity_id bigint NOT NULL COMMENT 关联活动ID, user_id bigint NOT NULL COMMENT 报名用户ID, name varchar(50) NOT NULL COMMENT 联系人姓名, phone varchar(20) NOT NULL COMMENT 联系手机号, ext_fields json DEFAULT NULL COMMENT 扩展字段JSON格式存储, status tinyint NOT NULL DEFAULT 0 COMMENT 状态0待审核1已通过2已驳回3已取消, remark varchar(500) DEFAULT NULL COMMENT 审核备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_activity_status (activity_id, status), KEY idx_user_id (user_id), KEY idx_phone (phone), CONSTRAINT fk_activity FOREIGN KEY (activity_id) REFERENCES activity (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报名记录表;这里有两个设计细节值得展开说。第一ext_fields字段用了JSON类型。为什么要这样设计因为不同的预报名活动需要的报名信息不一样——有的要填公司名称有的要填学校专业有的要填身份证号。如果把这些字段一列一列建出来每次新增活动类型都要改表结构非常痛苦。用JSON字段存储扩展信息数据库结构不动前端的动态表单也能灵活适配。这种设计是典型的面向扩展思路在真正的企业项目中非常实用。第二联合索引idx_activity_status的建立顺序。activity_id在前、status在后这个顺序是经过考虑的。后台最常见的查询场景是查看某个活动下的所有报名记录然后再按状态筛选。WHERE activity_id ? AND status ?这种查询联合索引能直接命中。反过来如果单独把status建索引这个查询只能走一个索引效率会打折扣。3.2 用户表与审核记录权限控制和流程追踪用户表的设计相对简单重点是区分管理员和普通用户CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 用户名, password varchar(100) NOT NULL COMMENT 密码BCrypt加密, nickname varchar(50) DEFAULT NULL, user_type tinyint NOT NULL DEFAULT 0 COMMENT 0普通用户1管理员, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;密码字段用BCrypt加密这个细节大二学生写课程设计的时候可能不太注意但在企业项目里这是安全底线。明文存储密码的后果不需要多说一旦数据库泄露就是灾难。Spring Security或者spring-security-crypto包里的BCryptPasswordEncoder能直接搞定加解密建议学习这个项目的时候直接保留这种实现。审核记录表单独拆出来的原因也很简单——审核是一个多轮可能发生的过程。用户提交报名后第一次被驳回修改信息后重新提交管理员再次审核通过这期间每一步的操作人和操作结果都值得留下记录。如果只在一张报名表里更新状态字段当出现争议时完全没有追溯能力。审核状态流转待审核 → 通过/驳回驳回后再提交已驳回 → 待审核 → 通过用户主动取消已通过 → 已取消这些状态流转的逻辑在后续前端页面的按钮显隐控制和后端接口的状态校验中都有体现。4. 后端SpringBoot核心接口实现从登录鉴权到报名提交4.1 项目分层结构与统一返回格式拿到源码之后先看后端的包结构。标准的SpringBoot项目分层是controller、service、mapper、entity或者叫domain、config、common这几层。每一层都有明确的职责边界controller层接收HTTP请求做基础的参数校验调用service层封装返回值service层业务逻辑的核心事务控制、状态流转、数据操作编排mapper层数据访问对应MyBatis的接口定义和XML映射entity层数据库表对应的实体类common层统一返回结果、异常处理、工具类这套系统里有一个很重要的设计——统一返回结构Result。它长这样public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }不管接口返回的是列表、详情、还是操作是否成功统一包一层code、message、data。前端axios拦截器里拿到响应后先判断code是否为200不是的话直接弹message提示用户。这种约定让前后端联调时不需要每个接口单独对格式协商成本大大降低。4.2 登录鉴权拦截器方案还是JWT方案登录鉴权是管理系统的刚需功能。这个预报名系统里普通用户报名不需要登录或者用手机号验证码即可但后台管理必须登录后才能访问。项目里常用的方案有两种基于Session的拦截器方案和基于JWT的Token方案。对于单体应用Session方案实现起来最简单——用户登录成功后把用户信息存入Session拦截器里检查Session是否存在。但前后端分离的架构下Session方案会碰到跨域Cookie的问题需要额外配置CorsFilter允许携带凭证。JWT方案则天然免疫跨域问题服务端签发一个Token返回给前端前端每次请求在Authorization头里带上服务端校验签名即可。这套系统如果代码里已经集成了JWT核心代码是这样Component public class JwtUtils { Value(${jwt.secret}) private String secret; Value(${jwt.expire}) private Long expire; public String generateToken(Long userId, String username, Integer userType) { Date now new Date(); Date expireDate new Date(now.getTime() expire * 1000); return Jwts.builder() .setHeaderParam(typ, JWT) .setSubject(username) .claim(userId, userId) .claim(userType, userType) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } }对应的拦截器实现中在preHandle方法里从请求头取出Token解析成功则放行失败则返回401。注意HandlerInterceptor注册时需要用WebMvcConfigurer指定拦截路径通常把/api/admin/**和/api/enrollment/**分别拦截因为普通报名接口和后台管理接口的鉴权要求不一样。对于/api/admin/**必须登录且是管理员才能访问报名接口则放宽到任意用户均可访问。4.3 报名提交接口事务与并发控制报名提交是整个系统最核心的接口实战中也会暴露最多的问题。先看逻辑主体Override Transactional(rollbackFor Exception.class) public void submitEnrollment(EnrollmentSubmitDTO dto) { // 1. 校验活动是否存在且在报名时间内 Activity activity activityMapper.selectById(dto.getActivityId()); if (activity null) { throw new BusinessException(活动不存在); } if (activity.getStatus() ! 1) { throw new BusinessException(活动未发布); } Date now new Date(); if (now.before(activity.getStartTime()) || now.after(activity.getEndTime())) { throw new BusinessException(不在报名时间范围内); } // 2. 名额校验乐观锁方式 if (activity.getQuota() 0) { int updated activityMapper.deductQuota(activity.getId(), activity.getQuota()); if (updated 0) { throw new BusinessException(报名名额已满); } } // 3. 保存报名记录 Enrollment enrollment new Enrollment(); enrollment.setActivityId(dto.getActivityId()); enrollment.setUserId(dto.getUserId()); enrollment.setName(dto.getName()); enrollment.setPhone(dto.getPhone()); enrollment.setExtFields(dto.getExtFields() ! null ? JSON.toJSONString(dto.getExtFields()) : null); enrollment.setStatus(activity.getNeedReview() ? 0 : 1); enrollmentMapper.insert(enrollment); }这段代码里有三个值得注意的工程细节。第一个是Transactional(rollbackFor Exception.class)——Spring事务默认只在遇到RuntimeException时回滚如果业务中抛出的是受检异常不指定rollbackFor事务不会回滚这是无数人踩过的坑。第二个是名额扣减的乐观锁设计。deductQuota方法的SQL是UPDATE activity SET quota quota - 1 WHERE id #{id} AND quota 0通过quota 0这个条件做原子性的行锁保护在高并发下数据库会自动串行化这些UPDATE操作有效避免超卖。如果使用原生Java的同步锁或分布式锁在这个场景下属于杀鸡用牛刀而且分布式锁的引入还会带来新的复杂度和运维成本。第三个是状态初始值的业务映射——activity.getNeedReview()为true时报名记录初始状态是待审核不需要审核时直接初始化为已通过。这段逻辑虽然只有一行但它体现了系统的两种流程在数据层面的落地方式。4.4 后台管理接口列表分页、审核操作与数据导出后台管理接口相对直白但有几个细节我喜欢专门讲。第一个是分页查询的封装。MyBatis分页通常用PageHelper插件一行代码搞定Override public PageResultEnrollmentVO pageQuery(EnrollmentQueryDTO queryDTO) { PageHelper.startPage(queryDTO.getPageNum(), queryDTO.getPageSize()); ListEnrollmentVO list enrollmentMapper.selectByCondition(queryDTO); PageInfoEnrollmentVO pageInfo new PageInfo(list); return PageResult.of(pageInfo.getTotal(), pageInfo.getList()); }注意PageHelper.startPage之后必须紧跟第一条查询语句中间不能有任何其他数据库操作这是这个插件最著名的坑。第二个是审核操作。审核不只是改一个状态字段还需要写审核记录。所以审核接口的事务范围要包含两步更新报名表的status和remark字段同时往审核记录表插入一条记录。这一步很容易遗漏审核记录是审计追踪的基础没有的话以后扯皮都找不到依据。第三个是数据导出。管理系统必备的Excel导出项目里常用阿里开源的EasyExcel写法很简单Override public void exportEnrollments(HttpServletResponse response, Long activityId) throws IOException { ListEnrollmentExportDTO list enrollmentMapper.selectExportData(activityId); response.setContentType(application/vnd.ms-excel); response.setCharacterEncoding(utf-8); response.setHeader(Content-Disposition, attachment;filenameenrollments.xlsx); EasyExcel.write(response.getOutputStream(), EnrollmentExportDTO.class) .sheet(报名数据) .doWrite(list); }EnrollmentExportDTO上用ExcelProperty注解标注每一列的标题和顺序导出时自动和实体属性匹配。EasyExcel解决了传统POI导出大文件时内存溢出的问题这在处理几万条报名数据时特别重要。5. 前端Vue页面与交互动态表单、状态管理和管理后台5.1 前端路由规划和页面结构Vue前端的核心结构我建议先从router/index.js看起。这套系统的路由设计要区分两个端面向普通用户的报名端和面向管理员的运营端。两种端共用一个Vue应用通过路由前缀和导航守卫做权限控制。路由规划大致如下const routes [ { path: /, component: HomeView, meta: { title: 首页 } }, { path: /activity/:id, component: ActivityDetail }, { path: /enroll/:id, component: EnrollForm }, { path: /my-enrollments, component: MyEnrollments }, { path: /admin, component: AdminLayout, requireAuth: true, children: [ { path: dashboard, component: Dashboard }, { path: activity/list, component: ActivityList }, { path: activity/edit/:id?, component: ActivityEdit }, { path: enrollment/list, component: EnrollmentList }, { path: statistics, component: Statistics } ] } ]requireAuth: true配合Vue Router的全局前置守卫router.beforeEach((to, from, next) { if (to.requireAuth !localStorage.getItem(token)) { next({ path: /login }) } else { next() } })这段守卫的意义在于不是每个页面都需要登录但后台管理的所有页面必须校验登录状态。路由级权限控制和接口级权限控制是两道防线前端控制的是用户体验后端控制的是数据安全。前端路由守卫可以被轻松绕过所以它只是装饰真正的鉴权一定在后端接口。这一点在做项目汇报的时候经常被问到一定要能讲清楚。5.2 axios封装与请求拦截统一处理Token和异常前端里隐藏的一个重点工程是axios实例的封装。几乎所有靠谱的Vue项目都有一个utils/request.js文件作用是从此以后所有页面组件里的API调用都复用同一个请求实例不用重复处理Token、错误提示和加载状态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 ! 200) { ElementUI.Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } ElementUI.Message.error(网络异常请稍后重试) return Promise.reject(error) } )这里的思路很清晰请求发出前自动带Token响应回来后自动判断业务码401时自动跳转登录页。组件层的业务代码只需要关注成功的数据流转异常处理全部收敛到这一层。这是Vue开发中区分新手和熟练工的分水岭之一。5.3 动态表单组件让表单字段跟着活动配置走预报名系统的一个亮点功能是动态表单。前面数据库设计时提到ext_fields字段用了JSON存储那前端如何实现不同活动展示不同报名表单核心思路是活动创建者在后台编辑活动时可以自定义一组表单字段配置如[ { key: company, label: 公司名称, type: input, required: true }, { key: position, label: 职位, type: input, required: false }, { key: experience, label: 从业年限, type: number, required: true } ]前端报名页根据这个配置数组动态渲染表单项template el-form :modelform :rulesrules refenrollForm el-form-item v-forfield in activity.extConfig :keyfield.key :labelfield.label :propfield.key el-input v-iffield.type input v-modelform[field.key] :placeholder请输入 field.label / el-select v-else-iffield.type select v-modelform[field.key] el-option v-foropt in field.options :keyopt :labelopt :valueopt / /el-select /el-form-item el-button typeprimary clicksubmitForm提交报名/el-button /el-form /template这种设计让系统在不改代码、不改数据库的情况下支持任意类型的预报名表单。新增一场需要收集职称上传证书照片的活动时管理员在后台配置一下就行研发完全不需要介入。这就是动态表单的价值——把高频的业务变化从代码层释放出来交给运营人员自助完成。当然动态表单还涉及校验规则的动态生成不能只做渲染。前端根据字段配置里的required布尔值动态生成rules对象传给el-form如果没有配置任何扩展字段就只展示姓名和手机号两个公共字段逻辑上要覆盖这种边界情况。5.4 管理后台的列表页与统计报表展示管理后台的列表页是另一个高频使用的页面它的核心交互是条件筛选、分页、批量操作。用Element UI的el-table配合el-pagination组件代码结构非常规整el-table :datatableData v-loadingloading el-table-column propid labelID width80 / el-table-column propname label姓名 width120 / el-table-column propphone label手机号 width140 / el-table-column label状态 width100 template slot-scopescope el-tag :typestatusTagMap[scope.row.status] {{ statusTextMap[scope.row.status] }} /el-tag /template /el-table-column el-table-column label提交时间 propcreateTime / el-table-column label操作 width220 template slot-scopescope el-button sizemini clickhandleView(scope.row)详情/el-button el-button v-ifscope.row.status 0 sizemini typesuccess clickhandleApprove(scope.row)通过/el-button el-button v-ifscope.row.status 0 sizemini typedanger clickhandleReject(scope.row)驳回/el-button /template /el-table-column /el-table按钮的v-if条件绑定状态值这一点建议在源码里仔细品味——它体现了操作可用性由数据状态驱动的交互设计思路。用户提交报名后列表里对应的操作按钮只会在待审核状态时出现通过和驳回审核通过的记录则只有查看按钮。这种收敛的操作设计能在交互层面防止大部分误操作。6. 本地运行部署从环境准备到系统启动的完整配置6.1 环境部署清单与版本匹配源码标注可直接运行但直接运行是有前提条件的——环境必须匹配。这里我列一个实测过的环境组合照着这个版本搭配基本不会出问题组件推荐版本注意事项JDK1.8 或 11SpringBoot 2.x最高支持到JDK 17不建议用太高版本Maven3.6项目依赖下载的构建工具MySQL5.7 或 8.0注意字符集统一为utf8mb4Node.js14.x 或 16.xVue CLI和依赖编译需要不建议用太新的18版本npm/yarn6.x / 1.x安装依赖用yarn速度更快关于SpringBoot版本我再多说一句。热搜里有个词叫springboot版本太高这确实是很多初学者卡住的地方。SpringBoot 3.x基于JDK 17很多老教程的配置和依赖坐标都不一样切到SpringBoot 3.0之后照着2.x教程写代码大概率会报错。做毕设和实战项目建议直接锁定SpringBoot 2.7.x这是2.x系列的长期维护版本资料最丰富坑最少。6.2 MySQL初始化三步走数据库初始化是新手翻车重灾区这里拆开讲清楚。第一步启动MySQL服务。Windows下打开服务管理器services.msc确认MySQL服务已启动。如果是用宝塔面板或者Docker部署的MySQL确认端口3306没被防火墙挡住。第二步创建数据库并设置字符集CREATE DATABASE IF NOT EXISTS enrollment_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;直接用Navicat或者命令行执行项目里带的sql/init.sql脚本脚本里会创建上面提到的四张核心表并插入一条默认管理员账号。第三步执行脚本后验证表是否创建成功USE enrollment_system; SHOW TABLES; SELECT * FROM user;如果user表里能看到初始化插入的管理员账号说明数据库层已经就绪。6.3 后端配置文件的修改点打开src/main/resources/application.yml需要改的无非这几个地方server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/enrollment_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.enrollment.entity configuration: map-underscore-to-camel-case: true jwt: secret: your-secret-key-please-change expire: 86400这几个配置项逐个解释清楚url里的serverTimezoneAsia/Shanghai必须加不加的话高版本MySQL驱动和本地时区不一致会报错。useSSLfalse是为了避免本地测试时的SSL握手警告。password改成你自己本机MySQL的root密码这个是最容易漏改的地方。map-underscore-to-camel-case: true让数据库的下划线字段名自动映射成Java的驼峰属性名phone_number字段自动对应phoneNumber属性不用每张表手写resultMap。jwt.secret建议改成一个自己的随机字符串不要用项目默认值否则Token安全形同虚设。后端启动命令也很简单——在项目根目录执行mvn spring-boot:run或者用IDE里直接运行Application类。看到日志里出现Started Application in x.xxx seconds后端就启动成功了。测试接口是否正常浏览器访问http://localhost:8080/api/health或者直接请求登录接口即可。6.4 前端的依赖安装与开发服务器配置前端目录通常是frontend或者web。进入目录之后npm install这一步耗时长短取决于网速和镜像源。如果卡在node-sass这类需要编译的依赖上大概率是Node版本兼容性问题建议先删掉node_modules和package-lock.json换用npm cache clean --force后重装或者直接换用国内的镜像源。依赖装完之后需要检查vue.config.js里的代理配置module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这个代理配置解决的是开发环境的跨域问题。前端跑在3000端口后端跑在8080端口浏览器直接发请求到/api会跨域。配置代理后Vue开发服务器会把/api开头的请求转发到8080前端代码里不需要任何跨域处理浏览器也感知不到代理的存在。然后启动前端npm run serve浏览器访问http://localhost:3000用数据库初始化脚本里预设的账号登录后台整个系统就跑起来了。7. 运行期高频问题与排查思路关于版本、跨域和打包的实战记录7.1 MySQL连接失败的完整排查链路数据库连不上是问得最多的问题。我把它从现象到结论的排查链路完整梳理一遍你在自己的环境上照着走基本能定位到病根。第一步确认MySQL服务真的在运行。这步不用写代码直接检查系统的进程列表或服务管理器或者执行一个最简单的连接命令mysql -u root -p看看能不能进。第二步确认JDBC连接串没写错。最容易犯错的有三处一是localhost:3306写成了192.168.x.x:3306本机连接没必要绕远端二是数据库名和实际创建的不一致大小写也要精确匹配三是characterEncodingutf8写成了utf-8竖杠字符在连接串里会被解析成特殊符号连接直接失败。第三步看驱动类是否匹配MySQL版本。MySQL 8.x用的是com.mysql.cj.jdbc.DriverMySQL 5.7及以下用的是com.mysql.jdbc.Driver。如果驱动和数据库版本对不上启动时就会报ClassNotFoundException或者驱动类的具体方法不存在。第四步排查权限问题。MySQL 8.0默认的认证插件是caching_sha2_password而比较老的连接驱动可能只支持mysql_native_password。解决办法是创建一个兼容账号CREATE USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 密码;或者直接用命令行连接到MySQL里执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 密码;。改完之后记得FLUSH PRIVILEGES;。7.2 Vue前端页面常见异常打包后布局乱掉与404问题热搜词里有一条vue 打包后 布局异常这和开发环境正常但生产环境白屏或404是同一类问题根源几乎都出在静态资源路径上。默认情况下Vue CLI脚手架生成的项目publicPath是/打包后的index.html引用的CSS和JS路径是绝对路径。如果你把打包产物部署到服务器某个子目录下比如http://xxxx/enroll-system/绝对路径/static/js/app.js就会去域名根目录找文件自然404。解决方案是在vue.config.js里修改module.exports { publicPath: ./, outputDir: dist, assetsDir: static }publicPath: ./会让打包后的资源路径变成相对路径static/js/app.js会相对于当前目录解析,这样部署到任意子目录都不怕。同理用vue-router的history模式时刷新子页面会出现404因为服务器不知道/admin/enrollment/list这个路径应该指向同一个index.html。解决方式要么改用hash模式createWebHashHistory要么在Nginx配置try_files $uri $uri/ /index.html;。7.3 跨域问题:开发环境代理和生产环境的Nginx配置跨域这个问题本质上是因为浏览器的同源策略当前页面地址是http://localhost:3000请求http://localhost:8080/api协议、域名、端口三者中端口不同属于跨域。开发环境用了Vue的proxy代理浏览器和前端服务器同源前端服务器再和后端服务器通信绕过了同源策略。但生产环境没有Vue开发服务器通常是用Nginx同时托管前端静态文件和反向代理后端接口server { listen 80; server_name your-domain.com; # 前端静态文件 root /var/www/enrollment/dist; index index.html; # 解决history路由刷新404 location / { try_files $uri $uri/ /index.html; } # 后端接口代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这套配置下来生产环境上用户访问的是80端口所有/api请求由Nginx转发到8080的SpringBoot服务前后端之间根本不会有浏览器层面的跨域问题。7.4 启动端口占用与依赖冲突的快速处理最后补一个几乎所有SpringBoot项目都会遇到的经典问题Port 8080 was already in use。端口被占用处理方式很直白Windowsnetstat -ano | findstr 8080查看PID再用taskkill /F /PID 进程号清理。Linux/Maclsof -i:8080查看占用进程再kill -9 进程号。但更稳妥的做法是把项目端口换掉或者让其他占用的服务换端口。因为8080端口被各种开发工具占用的概率实在太高换一个不常用的如9090可以少很多折腾。至于依赖冲突问题最常见的表现是启动时NoSuchMethodError或者NoClassDefFoundError。这时候可以执行mvn dependency:tree查看依赖冲突的具体情况再用exclusions标签排除掉重复的传递依赖。不过这个问题的排查复杂度比较高如果项目能正常跑起来一般不建议动依赖版本。8. 这套源码的扩展方向从预报名到通用报名平台8.1 系统当前的能力边界预报名管理系统能做的事情是清晰的创建活动、发布报名、用户填报、后台审核、数据导出。这套闭环覆盖了中小型机构80%的报名业务场景。但它也有明显的能力边界理解这个边界才能知道往哪个方向改。目前在多数变体中系统缺少通知能力——用户报名成功、审核通过、活动即将开始这些关键节点没有短信或邮件通知用户需要自己刷新页面查状态。对于预报名产品来说通知机制恰恰是提升用户转化率的关键一环用户留下联系方式但后续没有任何触达前面收集的线索就浪费了。系统也缺少支付能力——部分预报名场景需要收取定金锁定名额当前的报名流程到提交信息为止。扩展支付接口不难难的是支付回调、订单状态、退款流程这些电商级逻辑的引入会让系统复杂度成倍上升。8.2 推荐的演进路径如果这套源码是你的毕业设计或者个人作品我有几条可以马上落地的演进建议第一优先级的扩展是二维码分享和核销。每个活动自动生成一个带参数的二维码扫码直达报名页报名成功后生成一个核销码管理员在入场时扫码完成到场标记。这个功能贴合实际运营场景技术上也很好实现——用ZXing生成二维码加上一个checkin_status字段就行。第二优先级的扩展是数据看板和报表增强。当前系统的统计功能如果只有一个简单的数字汇总可以升级为按小时/按天粒度的报名趋势图、不同渠道来源的占比饼图、转化漏斗图。前端引入ECharts后端加几个聚合查询接口整个系统的高级感会立刻上一个台阶。第三优先级的扩展是多租户支持。如果想把系统从一个机构的工具变成SaaS产品需要在活动表、报名表上加tenant_id字段所有业务接口按租户隔离登录时携带的Token里解析出租户信息。这一步改动涉及全链路适合对源码已经非常熟悉之后再动手。8.3 学习这套源码的最佳路径最后结合我自己带团队的经验谈谈怎么高效消化这套源码。很多学习者拿到项目第一步就是打开IDE跑起来然后一个文件一个文件从头看到尾三天之后看后面的忘前面的这是典型的低效路径。我更推荐的顺序是这样先跑起来用管理员账号建一个活动再开一个普通用户视角提交一条报名信息完整走一遍业务闭环。然后追着一条数据走——从前端的报名表单向后端接口发请求经过Controller、Service、Mapper最终落到MySQL的一张表里把这条链路上涉及的每个文件和每段代码串起来。再挑一个你不理解的设计点比如为什么不直接删报名记录而是用状态去取消去源码里找答案想明白设计者的考量。最后才是大规模读代码此时你已经有了全局视图读起来完全不会迷路。这套源码的价值不在代码量而在于它是一条完整的业务闭环和工程化实践样板。把这条链路吃透往后你自己独立做类似的管理系统架构设计上基本不会犯方向性错误。我在实际项目中带过的几个新人按这个路径学完独立上手一个CRUD系统的时间从原来的两三周缩短到了一周左右。如果只让我留一句心得那就是拿到源码别急着复制粘贴跑结果先让自己变成这个系统的产品经理再当它的研发负责人。思路通了代码只是表达。