基于SpringBoot的高考志愿辅助填报系统设计与实现

1. 为什么选择"高考志愿辅助填报系统"作为毕设题目

我见过太多计算机专业的毕设选题翻车案例，要么选一个毫无业务逻辑的"管理系统"凑字数，要么选一个超出本科能力范围的人工智能大项目最后只能演示Demo。这个"基于SpringBoot的高考志愿辅助填报系统"其实是个相当聪明的选择——它有真实存在的业务痛点，有足够复杂的数据关联逻辑，又恰好落在JavaWeb技术栈的核心射程之内。

先说业务痛点。高考生和家长在志愿填报阶段的核心焦虑是：我的分数能上什么学校？这个分数段报哪些院校不会滑档？哪个学校的计算机专业比同档次的另一个学校更强？这里面涉及分数位次转换、院校历年的录取数据、专业录取分数线、招生计划变化等一系列信息。传统做法是翻两本大厚书，对着Excel表手工比对，效率低且容易漏掉合适的选择。一个能够根据考生分数自动匹配"冲稳保"三档院校、并给出推荐顺序的系统，是真实的用户需求。

从技术难度角度看，这个题目处于一个很舒服的梯度：SpringBoot做后端接口层，MySQL存结构化数据，MyBatis-Plus或JPA做持久层，前端可以用Thymeleaf服务端渲染也可以用Vue做前后端分离，核心的"智能匹配"功能实际上不需要深度学习，而是基于规则和加权评分的推荐算法。这个难度既不会让答辩评委觉得你在糊弄，也不会把自己逼到无法按期交付的墙角。

再说就业相关性。Java生态依然是国内企业级应用的主力，招聘市场上SpringBoot相关岗位数量一直很稳定。把这个项目做完，你对SpringBoot的自动配置原理、启动流程、事务管理、参数校验这些核心机制的掌握程度，会远超那些只跑过课设的学生。面试时聊"你做过什么项目"，这个系统可以展开的点非常多：数据建模、推荐算法、并发处理、Excel导入导出、权限控制……都是面试官愿意听的东西。

抛开功利因素，这个题目的数据可用性也很好。阳光高考平台、各省教育考试院公布的历年录取数据是公开的，你可以整理成结构化数据导入系统（注意不要直接商用即可）。这意味着你不需要像某些毕设项目那样造一堆假数据，项目的实际运行效果是真实可信的。

2. 业务拆解与系统功能边界划定

这是整个项目最重要的一步——搞不清楚系统里有哪些角色、哪些数据、哪些流程，后面代码写起来会越写越乱。我在规划这个系统时，先画了一遍完整的用户旅程：考生登录系统，输入高考分数和省份、科类，系统展示推荐的院校列表，考生可以按冲稳保标签筛选，查看院校的历年录取专业分数线，把心仪的院校加入志愿表，最终生成一份志愿填报草表。管理员后台负责维护院校信息、专业信息、历年分数线数据，还可以管理公告。

2.1 角色权限设计：考生端与管理员端的最小闭环

系统的角色设计不必复杂，两个角色就够了：

• 考生（普通用户）：注册、登录、完善个人成绩信息、获取院校推荐、浏览院校详情、管理志愿表。
• 管理员：登录后台、维护基础数据（院校、专业、批次、录取分数线）、管理公告、管理用户。

权限控制用Spring Security + JWT来实现。为什么用JWT而不是Session？因为这种系统前端大概率是独立部署的页面（Vue或者简单的Ajax页面），JWT无状态、跨域方便、移动端也能直接复用接口。考生登录后每次请求携带Token，后端通过拦截器校验。

角色权限的细节值得注意：考生只能查看和操作自己的数据，管理员只能操作数据管理模块。这个在Service层要做数据归属校验，不能只靠前端隐藏按钮。实际开发中我见过不少人有权限漏洞，主要是接口层没做数据过滤，属于一类经典扣分点。

2.2 核心功能模块清单与优先级排序

我建议按这个优先级来排开发计划，P0先做完，P1中的"录取概率预测"强烈建议做上，因为它直接增强推荐的解释性——算法不能只告诉用户"推荐这个学校"，还要说明为什么推荐。P2的可视化如果有余力就做，能显著提升答辩时的演示效果。

