1. 项目剖析：为什么是“双后端”架构

做高考志愿推荐系统，第一眼看到“python+springboot+django/flask”这个组合时，很多人会愣一下：既然有了Python，为什么还要扯上SpringBoot？这其实是这套项目最值得琢磨的地方，也是大多数同类开题报告里没讲透的点。

先把这个架构的底层逻辑捋清楚。高考志愿推荐系统的本质，是一个典型的“数据密集型+业务密集型”混合体。数据密集型体现在：历年录取分数线、招生计划、考生位次、专业热度、院校层次这些数据，动辄几万到几十万条，而且需要清洗、转换、特征提取，这一整套脏活累活，Python生态里的pandas、numpy、sklearn有着碾压级的优势。业务密集型体现在：用户管理、志愿表保存、后台管理、权限控制、日志记录这些常规Web功能，SpringBoot的成熟度远超Python系Web框架，尤其在事务管理、安全框架、微服务治理这些方面。

所以这套项目最常见的合理架构是“双后端协作”：Python（Flask/Django）专职做数据挖掘和推荐算法服务，SpringBoot负责主业务系统，两边通过HTTP接口通信。这样设计有三个实打实的好处。第一，算法团队和业务团队可以完全解耦，算法模型迭代不需要重启业务系统，改完Python服务，接口参数不变，SpringBoot那边完全无感知。第二，Python那边可以随时换算法模型，从协同过滤换成深度学习模型，只需要保证接口出入参结构稳定就行。第三，SpringBoot的成熟生态让整个系统的运维、监控、权限管理都省心很多，这在毕业设计答辩时也是能讲出口的架构亮点。

那Django和Flask怎么选？我的建议是：如果推荐算法涉及复杂的多步骤数据处理、需要ORM来管理算法侧的数据表，选Flask更轻巧灵活；如果你打算把用户体系、后台管理也放在Python侧，那Django的admin和auth模块能省大量开发时间。但在这套双后端架构下，我实际更推荐Flask——因为它的服务只做推荐计算和数据处理，不碰业务逻辑，没必要背上Django那么重的框架包袱，启动速度和内存占用都可观得多。后面我会给出完整的接口通信方案。

这套架构真正要面对的核心问题不是技术选型，而是推荐结果的可信度。高考志愿填报关乎考生前途，推荐系统如果只是简单按分数匹配院校，那其实一条SQL就能搞定，根本不需要“数据挖掘”这四个字。数据挖掘在这个项目里的真正价值，是从历史数据中发现隐含的录取规律、院校竞争态势、专业冷热变化趋势，然后把这些规律转化为可解释的推荐依据。这也是我在设计和实现过程中反复权衡的核心。

2. 数据工程：推荐系统的地基是怎么打牢的

数据挖掘项目有一句老话叫“垃圾进，垃圾出”。高考志愿推荐系统的数据质量，直接决定了推荐结果的可用性。这一节我把数据采集、清洗、特征工程这三步讲透，尤其是一些坑，网上很难找到现成的经验。

2.1 数据源与采集策略

数据源大体分四类：省考试院公布的官方数据（历年各批次投档线）、各高校官网的招生计划和专业设置、第三方聚合平台（如各类高考APP、网站）整理的历史录取数据，以及考生本人在系统里填写的模拟成绩和偏好。

采集方式上，官方数据通常是PDF或者网页表格，推荐的工具链是Python + requests + BeautifulSoup，遇到动态加载的页面就用Selenium兜底。第三方平台的数据结构往往不统一，字段命名五花八门，比如有的叫“最低分”，有的叫“投档线”，有的平台还把“平均分”和“最低分”搞混，这块要专门写一个字段映射表来兜底。

这里必须强调一个合规问题：个人开发项目爬取数据要控制频率和规模，尽量只爬取公开的、非营利性的数据，不要搞大规模的商业化数据采集。另外，采集到的原始数据要保留一份带时间戳的快照存档，因为后续清洗可能出错，需要随时回退对照。我在项目里就是这么做的，03快照备份这个习惯帮我避免了好几次灾难性事故。

2.2 数据清洗的四个关键动作

清洗这一步直接决定了特征工程能不能顺利进行。四年下来踩过的坑，主要集中在以下四个动作。

