简介：基于Java Spring、MySQL与Vue.js的平行志愿录取系统课程设计完整源码包，面向数据库课程设计学生及需要全栈项目参考的开发者，尤其适用于广东工业大学的数据库课程设计。资源共包含195个文件，压缩包约9.4MB，主要文件类型包括40余个Java后端源码、50个JavaScript前端逻辑、27个CSS样式、SQL建表脚本，以及XML、properties等配置文件，同时附带前端构建产物和少量图标字体等静态资源，目录结构清晰，基本覆盖系统开发所需核心内容。已有超过1.1万人学习下载，参考价值较高，可用于数据库课程设计答辩、系统功能演示及Spring+Vue+MySQL全栈实践。通过这份资源可获取平行志愿录取业务逻辑、前后端交互实现、数据表设计脚本等关键内容，帮助快速理解整体项目结构，并在此基础上进行二次开发或完善课程设计文档。
1. 数据库课程设计不靠运气：平行志愿录取系统如何把业务闭环装进 MySQL 与 Spring
我本来对所谓“精美版”课程设计资源抱有相当深的怀疑，这类 zip 见多了，解压之后往往是一堆半成品页面加一篇套话文档。但这套平行志愿录取系统让我改了判断：压缩包里的前端静态文件是带 hash 的构建产物，后端是 Spring + Java，数据层是 MySQL，业务本身覆盖了从考生信息、志愿填报到位次排序、名额扣减、录取结果生成的完整闭环。对正在准备数据库课程设计、又不想做传统图书管理系统的同学来说，这套资源真正补上了最缺的算法逻辑和前后端联通关系，下面我按拆解的顺序把怎么用它讲清楚。
2. 资源拆解与技术选型：从文件清单反推项目边界
2.1 解压后的第一眼：hash 命名的静态文件暴露了工程化程度
拿到任何课程设计压缩包，我第一件事不是点开说明文档，而是先看文件结构。这次的清单很有意思，mvnw.cmd 站在前排，后面跟着一批 chunk 前缀的 CSS 文件。mvnw.cmd 是 Maven Wrapper 的 Windows 启动脚本，作用是把 Maven 版本锁定在项目自己的配置里，避免“我这能跑你那就不能跑”的环境差异问题。而 chunk-vendors.70a052c3.css、chunk-448d2a85.afa49312.css 这类带 hash 的文件，是前端打包工具生成的静态资源。hash 是内容摘要，内容一改文件名就变，浏览器可以通过文件名变化判断该不该重新拉取缓存。
看到这一串文件量，基本可以确定前端用的是 Vue CLI 那套工程化构建。Vue 项目的标准构建流程会把代码拆成 vendor（第三方依赖）、app（业务代码）和若干个 route chunk（路由分包），每个包对应一到多个 CSS 与 JS 文件。清单里出现多个 chunk 开头的 CSS，说明项目做了代码分割，不同页面或组件有自己的独立样式文件。对一个课程设计而言，这个打包配置不是默认生成出来就完事的，而是经过认真组织过的。能够在答辩现场回答“前端资源是怎么组织的”这个问题，本身就是加分项。
那这些文件来源于哪里。答案是一个叫 dist 或者 build 的前端构建产物目录，正常情况目录里会有一个 index.html，通过 link 和 script 标签引用这些 hash 命名的 CSS 与 JS 文件，同时还有一个 assets 或 static 目录存放图片和字体。后端项目拿过来之后，把 dist 目录交给 Nginx 或者配置成 Spring Boot 静态资源映射，再启动后端服务，前后端就能联调起来。理解这个文件关系很重要，因为很多初学者只解压、复制，发现页面打不开就认为资源有问题，其实只是没有把静态资源正确放上去。
提示：识别 Vue 构建产物最直接的方法是找到 index.html，检查里面 link/script 标签引用的文件名，是否和 assets 目录下的哈希文件一一对应。对应不上，页面就会白屏。
把文件清单再往前推理一步就能得到完整的工程骨架。mvnw.cmd 与 mvnw 这一对文件是 Maven Wrapper 的双平台入口，分别服务 Windows 与 Linux/macOS，这里出现的是 Windows 版本，说明项目在 Windows 环境下验证过。再加上 pom.xml 和 src 目录，基本可以认定这是一个由标准脚手架生成并经过二次开发的 Spring Boot 工程。Maven Wrapper 的作用不复杂，它会按 maven-wrapper.properties 里锁定的版本自动下载 Maven，把环境搭建成本压到最低。
2.2 平行志愿录取的业务闭环：五个环节串起一条完整的数据库设计链
平行志愿是一个真实存在的录取规则，不是为作业凭空捏造的业务。它的核心规则可以压缩成九个字：分数优先、遵循志愿、一轮投档。考生按位次排队，位次靠前的人先被处理；每个考生手里有多个志愿，系统从第一个志愿开始探测，有空位就投，没空位就换下一个。一旦投出，本轮就不会再检索后续志愿。
放到数据库设计语境里，这个业务天然包含五个必须落地的模块：考生信息管理、招生计划维护、志愿填报、投档执行、录取结果查询。我习惯把这五个模块画成一张输入输出表，答辩时照着讲思路非常顺畅。
| 功能模块 | 输入 | 关键动作 | 输出 | 依赖的数据库特性 |
|---|---|---|---|---|
| 考生管理 | 考生号、姓名、总分、位次 | 增删改查 | 考生记录 | 唯一索引、排序 |
| 招生计划 | 院校、专业、计划名额 | 名额调整 | 剩余名额 | 事务与并发控制 |
| 志愿填报 | 考生、多个志愿 | 顺序保存 | 志愿记录 | 复合唯一键 |
| 投档执行 | 位次队列、志愿顺序、当前名额 | 逐个检索、扣减名额 | 录取记录 | 事务+行锁 |
| 结果查询 | 考生号 | 联表查询 | 录取状态 | 外键、关联索引 |
这张表建议每个复现项目的人都自己画一遍，因为它是答辩时最好的思路地图。多数课程设计只覆盖第一行和最后一行，也就是录入考生、查录取结果，中间两行才是这套资源的核心价值。投档执行这个模块会强制你思考“剩余名额怎么避免多人同时扣减”，答案指向事务隔离和锁机制，这正是数据库老师最喜欢追问的点。一旦你能把这个逻辑讲清楚，项目就不再是增删改查的堆砌，而是真的把数据库特性用到了业务里。
2.3 技术选型为什么不是巧合：Spring + Vue + MySQL 的答辩逻辑
这套技术栈看着平淡，但如果答辩时只说“因为大家都用”，分数不会高。能撑住场面的是把选型理由讲成闭环：业务数据必须满足 ACID，MySQL 事务就是直接的工具；后端需要能写业务逻辑又能开启事务的框架，Spring 的 @Transactional 把 Java 方法变成事务边界；前端要快速搭建交互页面，Vue 组件化写起来比 JSP 舒服得多。
换个方案对比就没这么顺了。如果后端用 Flask 配 SQLite，ACID 虽有，但 SQLite 并发控制弱，演示“多个考生同时竞争同一院校名额”的场景很没有底气。如果前端用 JSP 直接拼 HTML，代码耦合度高，改页面样式必须重启后端，演示现场容易翻车。Spring + Vue + MySQL 在课程设计里受欢迎，是因为每一层职责都很清晰：Vue 管页面，Spring 管接口和事务，MySQL 管存储。任何一层出了问题，都可以快速定位到具体文件，这对排错和讲清楚项目都至关重要。
当然这套栈也有槽点。依赖下载慢、首次前端构建要等几分钟、内存占用不低，这些缺点会在实际操作里变成具体的坑，第 5 章我会逐条说。但就课程设计这个评分场景而言，它权重最高的三件事——分层清晰、业务可演示、资料查找方便，全部占住了。这也是我不反对把这类资源推荐给本科生的原因，环境风险可以被充分降低。
3. 数据库设计与投档规则落库：核心表、位次排序与约束细节
3.1 核心表与字段设计：先画 ER 再写建表语句
数据库课程设计考核的是“看到业务能不能转成表结构”，这套资源的第一步就是把业务落成五张表。我概括成一句话：能用外键表达的关联，不要藏在业务代码里。sys_user 作为登录账号，与 student 考生表一一对应；student 通过 volunteer 志愿表关联到 school 院校；每次投档在 admission_result 结果表里生成一条记录。
-- 账号表：区分管理员与考生的系统入口 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录账号', password VARCHAR(100) NOT NULL COMMENT '加密后的密码', role VARCHAR(20) NOT NULL DEFAULT 'student' COMMENT '角色：admin/student', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户账号表'; -- 考生表：总分与位次是投档排序的两个核心字段 CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL COMMENT '关联 sys_user.id', student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '考生号', name VARCHAR(50) NOT NULL COMMENT '姓名', total_score INT NOT NULL COMMENT '高考总分', province_rank INT NOT NULL COMMENT '省内位次，越小越靠前', CONSTRAINT fk_student_user FOREIGN KEY (user_id) REFERENCES sys_user(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考生表';这套表结构里有几个字段值得解释。total_score 用 INT 而不用 DECIMAL，是因为高考总分本身就是整数，INT 排序性能最好；province_rank 是投档排序的锚点，必须加 NOT NULL，否则可能出现“位次为空却排在前面”的逻辑漏洞。student_no 上加 UNIQUE，保证考生号不会重复录入。user_id 外键关联 sys_user，登录账号和考生资料一一对应，这是注册流程的常规设计。
接下来是志愿表和录取结果表。志愿表里最核心的设计是复合唯一键 (student_id, seq_no)，保证同一个考生不会出现两个“第 1 志愿”。而录取结果表里 school_id 允许为空，这个设计对应业务正确性：考生滑档时没有投进任何院校，school_id 就是 NULL。
-- 院校表：剩余名额实时变化，是并发控制的核心对象 CREATE TABLE school ( id INT PRIMARY KEY AUTO_INCREMENT, school_code VARCHAR(20) NOT NULL UNIQUE COMMENT '院校代码', school_name VARCHAR(100) NOT NULL COMMENT '院校名称', total_quota INT NOT NULL DEFAULT 0 COMMENT '招生总名额', remain_quota INT NOT NULL DEFAULT 0 COMMENT '剩余名额，投档时递减' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='院校招生计划表'; -- 志愿表：seq_no 表示志愿顺序，从 1 开始 CREATE TABLE volunteer ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL COMMENT '考生ID', seq_no TINYINT NOT NULL COMMENT '志愿顺序，从1开始', school_id INT NOT NULL COMMENT '目标院校ID', UNIQUE KEY uk_student_seq (student_id, seq_no), CONSTRAINT fk_vol_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_vol_school FOREIGN KEY (school_id) REFERENCES school(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='志愿表'; -- 录取结果表：school_id 为 NULL 表示滑档 CREATE TABLE admission_result ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL COMMENT '考生ID', school_id INT NULL COMMENT '录取院校，滑档时为 NULL', result_status VARCHAR(20) NOT NULL COMMENT '已投档/滑档/退档', operate_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_result_student FOREIGN KEY (student_id) REFERENCES student(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='录取结果表';把 total_quota 和 remain_quota 分成两个字段，而不是只存一个“剩余人数”，是为了答辩时能直接回答“这个学校原本计划招多少人、还剩多少”。两字段一对比就能讲清总量与实时余量，同时“已录取人数 = total_quota - remain_quota”这个表达式用起来非常直观。类似的字段拆分思路可以用在任何有“总量与余量”概念的业务里。
3.2 位次排序与平行志愿投档：用事务和锁保住名额不超扣
建完表就该把业务规则落进代码。平行志愿按位次从高到低处理，数据库层面第一步是排序。常见做法是直接用 ORDER BY province_rank ASC 取出全部考生，然后在服务层按志愿顺序逐个检索。问题在于剩余名额是共享数据，如果没有加锁保护，两个并发操作同时读到 remain_quota = 1，各自扣减一次，名额就变成 -1，这就出现了超录。
在 Spring Boot 里用 @Transactional 把整个投档过程包住，同时对读取剩余名额的操作加悲观锁。
@Transactional(rollbackFor = Exception.class) public void processAdmission() { // 1. 按省内位次升序取得考生列表，位次小的优先处理 List<Student> students = studentMapper.selectAllOrderByRank(); for (Student student : students) { // 2. 当前考生志愿按 seq_no 升序读取 List<Volunteer> volunteers = volunteerMapper.selectSortedByStudent(student.getId()); boolean admitted = false; for (Volunteer v : volunteers) { // 3. 加行锁读取院校当前剩余名额，防止并发超扣 School school = schoolMapper.selectByIdForUpdate(v.getSchoolId()); if (school.getRemainQuota() > 0) { schoolMapper.decreaseRemainQuota(v.getSchoolId()); admissionResultMapper.insert(student.getId(), v.getSchoolId(), "已投档"); admitted = true; break; } } // 4. 所有志愿都没名额，记录滑档 if (!admitted) { admissionResultMapper.insert(student.getId(), null, "滑档"); } } }这段代码的顺序就是平行志愿的核心逻辑：先按位次，再按志愿顺序，循环里只做“查余量、够则扣、不够则下一个”。四个步骤不能乱。第三步里 selectByIdForUpdate 生成的是 SELECT * FROM school WHERE id = ? FOR UPDATE，事务提交前锁不会释放，另一个事务要更新同一行只能等待。rollbackFor = Exception.class 表示任何 RuntimeException 和检查异常都会触发回滚，避免“名额扣了但录取记录没写”这种脏数据。
如果不用悲观锁，用乐观锁版本号也可以，但课程设计现场演示时悲观锁的阻塞效果更好解释，代码也更短。实际面试里可以延伸一句：考生量极大的场景更适合用 Redis 分布式锁做预扣减，数据库锁只承担最终一致性。这一句能让听的人觉得你不只是会写循环，而是有基本的工程意识。
3.3 容易被老师抓住的细节：索引、外键与字段类型
这部分通常决定答辩分数的上限。索引方面，province_rank 排序字段必须加索引，否则考生量一上万，ORDER BY prov_rank 就会让查询时间明显变长；admission_result.student_id 需要索引，因为录取结果查询按考生号高频执行。外键方面，课程设计建议直接用物理外键，性能有一点代价，但能把参照完整性直接展示出来，这个场景下正确性远比极致性能重要。
字段类型里最容易出现的错是把 total_score 存成 VARCHAR。数值字段用字符串存储，排序会变成字典序，9 分会排在 10 分后面，投档排序直接乱套。另一个高频错是字符集，MySQL 的 utf8 最多存 3 字节，生僻汉字和 emoji 存不进去，建库建表统一用 utf8mb4，JDBC 连接串再加 characterEncoding=utf8，才能彻底避免乱码。这个坑我在别处被教育过不止一次，属于典型的血泪经验。
4. 完整复现路径：Maven 配置、SQL 导入与 Vue 构建
4.1 环境准备：先把 JDK、MySQL 与前端构建工具对齐
复现这套资源之前，先把环境清单列清楚，可以少走一半弯路。项目基于 Java 和 Spring，JDK 版本建议用 8 或 11，Spring Boot 2.x 在这两个版本上运行最稳；MySQL 用 5.7 或 8.0 均可，但注意 8.0 的认证插件和 JDBC 驱动版本需要匹配；前端如果只是使用现成 dist 产物，不需要安装 Node.js，只有重新构建前端才需要 Node 14 以上。
我的习惯是先输入三条命令确认环境，再继续下一步。
java -version mysql --version node -vnode -v 只在需要重新构建前端时才强制要求，如果直接用现成静态文件，这一条可以跳过。检查 Java 时注意看清版本号，如果显示的是 JRE 而不是 JDK，后续 Maven 编译大概率会失败报错。MySQL 确认能连上就够，账号密码稍后在 application.yml 里统一改。
环境检查完之后，把压缩包解压到一个不含中文和空格的路径下。Windows 下放在 C:\dev\project 这类路径，比放在“桌面\新建文件夹”更省事，因为 Maven 和 Node 工具链对路径里的中文支持曾经有过不少兼容性问题。这一步看似基础，实际踩坑率不低，很多人项目跑不通，问题就出在路径字符上而不是代码。
4.2 后端启动：mvnw.cmd、application.yml 参数怎么改
后端是基于 Maven 的 Spring 工程，入口就是 mvnw.cmd。首次执行时它会自动下载指定版本的 Maven，之后所有构建操作都走这个包装器，不需要全局安装 Maven。两个最常用的命令是编译打包和直接启动。
mvnw.cmd clean package mvnw.cmd spring-boot:run第一条命令会做一次完整构建并生成可执行 jar，生成物在 target 目录下；第二条是开发模式直接启动，编译通过后立即监听配置的端口。首次执行第一条命令时，依赖下载可能要花几分钟，这是正常的。如果卡在下载不动，通常是中央仓库连接不稳定，解决办法是打开项目里的 .mvn 或用户目录 settings.xml 配置国内镜像源。
启动前必须改数据库连接参数。打开 src/main/resources/application.yml，找到 spring.datasource 这一段。
spring: datasource: url: jdbc:mysql://localhost:3306/volunteer_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 jpa: hibernate: ddl-auto: update show-sql: trueurl 里的 volunteer_db 是数据库名，如果实际建的库名不同，要同步修改。useUnicode=true 和 characterEncoding=utf8 两个参数建议保留，否则中文数据写入后会变成乱码。serverTimezone=Asia/Shanghai 是 Java 8 以后的常见要求，很多启动报错都和时区参数缺失有关。如果项目用的是 MyBatis 而不是 JPA，把 jpa 相关配置换成 mybatis 配置即可，dataSource 部分不变。
启动成功的标志是控制台出现 Tomcat started on port 8080，此时后端已经就绪。如果启动就报错，先看控制台最上面的异常原因，大概率集中在三类：数据库连不上、端口被占用、依赖缺失。这三类的具体排错在第 5 章第 2 节展开。
4.3 前端资源处理：直接使用 dist 还是重新构建
前端处理的方案完全取决于压缩包里有没有 Vue 源码。如果只有 dist 产物，就直接用现成静态文件；如果有 src 目录和 package.json，建议重新构建一次，能保证前端和后端 API 路径完全匹配。
三种方式里最省事的是把 dist 目录整个复制到 Spring Boot 的静态资源目录，比如 src/main/resources/static 下面。Spring Boot 会自动把 static 下的 index.html 作为根页面，启动后直接访问 http://localhost:8080 就能看到登录页。这种方式适合后端语言和前端代码都想用一套服务拉起的场景。
第二种方式是开发环境下用 Vue CLI 自带代理。找到项目根目录的 vue.config.js，配置一个转发规则，让前端请求 /api 开头的接口都指到后端地址。
module.exports = { devServer: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };配置里 port 3000 是前端开发服务器端口，target 是后端实际地址。前端代码里所有接口请求都以 /api 开头，开发时访问 3000 端口，请求会自动转发到 8080，从而避开跨域。changeOrigin 设为 true 是为了让后端收到的请求头 Host 变成 target 地址，很多后端框架对 Origin 校验严格，不设置会报 403。
第三种方式是将 dist 产物放到 Nginx 或者任意静态服务器，同时在后端配置 CORS 允许跨域访问。这种方式更接近生产环境，但课程设计演示时不太需要，反而会增加环境复杂度。我一般只在准备扩展项目、讲部署方案时才用。
重建前端时有一个时序问题需要注意：先在 src/main/resources/static 里放过旧 dist 的话，重新 npm run build 之前要清空 static 目录，否则旧的 hash 文件和新 index.html 混杂，白屏问题就会冒出来。
5. 常见问题排查与避坑：五个把大作业拖进深渊的细节
5.1 Maven、环境变量与依赖下载的坑
问题一：mvnw.cmd 执行后窗口闪退，或者提示“不是内部或外部命令”
现象：双击 mvnw.cmd 或者命令行执行时，窗口一闪而过，完全看不到任何输出。
原因：最常见两种情况，一是 JAVA_HOME 环境变量没有设置，二是 PATH 里没有加 Java 的 bin 目录。mvnw.cmd 靠 JAVA_HOME 找到 Java 可执行文件，找不到就直接退出。
解决：先确认 java -version 能正常输出，然后在系统环境变量里新建 JAVA_HOME 指向 JDK 安装目录，再把 %JAVA_HOME%\bin 追加到 PATH 中，重新打开命令行窗口再跑命令。
问题二：依赖下载卡住不动，或者构建到一半超时报错
现象：mvnw.cmd clean package 执行后，长时间停留在 Downloading 状态，最后报错提示无法访问 Maven Central。
原因：默认中央仓库对国内网络环境不友好，连接不稳定导致下载失败。
解决：在用户目录的 .m2 文件夹里新建 settings.xml，配置阿里云镜像仓库。配置后重启构建，下载速度会有明显提升，这是最常用也最稳的做法。
5.2 数据库连接、导入与字符集的坑
问题三：source 导入 SQL 报错 1366，或者导入成功但中文全是问号
现象：执行 mysql 导入数据库脚本时，控制台提示 Incorrect string value 错误，或者页面查出来中文数据全是 ??。
原因：SQL 文件本身的编码和数据库字符集不一致。文件是 UTF-8，但库或表创建时用了 latin1，中文就存不进去。
解决：建库时指定字符集，SQL 脚本导入前先执行一条设置命令保证会话字符集一致，再执行 source 导入。如果已经建错，可以用 alter database 和 alter table 修改字符集后重新导入。
CREATE DATABASE IF NOT EXISTS volunteer_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; SET NAMES utf8mb4; SOURCE /path/to/init.sql;问题四：后端启动报错 Access denied for user，或者找不到数据库
现象：Spring Boot 启动时控制台报 Access denied，提示用户权限问题，或者报 Unknown database。
原因：application.yml 里的用户名密码与本地 MySQL 不一致，或者指定的数据库还没有创建。如果项目用了初始化脚本，但没有先创建同名库，连接时自然找不到库。
解决：先确认 MySQL 服务已启动，然后用命令行连一次库，确认账号密码有效。检查 application.yml 里的 url 中数据库名与实际库名一致，密码部分改成自己本地的密码。避免使用 Spring 的 ddl-auto 自动建表来自动补数据表，它只建表不导初始化数据，会把系统初始账号漏掉。
5.3 前后端联调、跨域与静态资源白屏的坑
问题五：页面白屏，控制台报 chunk 加载失败或 404
现象：访问首页只看到白屏，打开浏览器开发者工具，Console 里出现 Failed to load chunk 或某个 js/css 文件 404。
原因：index.html 引用的 hash 文件名与静态资源目录里实际文件不一致。常见场景是第一次构建后又在 static 里复制了旧文件，或者后端缓存了旧的 index.html。还有一种可能：把 dist 目录整个复制时漏掉了部分资源文件。
解决：清空静态资源目录，重新构建前端，确认 index.html 引用的文件名和 assets 目录下实际文件一一对应。如果使用开发服务器，先强制刷新浏览器缓存，或在 Vue CLI 构建时开启文件名 hash。这个坑在课程设计里出现频率极高，代码本身没问题，纯粹是构建产物不同步。
问题六：前端请求接口报 404 或 401，登录页完全无法进入
现象：页面正常打开了，但输入账号密码点登录，请求一直失败。控制台能看到请求发出去地址不对，或者返回 404。
原因：前端把 API 地址写死成后端 http://localhost:8080，而后端实际端口不同，或者前端与后端之间没有跨域处理，请求被拦截。
解决：统一用相对路径 /api 开头组织后端接口，开发环境用 vue.config.js 代理转发，生产环境让后端把 dist 放进 static 目录，避免直接使用跨域请求。登录失败还要顺带确认 sys_user 表里有没有初始账号，很多项目导入 SQL 后数据表为空，没有初始账号导致登录一直提示密码错误。
6. 把课程设计讲成自己的：演示数据构造与答辩追问应答
6.1 构造一组让评委一眼看懂的演示数据
复现项目只是第一步，答辩时能不能把投档逻辑讲清楚才是评分关键。我的建议是准备 6 个考生、3 所院校的测试数据。位次按 1 到 6 排好，前三名分数明显高，后三名贴着招生计划线分布。院校 A 只招 2 人，院校 B 招 2 人，院校 C 招 2 人。第 1 名只填了 A，第 2 名填 A 和 B，第 3 名填 B 和 C，第 4 名填 C，第 5 和第 6 名把三所院校都填上。
投档结果应该是：第 1、2 名进 A，第 3 名进 B，第 4 名进 C，第 5 名和第 6 名因为 C 也满员而滑档。这样一组数据把“分数优先、遵循志愿、一轮投档”三句话全部演示出来，评委一眼就能看懂系统的行为逻辑。演示时先展示考生列表的位次排序，再执行投档，最后展示录取结果，中间每一步都有数据支撑。
6.2 追问应答：并发、事务与扩展性的话术
答辩时最常被追问的是三个问题。第一个是“多个考生同时竞争最后一个名额怎么办”，回答要点是事务加锁，用 FOR UPDATE 锁住名额所在行，加上 @Transactional 保证回滚。第二个是“为什么不用乐观锁”，回答可以是课程设计场景并发量不大，悲观锁行为更直观，真正高并发才会考虑乐观锁或分布式锁。第三个是“如果系统要扩展到真实招生场景，哪里需要改”，回答方向是数据库读写分离、Redis 缓存名额预扣减、消息队列处理投档任务。
这类问题没有标准答案，但要把逻辑说圆。核心是不能只讲“我写了什么”，而是讲“我为什么这样写、不这样写会出什么问题”。把事务边界、锁的粒度、索引设计三条线讲透，项目在评委那里的印象会明显不同于普通管理系统。
顺带提一个复盘习惯：从那以后我拿到任何一份课程设计资源，都会强制自己先把完整跑通再做二次开发，跑通前不看任何美化过的说明文档。这个习惯帮我在多次项目里避开了“代码看起来没问题但一运行就翻车”的尴尬。数据库课程设计的价值不在页面多精美，而在你能不能把表和业务逻辑讲成一个自洽的故事，希望这篇拆解能帮到你。
本文还有配套的精品资源，点击获取