2.3 数据库表结构设计的关键决策

这个系统的数据模型比一般管理系统复杂，核心表我建议这样规划（用MySQL 8.x）：

• t_user：用户表，字段包括id、username、password、province、subject_type、score、rank（位次）、create_time。
• t_university：院校表，字段包括id、name、code、city、province、level（985/211/双一流/普通本科）、type（综合/理工/师范等）、tags、introduction。
• t_major：专业表，字段包括id、university_id、name、category、tuition、duration、description。
• t_enrollment_plan：招生计划表，字段包括id、university_id、major_id、province（面向省份）、year、plan_count、min_score、min_rank、avg_score。这张表是推荐算法的核心数据来源，按省份和年份拆分。
• t_volunteer：志愿表，字段包括id、user_id、university_id、major_id、priority（第几志愿）、status、create_time。

这里有一个关键设计决策：分数线和招生计划合并成一张t_enrollment_plan表，没有单独拆分数线表。理由是每次招生计划都携带当年的最低录取分数和最低录取位次，本质上是一份"招生录取结果概览"，拆成两张表反而会增加查询的JOIN次数。跨省招生的数据（同一院校在不同省份分数线不同）通过province字段区分，这是合理的。

位次字段（min_rank）一定要存，而且比分数更重要。因为每年试卷难度不同，直接拿今年分数对比去年分数会失真；位次是全省排名，跨年份可比性比绝对分数强得多。后面推荐算法里，主要就是拿用户的位次和往年各院校的录取位次做比对。这个设计点讲清楚，答辩时能体现出你不是随便造的表。

2.4 数据从哪来：公开数据的采集与整理方案

数据是整个系统的血液。没有真实的院校和分数线数据，功能做得再花哨都是空的。我的做法是分三步：

1. 从阳光高考平台抓取院校名单（学校代码、名称、所在地、办学层次、院校类型），这一层数据量不大，约3000多所，用Java爬虫或者直接手工整理都可以。
2. 从各省教育考试院公布的《普通高校招生录取统计资料》提取本科一批/二批次的录取分数和位次。注意这里各省的政策不同，需要按照目标省份提取。比如系统面向河南考生，就提取河南省的录取数据；如果做全国版，就按省份分批录入。
3. 整理专业录取分数线，这个颗粒度更细，如果精力有限，可以先只做部分热门专业的分数数据，其余用院校最低线代替。

提示：爬取公开数据时注意robots协议和数据使用规范。毕设演示用没问题，但如果要公开发布，建议只保留项目演示用的脱敏数据。

数据整理阶段建议直接用脚本批量处理后生成SQL文件导入MySQL，不要在系统里手工录数据（管理员后台的CRUD功能是给"数据维护"场景用的，不是给初始数据录入用的）。我当时是写了一个Python脚本把Excel表格转成INSERT语句，几千条数据一次性导入，效率高得多。

3. 智能匹配推荐算法的设计思路与实现细节

这个系统的灵魂就是"智能匹配"推荐。很多学生的做法是简单的分数区间筛选——查所有最低分小于自己分数的院校，随便排个序就完事。这样做当然也能跑，但答辩时基本一问就露馅，因为完全没有算法设计逻辑。

我的思路是设计一个基于位次差和院校级别的多因子加权评分模型，整体分为三步：筛选候选集、计算匹配评分、划分冲稳保梯度和排序推荐。

3.1 候选集筛选规则：先缩范围，再精细化

推荐的第一步不是算分，而是把院校范围缩小。范围太大，计算量倒不是问题，问题是结果太杂，冲稳保的梯度会失真。我的筛选规则如下：

• 只看目标省份、目标科类的数据。t_enrollment_plan表里按province和科类过滤。
• 只看近3年的数据（年份近3年取最大年份往前推），不追溯太远，因为高考政策变化大，5年前的数据参考价值不大。
• 只看院校招生批次符合用户输入或默认本科批的数据。
• 最低录取位次在用户位次的0.7倍到1.5倍范围之内的院校才进入候选集合。为什么是这个区间？位次小于用户0.7倍的院校，基本是"绝对稳"或"亏分"的学校；位次大于用户1.5倍的院校，是高度冲刺的学校，冲上的概率很低，可以留给用户在工作台里自己加，不必都放进推荐列表。0.7~1.5这个区间是经验值，你也可以根据实际数据分布调整。