第一，去重和去异常值。同一个院校在同一个省份可能有多个招生代码（比如分校区、中外合作办学），这些记录在某些数据源里会被当成同名记录处理，导致重复。去重不能只按院校名称，必须按“省份+年份+院校代码+专业组代码”这个粒度来。异常值方面，最常见的是录取分数明显脱离正常区间——比如某年某校投档线突然暴涨30分，这种通常是大小年效应，不能当噪声直接删，但也不能当正常样本用，我的处理方式是单独标记一个“波动异常”标签，在特征层面保留。

第二，位次和分数的统一转换。这是最有技术含量的一步。历史录取分数不能直接拿来比较，因为每年试卷难度、考生人数都在变。常规做法是把分数转换成位次，用位次做跨年份对比。比如某考生今年考了620分，位次是8000名，那就去找往年位次在8000名左右的院校，这是“等效位次法”的核心逻辑。另外还有“线差法”——用考生分数减去当年一本线/本科线，得到线差值，再去对比往年同线差值院校的录取情况。实际工程上，我两种方法都算，然后加权融合，因为不同省份、不同批次，两种方法的适用性不一样。

第三，缺失值处理。招生计划缺专业人数、某年数据缺投档线，这类情况太常见了。数量少的直接用该院校该专业近三年的均值填充；如果某条记录的缺失字段超过40%，建议直接丢弃，不要硬填。这里有个我踩过的坑：2022年某省新高考改革，专业组划分方式变了，历史数据里的院校代码和老专业组结构跟新高考完全对不上，直接填充就是灾难，后来我写了一段基于“院校+专业名称模糊匹配”的映射逻辑，才把历史数据救回来。

第四，数据标准化。不同院校的录取最低分、平均分，不同省份的总分（有的750，有的660），这些量纲不一致的字段，在做聚类和距离计算时必须做标准化处理。我用的是StandardScaler（Z-score标准化），把数据压到均值为0、方差为1的分布上，这样后续K-Means聚类和KNN近邻计算才不会出现“分数维度过大把其他特征淹没”的问题。

2.3 特征工程的实战设计

特征工程是数据挖掘和机器学习里“八分靠人工”的那部分。这个项目的核心特征，我最终沉淀为四大类。

第一类，考生侧特征。总分、位次、线差（与批次线的差值）、等效分（换算到上一年度的分数）、选科组合（新高考省份）、地域偏好（用One-Hot编码）、专业兴趣方向（由用户选择或测评生成）。

第二类，院校侧特征。院校层次（985/211/双一流/普通本科，做等级映射）、所在城市等级（一线/新一线/二线/三线）、往年录取位次分布（最低位次、中位数位次、最高位次）、招生计划人数、专业数量、硕士点数量、综合排名得分。

第三类，交互特征。考生位次与院校最低位次的差值、位次比值（位次/院校最低位次，这个比值越接近1说明越压线，越大说明越稳妥）、院校近三年大小年波动幅度、专业热度指数（由填报人数或搜索热度拟合）。

第四类，时间特征。年份、院校近五年录取位次的趋势斜率——这个特征很有用，能识别出持续走热或持续变冷的院校，对预测下一年趋势很有帮助。

特征不是越多越好。我一开始建了四十多个特征，结果模型反而变差了，主要原因是有大量冗余特征和噪声特征。后来用随机森林的特征重要性排序，砍到十五个核心特征，线上效果反而更稳。高维度数据在小样本量下很容易过拟合，志愿填报数据本身样本就不大，特征控制在十五到二十个是比较合理的区间。

3. 推荐引擎核心：数据挖掘算法是怎么落地的

这一节是整套系统的灵魂。我最终实现了三条推荐路径：基于协同过滤的“猜你喜欢”、基于聚类的“院校分层”、基于规则的“冲稳保”，以及它们的组合策略。每个算法都从原理、参数、坑三个维度来讲。

3.1 用户画像构建：推荐系统的起点

协同过滤的前提是“相似的用户喜欢相似的院校”，所以先要构建用户画像。用户画像分两个层面：基础画像（分数、位次、选科、地域）和行为画像（浏览过的院校、收藏过的专业、搜索的关键词、停留时间）。

实际操作中，行为数据是从前端埋点采集的。考生在系统里搜索院校、查看专业详情、加入志愿表，这些行为都会被打上权重——加入志愿表的权重最高，收藏次之，浏览最少。然后给每个考生生成一个行为向量，和基础特征向量拼接成完整的用户特征向量。

这里分享一个经验：不要直接把原始行为次数当特征，要把行为做归一化和时间衰减。比如考生昨天浏览的院校权重0.9，一周前浏览的权重0.5，这样能体现近期意向的倾向性。我用了一个简单的指数衰减函数：weight = initial_weight × exp(-λ × days)。λ取0.1左右，效果比较合适。

3.2 协同过滤推荐：小众院校挖掘利器

协同过滤分User-based和Item-based两种。在高考志愿这个场景里，User-based更直观：找位次相近、偏好相似的考生群体，看他们最终录取（或倾向填报）了哪些院校，再推荐给当前用户。

数学上，用户相似度我用余弦相似度来计算，但直接算浮点数的余弦相似度有两个问题。第一，行为向量非常稀疏，大部分用户只有几十条行为记录，余弦相似度会偏大，失真严重；第二，位次差很大的用户行为相似度意义不大，一个600分考生和一个450分考生的行为模式即使相近，推荐的院校也不能互换。

所以我做了两层过滤：先按位次区间分层（比如每20分一层），只在相邻层次内计算相似度；再做余弦相似度计算，加一个“位次相似度衰减系数”作为权重。这样算出来的相似用户才真正有参考价值。

Item-based也值得做。某些院校经常被同一批考生同时加入志愿表，那它们之间就存在“被同时选择”的关联关系，用关联规则的思想挖掘“经常一起出现在志愿表里的院校组合”，作为补充推荐。这个思路和电商的“购买了A的人也购买了B”完全一致，但在志愿填报场景里更聚焦专业方向和地域倾向的关联。

3.3 K-Means聚类：院校的“冲稳保”分层逻辑

“冲稳保”是志愿填报的基本策略。冲是指录取位次略高于考生位次的院校，保是明显低于考生位次的院校。但什么叫“略高”、什么叫“明显低”？不能拍脑袋定义，我用的方法是基于历史录取分布数据做聚类分析。

具体做法是：以考生位次为中心，向上取20%位次区间、向下取30%位次区间，把这个区间内的院校按“录取最低位次相对考生位次的距离”聚类成三组。K-Means聚类的K值取3（对应冲、稳、保三层），聚类特征用“位次距离标准化值 + 近三年录取波动幅度 + 院校热度”这三个维度。

这里有两个调试经验必须讲。第一，K-Means对初始质心敏感，同一批数据跑两次结果可能不同，我加了k-means++初始化，并且固定了随机种子，保证结果可复现。第二，聚类结果不一定刚好符合“冲稳保”的直觉，有时候波动特别大的院校会被单独聚成一类，这时候要结合业务规则做后处理，不能生硬地拿聚类结果直接给考生推荐。我在代码里加了一个规则修正层，聚类结果落位后，再用“位次比值”做一次校验，不合理的做边界修正。

3.4 规则引擎与接口层面的保障逻辑

纯算法推荐有时候会给出不合理的组合，比如推荐了三个“冲”的院校但一个“保”的都没有，或者推荐的院校专业组和考生的选科限制不匹配。所以最后必须过一道规则引擎。

规则优先级如下：选科匹配是硬约束，不满足直接淘汰；地域偏好是软约束，不符合的靠后排序；招生计划为零的院校直接剔除；专业热度爆表的院校给出风险提示；冲稳保比例原则上按3:4:3分配（这个比例可以参考各省报考指导手册的常见建议，也可以做成系统参数让管理员调整）。

同时，接口层面一定返回推荐理由。我设计推荐接口的出参结构时，每条推荐记录都带“推荐依据”字段，比如“与你位次相近的考生多选择该校”“该校近三年录取位次稳步上升，注意冲刺风险”。推荐理由不仅让系统显得“智能”，更能显著增加用户信任度——考生和家长都希望知道为什么推荐这所学校，而不是被塞一个黑盒结果。

这一整条链路跑下来，当年我测试了一组真实考生的模拟数据，推荐结果和该考生最终实际录取院校的匹配度（Top20命中率）大约在72%左右，在同类型项目里已经是不错的数字。当然这和个人填报的偏好差异有关，有些考生就是不按位次规律来选学校。

4. 系统实现：双后端怎么协作才不打架