这一步用SQL即可完成筛选，不要把所有院校加载到内存再过滤，数据量上千条的时候虽然影响不大，但是培养良好的查询习惯对后续开发很重要。

3.2 匹配评分的多维加权公式

候选集合里每个院校要计算一个匹配分，这个分数代表"这所学校与考生匹配程度"的量化值。我的公式如下，供参考：

code复制score = w1 * rank_fit + w2 * level_bonus + w3 * stable_trend + w4 * major_fit

四个分量的含义和计算方法：

• rank_fit（位次匹配度）：反映考生当前位次与院校往年录取位次的接近程度。计算方式：如果考生位次小于等于某院校近三年录取位次的平均值，说明录取概率较高，得分高。具体可以用 rank_fit = max(0, 1 - (user_rank / avg_min_rank - 0.85)) 这样处理，核心思想是位次越有优势得分越高。
• level_bonus（院校层次加分）：985院校加10分，211加8分，双一流加6分，普通本科加4分。这个分量是保证推荐结果"向上覆盖"——如果完全不考虑院校层次，推荐结果会被同级别的普通学校填满，用户看不到更高层次学校冲刺的可能性。
• stable_trend（录取稳定性系数）：对比院校近三年位次数据的方差。方差越小说明录取位次越稳定，可预测性高，推荐价值更大。用 stable_trend = 10 - variance * coefficient（具体系数根据数据分布调）。
• major_fit（专业契合分）：如果用户输入了感兴趣的报考方向（如计算机、临床医学），推荐有相关专业且该专业录取分明显高于院校整体线（说明是学校王牌专业）的院校时加分。

权重建议：w1 = 0.5，w2 = 0.2，w3 = 0.15，w4 = 0.15。这是我在实际测试中调试出来的组合：位次匹配度是主要决定因素，层次加分不能太高否则会误导冲刺，稳定性作为辅助维度，专业契合则按用户是否有明确专业意向来动态调整。注意，这些权重不是一次性定死的，我建议做成系统参数表，管理员可以在后台调整——这个设计本身又是一个答辩加分项，说明你做的是可配置的推荐引擎，不是写死的。

3.3 冲稳保梯度划分与志愿排序策略

计算出匹配分之后，需要对结果做冲稳保三档划分。我的划分锚点是位次比值（用户位次 / 院校平均录取位次）：

• 冲（冒险）：位次比值 < 0.9，即院校录取位次比考生位次更靠前（更苛刻），考生需要冲刺才能进。例如考生位次30000，院校平均录取位次27000（前27%分数段），这类属于冲。
• 稳（适中）：位次比值在0.9 ~ 1.1之间，考生位次和院校录取位次接近，录取概率较大。这是推荐的主体。
• 保（保底）：位次比值 > 1.1，考生位次明显比院校录取位次靠后（更优越），基本确定能录取，用来兜底。

推荐列表按"冲3、稳4、保3"比例输出，这个比例参考了志愿填报的常见策略——冲刺段不填满，太浪费志愿机会；保底段必须有足够保障。比例做成常量配置，也放在参数配置表里。

至于志愿表内的排序策略，我在生成草表时默认按冲稳保梯度排列：冲的院校在前，稳居中，保靠后。这符合真实志愿填报的填报原则——把最想冲且有可能冲上的学校填在前面，保底学校放最后。用户可以手动拖动调整顺序的交互此时也有必要做，属于业务逻辑的自然延伸。

3.4 为什么选加权评分而不是机器学习模型

聊算法的时候一定会有人问：为什么不直接上机器学习模型？我自己的判断是：在这个场景下，加权评分规则方案要优于机器学习方案，理由有三个：

1. 数据量不足以支撑训练。一个省3年的录取数据，有效样本大概几千到万级，特征维度也不多（位次、层次、年份、专业热度），这个量级训练出来的模型很容易过拟合，泛化能力反而不如规则明确、可解释性强的评分方案。
2. 可解释性要求高。高考志愿填报是高风险决策场景，用户需要知道"为什么推荐这个学校"。加权评分可以把每一项分值的贡献拆给用户看："您的位次与该校近三年平均录取位次匹配度得分82"，这种透明性不是黑盒模型能给的。
3. 规则方案便于调整。不同省份的高考政策和录取规则差异大，加权方案可以通过调整权重、修改筛选阈值来适配不同地区的场景，机器学习方案则需要重新训练。

这不代表机器学习在该领域没有应用空间——在志愿咨询机构的大规模推荐系统中，图神经网络、协同过滤都有研究应用。但作为毕设项目，能讲清楚"为什么用简单方案"比"堆一个说不清原理的黑盒模型"更有说服力。

3.5 核心代码结构示例

整体按SpringBoot经典分层结构走。Controller层负责参数接收和返回；Service层实现推荐算法核心逻辑；Mapper层用MyBatis-Plus简化CRUD操作。

核心推荐服务接口的代码骨架如下：

java复制public interface RecommendationService {
    /**
     * 根据考生信息生成院校推荐列表
     * @param rank 考生位次
     * @param province 省份
     * @param subjectType 科类
     * @param majorKeyword 专业偏好（可为空）
     * @return 推荐结果，按冲稳保分组
     */
    RecommendResult recommend(Integer rank, String province, String subjectType, String majorKeyword);
}

实现类中的三个核心步骤是：调用Mapper查询候选集、遍历候选集计算各项评分、按总分排序并做梯度分组。候选集的SQL大致长这样：

sql复制SELECT e.university_id, 
       AVG(e.min_rank) AS avg_rank,
       STDDEV(e.min_rank) AS rank_std,
       MAX(e.year) AS latest_year
FROM t_enrollment_plan e
WHERE e.province = #{province}
  AND e.year >= #{startYear}
GROUP BY e.university_id
HAVING AVG(e.min_rank) >= #{minRank} 
   AND AVG(e.min_rank) <= #{maxRank}

这段SQL返回的是每个院校近三年录取位次的均值、标准差和最新年份，推荐算法的主数据源。这里用HAVING做AVG条件过滤是合理的，因为AVG的结果需要在GROUP BY之后才能判断。注意标准差STDDEV在MySQL中是聚合函数，可以直接用。

4. SpringBoot项目落地的工程化细节

选型层面我建议：SpringBoot 2.7.x + MyBatis-Plus + MySQL 8.0 + Spring Security + JWT，前端可以用Vue 3 + Element Plus或者最简单的Bootstrap + Thymeleaf页面。考虑到毕设的交付时间，如果前端基础薄弱，直接用Thymeleaf模板做服务端渲染最稳妥，少一套跨域和前后端联调的麻烦；如果前端基础不错，做前后端分离能让项目的技术栈更完整，演示效果也更好。

4.1 项目初始化与基础配置的几个关键动作

创建一个SpringBoot项目很容易，但有几个配置细节会直接影响开发效率：

• application.yml里配置数据源时，加上serverTimezone=Asia/Shanghai，否则MySQL连接会有时区报错。
• MyBatis-Plus的逻辑删除配置建议加上：global-config.db-config.logic-delete-field: deleted，表里留一个deleted字段做软删除。院校数据被误删后还能找回，演示的时候也更安全。
• 统一响应体的设计。不要Controller里到处返回Map或直接把实体类返回给前端，而是定义一个Result<T>泛型类（code, message, data三个字段），所有接口统一返回这个结构。这样前端处理异常的逻辑只有一套，也方便后置拦截器统一处理。
• 参数校验必须用@Validated注解配合@NotNull、@Min这些校验注解，不要手写if判断参数是否为空。这既显得专业，又能避免大量样板代码。

启动类没什么特别的，标准写法。如果你用了Spring Security，记得配置@EnableGlobalMethodSecurity(prePostEnabled = true)，这样可以在方法上用@PreAuthorize("hasRole('ADMIN')")做细粒度的权限控制，比在拦截器里写URL匹配要灵活得多。

4.2 推荐算法模块的接口设计与前端交互

推荐接口设计成POST请求比较合适，因为传递的参数是一批筛选条件，可能有专业关键词等多字段。接口定义如下：

java复制@PostMapping("/api/recommend")
public Result<RecommendResult> recommend(@RequestBody @Valid RecommendRequest request) {
    // request: province, subjectType, score, rank, majorKeyword
    return Result.success(recommendationService.recommend(...));
}