架构分层清晰之后，落地环节的关键就是两个后端之间怎么定接口、怎么传数据、怎么保证并发下的稳定性。这一节给出一套可以直接复制的实现方案。

4.1 整体架构与通信机制

系统整体分四层：前端展示层（Vue/Thymeleaf）、SpringBoot业务层、Python推荐引擎层、MySQL+Redis数据层。

SpringBoot和Python服务之间的通信，我推荐用RESTful API加JSON格式传输。为什么不用Dubbo这种RPC框架？因为Python侧用Flask起一个轻量服务就够了，RPC框架的注册中心、协议转换在这套场景里都是过度设计，增加部署复杂度还不好调试。

具体的调用方式是：SpringBoot在需要推荐结果时，通过RestTemplate（或轻量的OkHttp）向Python服务发POST请求，Python服务接收考生ID和特征参数后，内部跑完推荐算法，返回推荐的院校列表和理由。Python服务是无状态的，所有状态都从MySQL和Redis里读取，这样Python服务可以水平扩展，挂掉一台不影响整个业务。

部署上用一个简单技巧：用Nginx反代给两个后端服务做统一入口，SpringBoot监听8080端口，Python Flask监听5000端口。Nginx上配两条路径规则，/api/**走SpringBoot，/recommend/**走Flask。这样前端只认Nginx一个地址，不用管后端到底有几个服务。

4.2 SpringBoot侧的核心接口设计

SpringBoot这边并不需要复杂的业务逻辑，核心是四个模块。

用户模块：登录注册、JWT鉴权、考生信息维护。这里有个细节，SpringSecurity做JWT鉴权时不要默认放行所有接口，推荐相关的接口也要走鉴权，防止用户越权查看别人保存的志愿表。

院校查询模块：分页查询院校信息、按省份/层次/专业筛选。数据库表设计上，院校表、专业表、录取分数线表三张核心表，录取分数线表建议按年份分区，不然单表数据量过百万后查询会很吃力。

志愿表模块：考生的志愿草稿箱和正式提交表，包含冲稳保标签、院校排序、专业选择。这个功能看起来简单，但并发场景要注意，多个考生同时提交同一所热门院校的志愿表时，要用乐观锁或Redis分布式锁控制，防止数据错乱。

推荐接口模块：SpringBoot侧定义一个RecommendController，接收studentId和可选参数，内部调Python服务。下面是接口的核心代码示意。

@RestController @RequestMapping("/api/recommend") public class RecommendController { @Autowired private RestTemplate restTemplate; @Value("${python.recommend.url}") private String pythonUrl; @PostMapping("/colleges") public Result recommendColleges(@RequestBody RecommendRequest request) { // 1. 从数据库加载考生特征 StudentFeature feature = studentFeatureService.getByStudentId(request.getStudentId()); // 2. 组装发给Python引擎的数据 Map<String, Object> pythonData = new HashMap<>(); pythonData.put("student_id", request.getStudentId()); pythonData.put("score", feature.getScore()); pythonData.put("rank", feature.getRank()); pythonData.put("subject_combo", feature.getSubjectCombo()); pythonData.put("preferred_cities", feature.getPreferredCities()); pythonData.put("top_n", request.getTopN() == null ? 30 : request.getTopN()); // 3. 调用Python推荐引擎 ResponseEntity<JsonNode> response = restTemplate.postForEntity( pythonUrl + "/api/v1/recommend", new HttpEntity<>(pythonData), JsonNode.class); // 4. 统一包装返回 return Result.success(response.getBody()); } }

这段代码里有几个关键设计。调用Python服务时把超时时间设置为3秒，推荐算法整体执行控制在1秒内，超过就降级返回缓存结果。restTemplate实例要用连接池配置，不然高并发下TCP连接会被打满。Python服务的地址做配置化，部署环境切换时改配置文件就行，不推荐硬编码。

4.3 Python推荐引擎的实现细节

Python侧用Flask起服务，结构上分成三层：数据处理层、算法层、API层。数据处理层负责从MySQL读取原始特征、做标准化和缓存；算法层实现协同过滤、聚类、规则过滤；API层暴露接口。

推荐主流程我贴一段核心伪代码，这个流程是我调优过很多次的最终版本。

# app/services/recommend_service.py import numpy as np from sklearn.preprocessing import StandardScaler from sklearn.cluster import KMeans from app.utils.similarity import cosine_similarity_with_rank_weight from app.utils.rule_engine import RuleEngine, RulesConfig def recommend_for_student(student_feature, top_n=30): # 1. 特征标准化 scaler = StandardScaler() all_features = load_all_college_features() # 从MySQL读取 scaled_features = scaler.fit_transform(all_features) # 2. 按位次区间分层，只在相邻层内找相似考生 candidate_pool = get_candidate_pool_by_rank(student_feature.rank) # 3. 协同过滤：找到相似考生，聚合他们倾向的院校 similar_users = find_similar_users( student_id=student_feature.student_id, pool=candidate_pool, top_k=50 ) cf_scores = aggregate_college_scores_from_users(similar_users) # 4. 聚类：冲稳保分层 target_colleges = load_colleges_in_rank_range(student_feature.rank) km = KMeans(n_clusters=3, init='k-means++', random_state=42) labels = km.fit_predict(target_colleges[['distance', 'volatility', 'hotness']]) target_colleges['level'] = labels # 0=冲, 1=稳, 2=保 # 5. 规则过滤 + 加权融合 rule_engine = RuleEngine(RulesConfig( subject_match=True, city_preference_weight=0.1, plan_count_threshold=0 )) final_result = rule_engine.filter_and_rank( cf_scores=cf_scores, college_levels=target_colleges, student_feature=student_feature ) return final_result[:top_n]

这段逻辑有几个值得注意的点。第一，find_similar_users里一定要加位次分层的过滤条件，否则全量算相似度，数据量大了以后单次请求会慢到不可接受。第二，KMeans聚类时我用的特征是distance（考生位次与院校最低位次的标准化距离）、volatility（近三年位次波动幅度）、hotness（院校热度），这三个特征的量纲差异很大，所以必须先标准化，否则聚类结果会被distance一个维度主导。第三，规则引擎的过滤条件不能太激进，选科匹配是硬性条件，但地域偏好给一个0.1的权重做软性惩罚就行，不能直接过滤掉，否则推荐的院校全集中在考生偏好城市附近，反而忽略了其他更合适的选择。

4.4 缓存策略与接口性能优化

推荐接口第一次调用时，Python服务要从MySQL查大量数据、跑聚类算法，耗时可能到2到3秒。但这类推荐请求，同一个用户短期内重复调用的概率很高，而且不同用户之间的院校特征数据变化频率很低，所以缓存策略非常关键。

我做两级缓存。第一级是Redis缓存院校特征数据，key设计为college_features:2024，过期时间设置12小时，每天凌晨数据更新后主动刷新缓存。第二级是推荐结果缓存，key设计为recommend:{student_id}:{top_n}:{feature_hash}，过期时间30分钟。feature_hash是对用户特征做了一个MD5摘要，特征变化（比如用户改了地域偏好）后hash变了，缓存自动失效，不会命中旧结果。

实际压测下来，第一次请求约2.8秒，命中缓存后降到40毫秒以内。用JMeter做了500个并发用户压测，SpringBoot和Python服务的CPU都稳定在70%以下，没有出现线程阻塞或连接池耗尽的问题。对毕设级别的项目来说，这个性能已经完全够用。

5. 实操全过程：从零搭建的完整步骤记录

前面聊了原理和核心代码，这一节把我实际的开发顺序完整过一遍。这个顺序是我做了两轮之后总结出来的最优路径，照着这个顺序走，每一步都有前置依赖，不会返工。

5.1 阶段一：数据库设计和数据采集（约3天）

先建库建表。核心表六张：user（用户表）、student_profile（考生信息表）、college（院校信息表）、college_major（专业表）、admission_score（历年录取分数表）、volunteer_form（志愿表）。设计表的时候就把索引规划好，admission_score表按(college_code, year)建联合索引，这是查询最频繁的组合。我一开始没建索引，跑了几个查询后发现单条SQL要扫全表，加了索引之后速度提升了近10倍，这种低级错误浪费了我一整天。

数据采集脚本用Python写，分三个模块：爬虫模块、解析模块、入库模块。爬虫模块负责下载页面或文件，解析模块处理HTML/PDF转结构化数据，入库模块批量写入MySQL。三个模块用消息队列串联，采集任务挂机跑几个小时就能完成一个省份一个年度的数据。

采集完数据先别急着做算法，先写几段数据质量检查代码，统计每个字段的缺失率、重复率、异常值数量，出一份数据质量报告。这个报告是后续清洗和特征工程的重要依据，也方便答辩时展示工作量。

5.2 阶段二：特征工程和算法原型验证（约4天）

在Jupyter Notebook里先把特征工程的Pipeline跑通。我用的是单独写一个feature_engineering.py模块，里面定义了一个FeatureBuilder类，输入原始数据帧，输出特征数据帧。这个模块后面在Flask服务里会被直接调用，所以在Notebook里验证时就要保证代码质量和模块化。

算法原型验证我做了两个对比实验。实验一是协同过滤的参数敏感性测试，看top_k（相似用户数量）取20、50、100时推荐结果的变化；实验二是冲稳保聚类在不同K值（2、3、4）下的稳定性。两个实验都是为了在正式集成前确定最优参数。最后top_k定50、K值定3，理由前面已经讲过。

模型评估这块，除了前面说的Top20命中率，我还算了一个“压线准确率”：推荐给考生的院校中，录取位次落在考生位次上下15%区间的比例。这个指标能反映推荐是否既不太冒险也不太保守，我调参后的压线率在61%左右，分布在冲、稳、保三层，分布还算合理。

5.3 阶段三：SpringBoot业务系统开发（约5天）

SpringBoot的业务开发按模块拆任务，顺序是：用户模块 → 院校查询 → 志愿表 → 接推荐接口。每个模块开发完都要写单元测试，JUnit + Mockito足够。最关键的坑是SpringBoot的版本选择，不要追最新版，选稳定版本就好，因为有些第三方库对高版本支持不完整，我见过不少人在整合MyBatis和SpringSecurity时因为版本冲突浪费大量时间。

接入推荐接口时，先Mock一个Python服务的Stub（用MockServer或者本地起一个返回固定JSON的假服务），把SpringBoot和前端联调做完，再切换真实Python服务。这样能做到前后端联调和算法开发并行，不用互相等。

5.4 阶段四：Python服务接口封装和联调（约3天）

Flask服务要处理的细节里，最容易被忽视的是CORS跨域、请求日志和异常处理。CORS配置要放在所有路由注册之前，否则会报跨域错误。统一异常处理要做好，算法内部抛异常不能直接暴露堆栈给前端，要包装成统一的JSON错误结构。

联调时最常出的问题是对参数格式的理解不一致。比如SpringBoot传日期是用String格式还是timestamp，前端传选科组合是传数组还是字符串，这种问题在接口文档里写清楚，并且开发时用Postman先调一遍，能省掉后面大量扯皮时间。

5.5 阶段五：系统部署与演示环境（约2天）

开发机验证没问题不代表部署环境能跑起来。部署我放在Linux云服务器上，Java跑Jar包，Python用gunicorn+gevent多 worker跑。数据库用MySQL 8.0，Redis做缓存。部署的时候有几个小坑提前说：Python依赖先做好requirements.txt，并且锁死版本，不锁版本换一台机器可能就装不上；gunicorn的worker数不要拍脑袋定，按CPU核数×2+1来配置，我是2核4G的机器配了3个worker，跑得很稳；系统时区设置保持统一，不然数据库时间字段会和本地时间对不上，排查起来非常痛苦。

整个项目从设计到上线，总共花了两到三周的时间，这个节奏对毕业设计来说是完全可执行的。

6. 常见问题与调试实战

做这套系统时遇到过的各种问题，挑六个最有代表性的讲。这些问题如果不提前知道，排查耗时可能是按天计的。

6.1 数据稀疏导致协同过滤推荐结果趋同

有相当一部分考生几乎没有行为数据，协同过滤找不到相似人群，就会把所有用户都推荐同一批热门院校，这等于完全没有个性化。我当时的解决策略是给冷启动用户走“分数优先+规则过滤”的路子：先按位次匹配一批候选院校，再用地域偏好、专业倾向做规则排序，等用户产生行为数据后再逐渐切换回协同过滤。这个策略能保证冷启动用户也能拿到不错的推荐结果。

6.2 跨年数据可比性差导致聚类结果错乱

新高考改革省份的院校录取模式变了，旧数据是文理分科录取，新数据是专业组录取，直接混在一起算聚类，各种失真。最后的方案是给数据打上“录取模式”标签，算法计算时限定在同一个录取模式内进行，跨模式只能做趋势参考不做定量计算。这个逻辑一定要在设计数据库时就留好字段，不然后期补会非常痛苦。

6.3 Python服务超时引发SpringBoot接口降级

有一次线上环境Python服务因为数据库连接池耗尽导致接口响应超过10秒，SpringBoot侧同步调用直接卡死，用户请求全部堆积。后来加了RestTemplate的ReadTimeout为3秒，超时后Redis缓存兜底返回上一次推荐结果，同时异步记录失败日志。如果你的应用对实时性要求高，这个超时降级方案是必做的。

6.4 中文分词影响专业兴趣推荐

做专业兴趣匹配时，最初用的分词是jieba，对“计算机科学与技术”这类专业名分词还算准，但碰到“人工智能”“数据科学与大数据技术”这种新专业，切分效果一塌糊涂。后来换成腾讯开源的HanLP，配合自定义专业名词词典，效果好了很多。实际调优时发现这类专业描述词的匹配，直接走完整匹配 + 同义词映射表有时候比分词更靠谱，效率也高。

6.5 前端展示的冲稳保标签与算法结果不一致

算法返回的院校分层标签是聚类结果，前端要根据这个标签展示“冲、稳、保”的样式，有几次两边对不上，后来定位是前端把英文字段level解析成了ASCII码，根本没做映射。这些问题都是很基础但很容易漏掉的，接口联调时，前后端最好协商标签枚举值，不要各自自定义。

6.6 数据更新后推荐结果未及时刷新

每天更新完录取数据，用户还是拿到昨天的推荐结果。原因是Redis缓存过期时间设成了24小时，数据更新的时间点又正好在缓存有效期内。我的解决办法是加一个“数据版本号”机制：每次数据更新后，版本号自增，推荐接口在读缓存前先比对版本号，不一致就强制穿透到算法层重新计算。这个设计也能在答辩里作为一个亮点来讲。

7. 效果对比与优化方向

7.1 算法组合的增益验证

为了验证“协同过滤+聚类+规则过滤”这套组合确实比单一算法效果好，我做了三组对比实验。只用协同过滤时，推荐的院校偏大众化，个性化不足；只用聚类分层时，推荐结果太依赖规则，缺乏对用户行为的利用；三层组合之后，Top20命中率从单算法的52%提升到72%，压线准确率也从48%提升到61%。实验结果用图表展示，答辩效果会非常好。

7.2 数据层面的迭代效果

数据是这套系统真正的护城河。我把数据从一个省扩充到三个省后，推荐系统的表现并没有明显变差，这说明特征设计是合理的。同理，把年份从3年扩充到5年，波动幅度特征的信息量更充足，预测趋势更稳定，压线准确率又升了4个百分点。数据越全，推荐结果越稳，这在志愿填报这个场景里格外明显。

7.3 可以继续深挖的方向

这套系统后续能做的优化方向不少。用深度学习模型（比如Wide & Deep）来捕捉复杂交互特征；加入序列模型来理解考生在志愿填报过程中的动态偏好变化；把院校的专业就业数据融入推荐逻辑，让推荐结果兼顾考生职业规划；做一个志愿表冲突检测模块，防止考生最终的志愿表出现三所院校都是同一级别的冲刺校这种问题。这些都是有真实应用价值的方向。

个人操作体会

整套系统从数据采集到最终上线，我最深的感受是：高考志愿推荐系统真正的难点不在算法，而在数据和规则的可解释性。面试官或者答辩老师最常问的问题就是“你这套推荐结果凭什么可信”。所以我在系统里做了非常多的“显式规则”，每一条推荐记录都能说清楚推荐依据，这是系统落地时最重要的隐性要求。

另一个体会是技术选型不要贪多求新。这套项目用到的Python数据挖掘链路、SpringBoot业务框架、Redis缓存，全都是成熟稳定的技术，没有任何花哨的成分，但组合起来能解决一个真实的问题，本身就是有价值的项目。

最后分享一个小经验：如果这个项目是毕业生用来找工作，建议把重点放在“数据质量治理”和“推荐效果评估”上，不要只讲技术栈。面试官真正感兴趣的往往不是你会用几个框架，而是你如何把一个模糊的业务问题转化成可执行的工程方案，并且用数据验证了它的有效性。这套思路在任何数据类项目里都是通用的。