前端页面展示推荐结果时，建议按"冲、稳、保"三个Tab页展示，每个Tab下面是一张院校卡片列表。卡片上展示院校名称、所在城市、院校层次、录取概率标签、近三年录取位次趋势。点进详情页再展示同层次的更多分析数据。

这个交互设计很关键：用户不是只要一个列表，而是要"可控的信息密度"。列表页做概要展示，详情页做深度数据展示，这一层交互逻辑做出来，系统整体质感就完全不一样了。

4.3 批量导入功能的实现与数据校验

管理后台的Excel批量导入功能，用EasyExcel（阿里开源）来实现。相比Apache POI原生写法，EasyExcel的API简洁很多，而且支持大文件流式读取，不会撑爆内存。示例代码骨架如下：

java复制@PostMapping("/admin/enrollment/import")
public Result<Void> importEnrollment(MultipartFile file) throws IOException {
    List<EnrollmentPlan> list = EasyExcel.read(file.getInputStream())
        .head(EnrollmentPlanExcelModel.class)
        .sheet()
        .doReadSync();
    for (EnrollmentPlan plan : list) {
        // 逐条校验合法性（院校是否存在、年份是否合法、分数位次是否为正）
        // 校验通过的插入或更新，更新逻辑用院校+专业+省份+年份作为唯一键
    }
    return Result.success();
}

数据导入这里有个坑：重复导入同一份文件会导致数据库中产生重复记录。我的做法是导入之前先按"院校ID + 专业ID + 省份 + 年份"做一次去重检查，存在则执行更新，不存在则新增。这种upsert逻辑在数据维护场景下非常实用。

4.4 安全与性能的工程实践补充

考生成绩属于个人敏感信息，在表设计上不直接存储明文登录密码，用BCrypt加密。Spring Security自带BCryptPasswordEncoder，直接用即可，不要自己写MD5加盐之类的逻辑，BCrypt已经是行业标准。

查询性能方面，t_enrollment_plan表建议建联合索引：(province, year, min_rank)。经过实测，这个索引对候选集筛选SQL的加速非常明显，千万级数据量下也能保持毫秒级响应。另外给t_university表的name字段加一个普通索引，因为管理后台要做模糊搜索。

5. 开发过程中最容易踩的坑与处理方案

开发一个完整系统的过程中，踩坑是必然的。这一章记录几个我实际遇到的、比较有代表性的问题，每一个都是可以复现和排查的完整链路。

5.1 Spring Security放行配置导致推荐接口401

这是权限配置最常见的问题。现象是：前端调用/api/recommend接口时返回401未授权，而登录接口/api/auth/login正常。

排查链路如下：先看SecurityConfig中的permitAll配置是否正确。我最初只把/api/auth/**和/api/register放行了，但推荐接口/api/recommend没有加入白名单。由于推荐功能需要登录后才能使用（用户提交成绩后系统才能推荐），这个接口本身必须要求登录，所以不应该放行。问题通常不是"没放行"，而是JWT过滤器里解析Token失败。继续排查Token解析逻辑，发现我在JWT工具类里把用户ID和用户名的顺序搞反了，导致从Token中解析出的用户名和数据库中的用户名对不上，认证失败。

最终处理：修正JWT工具类的Claims写入顺序，同时在SecurityConfig中显式声明"哪些接口匿名可访问，哪些接口必须认证"。建议用@PreAuthorize做方法级权限校验，而非全局URL匹配，这样可读性更好。

5.2 MyBatis-Plus分页插件导致的内存溢出

引入MyBatis-Plus后，很多教程会直接推荐配置分页插件PaginationInnerInterceptor。但有的版本中，如果PaginationInnerInterceptor没有被正确注册为Bean，或者使用了过时的PaginationInterceptor（旧版本类名），分页查询会退化为全表查询，将所有数据加载到内存后手动分页。本地数据量小时感觉不出来，上了几万条数据后直接OOM。

排查方法是开启MyBatis的SQL日志，打印出实际执行SQL。如果分页SQL里没有LIMIT关键字，说明分页插件没有生效。处理方案很简单：用@Configuration类注册官方新版的分页插件Bean，注意检查依赖版本与插件版本的兼容性（新版MyBatis-Plus 3.5.x的插件是MybatisPlusInterceptor）。

5.3 同院校同专业跨省分数线数据导致的平均分计算错误

这是数据库设计时就埋下的坑。某所大学，河南省的录取分数线和河北省的录取位次完全不同，如果SQL里只按university_id分组做平均位次，会把不同省份的数据混在一起，算出来的平均位次没有意义。

排查链路：先发现某所省外院校的推荐结果异常——明明是位次差距很大的学校，推荐列表里却出现了"稳"标签。深入核查时发现该院校推荐使用的平均位次是所有省份的混合值。原因就是候选集筛选SQL里漏了e.province = #{province}条件，导致数据范围扩大。

处理：把所有的t_enrollment_plan聚合查询都严格加上省份和科类维度条件，不能省。同时增加一条审核规则：接入一个新的省份的数据时，先在管理后台用SQL验证该省数据量是否符合预期，防止"数据整体范围正确但某个院校数据混入"的问题。

5.4 前端Vue项目跨域Session丢失问题

前后端分离架构下，登录接口Set-Cookie的SessionID在前端后续请求中没有携带，导致登录状态丢失。这个问题实际上是我们决定弃用Session方案、改用JWT的直接导火索。如果你的系统是前后端分离的，建议直接用Token方案；如果坚持用Session，必须配置跨域时携带SessionID的withCredentials属性，并且前端也要做响应的CORS配置。

但是有个更省心的方案：如果你的前端就是Thymeleaf服务端渲染，直接在同源下用Session就完全没问题，不需要处理跨域。这也是我之前建议前端基础弱的同学直接用Thymeleaf的原因。

5.5 数据可视化中用错图表类型引发的误导

我在给录取趋势页做图表时，一开始用了折线图表现"某院校近三年录取位次"，但位次的定义是数值越小代表排名越靠前。折线图默认习惯是数值越高越好，用户看到一条上升的折线会误以为"录取排名在上升"，实际反而是位次在下降、学校在变难考。这就是用错图表语义。

处理方式是在图表纵坐标上做位次反转（即位次值小的在上方），并且给图表增加明确的文字说明。这个细节虽然小，但体现的是工程师对业务语义的理解，答辩时拿出来单独讲，能够展示你的项目不是简单地调用图表组件，而是有业务思考的。

6. 项目从"能跑"到"出彩"的进阶优化方向

如果你的毕设时间比预期充裕，或者想冲刺更高级别的毕业设计评优，以下几个方向可以作为延伸。

6.1 推荐解释模块：让算法"开口说话"

在推荐结果页上，每一个推荐卡片增加"为什么推荐"的折叠区域。前端展示后端返回的结构化解释信息，比如："您位次30000，该校近三年平均录取位次26000，属于冲刺梯段；近三年录取位次方差较小，分数线稳定；该校计算机专业为国家一流本科专业建设点，建议冲刺。"

这个功能的实现思路是：候选集筛选中存下各项评分指标的原始值，匹配评分计算出结果时同步生成文本解释。不需要额外的算法投入，只需要把评分过程中间数保存下来，再写一段模板拼接逻辑即可。这个功能做实了，答辩评分会高一个档次。

6.2 基于雷达图的多维度院校对比

志愿表里添加了多个院校之后，做一个"对比模式"：用雷达图展示几所备选院校在"录取难度、学术水平、城市发展、就业前景、学费性价比"五个维度的得分。这五个维度里的前两个来自系统数据，后三个需要你在院校基础表里补充评分字段。

雷达图可以用ECharts的雷达图组件实现，后端只需要提供各院校各维度的评分数值，前端直接拉取。用户在最终决定顺序时，这个对比图可以直观地辅助决策。注意评分数据来源于人工标注，需要说明这是"综合评估值，仅供参考"。

6.3 数据分析模块：从数据中挖掘趋势

在管理后台增加一个"录取趋势分析"页面，统计本省近三年各大类院校的录取位次变化趋势、热门专业的分数变化曲线，生成可视化图表。功能本身不复杂，但对理解数据分析流程很有帮助。比如可以按院校层次分组显示平均录取位次的变化，探析"双一流院校位次逐年上升、普通本科院校位次波动大"等趋势，这些结论在报告里写出来非常加分。

6.4 Docker化部署与持续集成

交付一个可以一键启动的Docker-Compose镜像编排：MySQL容器 + 后端SpringBoot容器 + 前端Nginx容器。docker compose up -d 就能把整套环境拉起来。这个能力对毕业设计和面试都很有用——面试官问"你这个项目怎么部署的"，你直接说"Docker Compose一条命令起全套，我带你演示"。

SpringBoot应用打镜像时，Dockerfile里建议用多阶段构建：第一阶段用Maven打包，第二阶段把jar包拷贝进JRE基础镜像，这样镜像体积能控制在200MB以内。如果你的JDK是1.8，用eclipse-temurin:8-jre作为基础镜像，注意不要用早已过时的java:8镜像。

关于SpringBoot打包还有一个经典问题：版本太高导致Java编译和目标版本不匹配的报错。我在项目里用的是SpringBoot 2.7.x，要求JDK 8即可，但是在用JDK 17编译的时候遇到过"源发行版17需要目标发行版17"的警告。处理方式是在pom.xml里显式指定<java.version>1.8</java.version>，同时Maven编译插件的source和target都设置为1.8。

6.5 并发场景与压力测试

虽然作为毕设可能不需要应对高并发，但我建议至少加一层Redis缓存。推荐接口的入参是省份、科类、位次这样的组合值，但同一组合下的推荐结果短期内有很强的重复性。用Redis将推荐结果缓存起来（key值用参数的MD5，过期时间24小时），实测能把接口响应时间从300ms降到50ms以内。

更进一步，可以做个简单的JMeter压测，验证一下系统在100并发下的稳定性。压测报告截图放到毕业论文的"性能测试"章节，又是一个别人没有的亮点。

7. 论文结构与答辩准备的实战经验

最后一个部分是写作答辩层面的经验分享。这个系统做完了，论文和答辩的准备工作同样重要。

论文结构建议按这个顺序展开：

1. 绪论：背景、意义、国内外研究现状（重点写高考志愿填报咨询服务的现状和痛点）。
2. 需求分析：从用户角色出发写功能性需求和非功能性需求，把用例图画出来，这是论文的标配内容。
3. 系统设计：架构图、功能模块图、数据库E-R图、核心类图、时序图。重点讲解智能匹配算法的设计思路，把评分公式和冲稳保划分规则写清楚。
4. 系统实现：各模块的实现细节，代码片段、接口文档、界面截图。注意代码片段不要贴太长，选核心方法展示即可。
5. 系统测试：功能测试用例表、性能测试结果、兼容性测试（不同浏览器打开页面）等。

答辩时的演示顺序建议这样设计：先演示数据可视化分析页面（最先抓住眼球），再演示考生端完整的操作流程——注册登录、录入成绩、查看推荐、对比院校、生成志愿表，最后切到管理员后台演示导入数据和维护功能。演示总时长控制在8~10分钟，不要拖拉。

答辩中最容易被追问的几个问题，提前准备好答案：

• "推荐算法的权重是怎么得来的？"——回答：先通过历史数据回测确定初始参数，再结合专家经验调整，系统参数表支持后续优化。
• "如果省份高考政策变化，推荐结果还准确吗？"——回答：算法基于位次而非绝对分数，降低了试卷难度差异的影响；对于政策变化，设计上允许管理员调整权重和筛选阈值，并建议在新高考模式下按选科组合重新校准。
• "数据库为什么这样建表？"——回答：贴合查询场景，分数线与招生计划合并存储避免多表关联，索引设计满足核心筛选SQL的查询路径。

回忆一下我见过最差的答辩状态：代码真的写出来了，功能也是完整的，但讲到"智能匹配"的时候，直接说"这个算法网上找的"，没有任何自己的思考过程。这种状态几乎一定会被追问，最后只拿了一个中等分。反过来，哪怕算法像上面这样简单，只要你能讲清楚设计动机、公式来源、权重调优过程和局限性，就能展现出独立解决问题的工程能力，这恰恰是毕设考核的核心目标。

所以，请记住：项目完成只是你毕业设计工作的一半，另一半是把你的设计思路、踩坑经历、技术选型决策逻辑，完整地、有条理地讲出来。这个系统的技术含量不一定要多高深，但"为什么这样做"的思考过程一定要扎实。写完代码之后，花一个下午整理你的设计决策记录，到答辩时就不会无话可说了。