2022年夏天帮亲戚家小孩查志愿，电脑屏幕上同时开着五个 Excel，一个放院校投档线，一个放专业录取分，一个放一分一段表，还有一个是往年各批次划线。VLOOKUP 来回拉了三天，孩子的电话天天来问“这个稳不稳”。被烦透之后我决定把这个过程彻底工具化——用 Node.js 加 Vue 整套做一套“高考志愿填报辅助系统”，把查学校、查分数、换算位次、冲稳保判断、志愿清单收集全部塞进一个 Web 应用里。
这套系统听起来很大，实际拆开其实就三块底座：数据建模、推荐算法、前后端交互。这篇文章我会从数据表设计讲到推荐 API 实现，再讲 Vue 前端怎么把“冲稳保”可视化，最后把上线前后踩过的坑一并交代清楚。无论你是拿它当毕业设计、课程设计，还是想给自己认认真真做一个选校工具，都有可以直接搬走的部分。
1. 为什么做这个系统：手工翻数据的痛与前后端分离的解法
先说痛点。志愿填报这件事的信息量是典型的“低频刚需，高密度数据”：一个省每年有几千个招生院校，每个院校又有多个批次、多个专业组，组里再挂一堆专业；往年的录取分数、录取位次、招生计划全部整理下来，少说也有几十万行。更麻烦的是，每年试题难度不同、批次线浮动，直接拿分数比去年毫无意义，必须把分数换算成全省位次，这个动作手工做一次两次还行，做二十个志愿会疯。
所以我从一开始就明确了系统目标：不是做官方志愿填报系统，而是做“辅助工具”。它只做四件事：
- 查院校：按省份、层次（985/211/双一流/普通）、地域、关键字筛学校；
- 查分数：展示某学校近三年在某省的录取最低分、最低位次、平均分与位次；
- 智能匹配：输入自己的分数和省份科类，系统自动算出声和分段对应位次，再和历史录取数据比对，给出冲、稳、保三个梯度的学校列表；
- 志愿工作台：收藏候选学校，形成个人志愿清单，方便反复调整。
技术选型方面，我直接定了 Express + Vue 3 + MySQL 这套组合，没有用 Spring Boot。原因很实际：前后端都是 JavaScript/TypeScript，一个人维护成本低；数据解析脚本、后端接口、前端页面可以共享同一套命名习惯；部署只需要一个 Node 进程加静态文件，比 JVM 那一套轻太多了。后来很多朋友问“为什么不用 Spring Boot + Vue，网上模板多”，我的回答是：模板多不代表适合你，这套系统最难的不是框架，而是数据怎么组织和算法怎么算得让人信服。
架构上我没有搞微服务，就是一个典型的 REST 后端加单页前端：
nodejs后端提供/api/schools、/api/recommend等接口；- Vue 前端用 Vue Router 管理页面，用 Axios 拉数据；
- MySQL 存全部业务数据，Redis 可加可不加，开发阶段我用内存缓存就够了。
这个结构最大的好处是局部可替换：算法可以单独抽出来测，数据导入脚本也不依赖 Web 层，前端就算换人重写，后端一点不用动。
2. 数据模型与数据源：用四张表装下志愿填报的全部底料
很多人在这一步容易犯错——一上来先建一张“学校表”，把录取分数全塞进去，每行塞几十个字段，到最后接口越写越痛。数据应该按业务语义拆表，我这套系统最终只留四张核心表，加一张辅助省份表。
数据源：各省教育考试院每年公布的一分一段表、各批次录取控制线、院校专业组投档线，以及官方志愿填报指南里的招生计划，这些全部是公开数据。做系统时需要自己整理省份、年份、科类、批次等维度，最后导入 MySQL。页面上一定要注明“数据仅供参考，以官方发布为准”，这不是免责做样子，而是这类系统容易出纠纷。
表结构我直接给出可以落地的基础版：
-- 省份表 CREATE TABLE province ( id INT PRIMARY KEY, name VARCHAR(50) NOT NULL, province_code VARCHAR(20) UNIQUE NOT NULL ); -- 院校表 CREATE TABLE school ( id INT PRIMARY KEY AUTO_INCREMENT, school_code VARCHAR(30) UNIQUE, name VARCHAR(120) NOT NULL, province_code VARCHAR(20), city VARCHAR(50), level VARCHAR(20), -- 985 / 211 / 双一流 / 普通 nature VARCHAR(20), -- 公办 / 民办 / 中外合作 website VARCHAR(200), KEY idx_province (province_code), KEY idx_level (level) ); -- 招生计划（院校专业组/专业） CREATE TABLE major_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, school_id INT NOT NULL, major_code VARCHAR(30), major_name VARCHAR(120) NOT NULL, batch_code VARCHAR(20), -- 本科批/提前批/专科批 group_name VARCHAR(50), -- 新高考“院校专业组”代码，可选 length_years TINYINT, tuition INT, subject_requirement VARCHAR(100), -- 选科要求，如“物理+化学” plan_count INT, KEY idx_school (school_id) ); -- 录取分数线 CREATE TABLE admission_line ( id BIGINT PRIMARY KEY AUTO_INCREMENT, school_id INT NOT NULL, major_id BIGINT, -- 若只有院校线，该字段为 NULL year SMALLINT NOT NULL, province_code VARCHAR(20) NOT NULL, subject_type VARCHAR(20) NOT NULL, -- 理科/文科/物理类/历史类 batch_code VARCHAR(20), score_line INT, -- 当年省份批次线 min_score INT, min_rank BIGINT, avg_score INT, avg_rank BIGINT, KEY idx_search (province_code, subject_type, batch_code, year), KEY idx_school_year (school_id, year) ); -- 一分一段表 CREATE TABLE rank_segment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, year SMALLINT NOT NULL, province_code VARCHAR(20) NOT NULL, subject_type VARCHAR(20) NOT NULL, score INT NOT NULL, segment_count INT NOT NULL, -- 该分数段人数 cumulative_rank BIGINT NOT NULL, -- 累计人数，即该分数对应全省位次 KEY idx_rank (year, province_code, subject_type, score) );解释几个关键设计点。
第一，admission_line里既有院校线也有专业线，用major_id区分。很多省份只公布到院校专业组，个别专业还要单独看，这个字段留着就灵活。
第二，rank_segment是整系统的命根子。把分数换成位次全靠它。官方一分一段表通常给出分数段人数和累计人数，cumulative_rank就是位次；如果某些省份只公布“xx 分段人数”，导入时做一次累加就能还原位次。
第三，新高考省份的选科约束不能少。现在很多省份实行“院校专业组”，一个学校有多个物理类组、历史类组，组之间选科要求不同，调剂的逻辑也不同。我只在major_plan里加了一个group_name字段，先满足基础查询，如果你要精确匹配，建议再加一个group_rule表单独存选科组合规则。
第四，所有查询索引都围绕province_code + subject_type + batch_code + year建。这个组合才是用户查询时的真实过滤条件，没索引的话，几万行数据做全表 scan 会非常难受。
导入环节我踩过一个坑：直接拿 Excel 文件用 Node 的xlsx库整表读进来，一次性insert上万行，内存飙升。后来改成用 CSV 按行readline流式读，再用mysql2的批量插入分页提交，速度稳定很多。四张表全部导完大概几十万行，几分钟之内能结束。
3. 核心算法：位次换算、“冲稳保”梯度的判断逻辑
这一部分是整个系统真正值钱的地方。先说结论：永远不要直接拿“分数”跨年份比较。某校去年最低 590，今年涨到 610，不代表它变难考了，很可能只是今年题目简单。真正稳定可比的是“位次”——它在同一省内、同科类之间，代表你在所有考生里的相对位置。
所以推荐引擎的第一步是位次换算。用户输入他的高考分数后，我用当年的rank_segment表反查：
async function queryRank({ score, provinceCode, subjectType }) { const sql = ` SELECT cumulative_rank FROM rank_segment WHERE year = ? AND province_code = ? AND subject_type = ? AND score <= ? ORDER BY score DESC LIMIT 1 `; const [rows] = await pool.query(sql, [currentYear, provinceCode, subjectType, score]); return rows[0]?.cumulative_rank ?? null; }如果用户输入的分数高于当年所有分段，取累计人数最小值；低于第一个分段，就返回空并提示用户检查数据。这块不要做太过复杂的插值，院校录取数据本身是有噪声的，精度用到“位次区间”级别就够。
第二步是拿位次和学校历史录取位次比对。我用的判断方法是“录取位次偏差法”：
- 取目标院校、同省份、同科类、同批次过去三年的
min_rank（最低录取位次）； - 按年份加权平均，最新一年权重最高，比如近三年权重分别为 0.5、0.3、0.2；
- 算出用户位次相对学校基准位次的偏差比例
diff = (userRank - refRank) / refRank。
这里要解释一下位次的方向问题：位次数字越小，代表名次越靠前、越有优势。学校去年的最低录取位次是 23000，意思是有学生以全省第 23000 名的位次进校，这是学校录进去的最后一名。你今年考了全省第 25000 名，diff就是正的，代表你比学校的“底线”还差一点，这就是“冲”；第 21000 名，diff是负的，优于学校的底线，大概率进，就是“稳”甚至“保”。
细分规则如下：
| 偏差范围 | 标签 | 含义 |
|---|---|---|
diff > 0.15 | 高风险 | 离往年最低录取位次差太多，不建议放进前几个志愿 |
0 < diff <= 0.15 | 冲 | 比最低录取位次差 0% 到 15%，可以冲一冲 |
-0.10 <= diff <= 0 | 稳 | 位于最低录取位次附近，录取概率较高 |
diff < -0.10 | 保 | 明显优于最低录取位次，作为保底志愿 |
算法核心代码就这么一段：
const YEAR_WEIGHTS = [0.5, 0.3, 0.2]; function classify(diff) { if (diff > 0.15) return { label: '高风险', tag: 'danger' }; if (diff > 0) return { label: '冲', tag: 'warning' }; if (diff >= -0.1) return { label: '稳', tag: 'primary' }; return { label: '保', tag: 'success' }; } function calcDiff(userRank, lines) { const ranked = lines .sort((a, b) => b.year - a.year) .filter((l) => l.min_rank != null) .slice(0, 3); if (!ranked.length) return null; const totalWeight = ranked.reduce((sum, l, i) => sum + YEAR_WEIGHTS[i], 0); const refRank = ranked.reduce( (sum, l, i) => sum + l.min_rank * YEAR_WEIGHTS[i], 0 ) / totalWeight; return (userRank - refRank) / refRank; }为什么给最新一年更高的权重？因为招生计划和生源结构逐年变化，2023 年的数据比 2019 年的数据更能反映当前趋势。权重比例不用太死，你也可以用 0.4、0.33、0.27，但原则上必须让最近一年占主导。
除了位次偏差，系统还应该支持三个“硬过滤条件”：
- 批次过滤：不能把本科批的用户推到专科批；
- 选科过滤：新高考省份，考生选科组合必须满足专业组的选科要求；
- 地区/兴趣过滤：用户不接受的省份直接排除。
这些条件在 SQL 里先过滤，再进算法，不要在算法里逐条判断，否则代码会越来越臃肿。
整个算法虽然不复杂，但我实际做的时候花了一晚上反复推演边界：diff = -0.1到底是稳还是保？如果某校连续三年位次波动特别大怎么办？最后我给波动大的学校加了“三年位次极差”字段，极差超过 40% 就直接降低推荐权重。这类学校大小年效应太明显，位次偏差法对它们的预测力本来就弱。
4. Node.js 服务端实现：Express 路由、推荐接口与缓存设计
后端我用 Express 5 起步，接口设计成下面几条，够用且直观：
// 院校列表（筛序） GET /api/schools?keyword=大学&province=北京&level=211&page=1&size=20 // 院校详情（含近三年录取数据） GET /api/schools/:id // 智能推荐（核心接口） POST /api/recommend Body: { score: 610, provinceCode: '37', subjectType: '物理类', batchCode: '本科批', interest: ['计算机', '医学'] } // 志愿清单（可选，后端存储） POST /api/favorites GET /api/favorites推荐接口的实现我分了三层：入口路由层、推荐服务层、数据访问层。入口只做参数格式校验，真正逻辑放services/recommend.js。
// routes/recommend.js router.post('/recommend', async (req, res) => { const { score, provinceCode, subjectType, batchCode } = req.body; if (!score || !provinceCode || !subjectType || !batchCode) { return res.status(400).json({ message: '缺少必要参数' }); } const userRank = await rankService.queryRank({ score, provinceCode, subjectType, }); if (!userRank) { return res.status(404).json({ message: '分数无效，请检查省份与科类配置' }); } const recommendations = await recommendService.recommend({ userRank, provinceCode, subjectType, batchCode, }); res.json({ userRank, items: recommendations }); });推荐服务内部做了池化缓存。因为对同一个省份、科类、批次来说，院校池里的数据短期内完全不变，不需要每次请求都查一遍大表。我用非常简单的内存 Map 做缓存：
const cache = new Map(); const TTL = 5 * 60 * 1000; // 5 分钟 async function getPool({ provinceCode, subjectType, batchCode }) { const key = `${provinceCode}-${subjectType}-${batchCode}`; const hit = cache.get(key); if (hit && Date.now() - hit.time < TTL) return hit.data; const [rows] = await pool.query( `SELECT s.id, s.name, s.level, s.city, l.year, l.min_rank, l.avg_rank, l.min_score, l.score_line FROM admission_line l JOIN school s ON s.id = l.school_id WHERE l.province_code = ? AND l.subject_type = ? AND l.batch_code = ? AND l.year BETWEEN ? AND ? ORDER BY s.id, l.year DESC`, [provinceCode, subjectType, batchCode, currentYear - 3, currentYear] ); cache.set(key, { time: Date.now(), data: rows }); return rows; }这样处理之后，每次推荐请求只有位次反查和内存计算，接口耗时能压在 50ms 以内。如果后续并发大了，把 Map 换成 Redis 也很容易，key 不变。
排序权重也是值得说清楚的。同样的“冲”字标签，有的学校偏差 1%，有的偏差 14%，前者显然更值得冲刺。我专门加了一个推荐分：
function computeScore(label, diff) { switch (label) { case '冲': // diff 越大越危险，分数越低 return Math.round(60 - (diff / 0.15) * 40); case '稳': // 越接近 0 越合适 return Math.round(70 - Math.abs(diff) * 150); case '保': // 留的余量越大，越稳 return Math.round(85 + Math.min(1, -diff - 0.1) * 15); default: return 0; } }最后按“标签权重 + 推荐分”双重排序，冲、稳、保三组各自输出前 50 条，前端分栏展示。认真提醒一句：这里的分数只是系统内部的经验排序，不保证录取概率，不能让用户产生“90 分就一定会被录取”的误解。
5. Vue 前端落地：筛选联动、推荐卡片与填报工作台
前端我用的 Vue 3 组合式 API 加 Element Plus 组件库，页面拆成四大块：院校查询页、智能推荐页、志愿工作台、数据管理页。Vue 的作用不只是画界面，它特别适合这种“多条件筛选 + 表格 + 图表 + 状态共享”的组合场景。
先看最核心的推荐结果页。接口返回的每一所学校都带label（冲/稳/保）、diff、minRank等字段，Vue 端直接映射成卡片。我写了一个RecommendCard.vue，大致结构：
<template> <div class="recommend-card" :class="item.label"> <div class="header"> <el-tag :type="tagMap[item.label]">{{ item.label }}</el-tag> <span class="name">{{ item.name }}</span> </div> <div class="meta"> <span>{{ item.city }}</span> <span>{{ item.level }}</span> </div> <div class="score-line"> 近三年最低位次： <span v-for="line in item.lines" :key="line.year"> {{ line.year }}: {{ line.min_rank }} </span> </div> <el-button size="small" @click="addToWorkspace(item)">加入志愿表</el-button> </div> </template> <script setup> const props = defineProps({ item: { type: Object, required: true }, }); const tagMap = { 冲: 'warning', 稳: 'primary', 保: 'success', 高风险: 'danger', }; </script>筛选联动是这类系统最常见的交互。我在院校查询页做了三层筛选：省市下拉、层次下拉、关键字搜索，配合 Element Plus 的el-select和el-table。查询逻辑走后端接口，点击一次按钮拉一次数据，没有做复杂的前端全量筛选——因为院校数据几千条，真全量拉到浏览器反而卡。
历史分数趋势这块，我用 ECharts 画了最低分和最低位次的双折线图。注意单位差异太大，不能放在同一个 Y 轴：分数是 400–700 的范围，位次是几千到几万，直接画会压扁一边。我设置了两个 Y 轴，左轴分数、右轴位次，家长和考生第一眼就能看出“分数虽然忽高忽低，位次其实很稳定”这个核心信息。
志愿工作台就是典型的 Pinia 状态管理。我定义了一个workspacestore，用户无论从查询页还是推荐页都能把学校加进来，带几个关键字段：学校名称、批次、冲稳保标签、加入时间。工作台里可以拖动排序、删除、清空，最后导出一份 CSV。这里没用后端存用户数据，因为系统没有做多用户登录，localStorage持久化就够个人用户用了。
Vite 开发代理也要提一嘴。前端跑在 5173 端口，后端跑在 3000 端口，跨域问题在开发阶段用代理解决：
// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true, }, }, }, });生产部署时则直接用 Node 后端托管dist目录下的静态文件，不需要额外配 Nginx 也能跑起来：
app.use(express.static(path.join(__dirname, 'dist'))); app.get(/.*/, (req, res) => { res.sendFile(path.join(__dirname, 'dist', 'index.html')); });这个兜底路由必须放在最后，否则/api请求也会被当成前端路由返回 HTML。
6. 开发期与上线前后最容易踩的坑
这一节不写完整部署教程，只讲我在实际开发中碰到过、而且大概率你也会碰到的几个问题。
第一个坑：npm 命令在 Windows PowerShell 下直接报红。
很多人装完 Node.js 后执行npm -v，会看到npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。这不是 Node 装坏了，是 PowerShell 的执行策略默认禁止.ps1脚本。我当时的处理方式是有两种：临时用 CMD 执行 npm 命令；或者以管理员身份打开 PowerShell，执行一次：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned表示本机脚本可以运行，从网上下载的脚本必须有可信签名，安全性可控。改完重开终端就正常了。建议刚上手 Node 的同学直接记住这个命令，不然安装 vue-cli 或 Vite 时会卡在第一关。
第二个坑：Excel 导入时把数据源格式读崩。
各省考试院官网导出的一分一段表，列名五花八门：“分数”“本段人数”“累计人数”算好的，有的直接叫“投档最低分”“最低位次”，还有表头合并、空格、空行。我最早用固定列下标读，换一个省的文件就全错了。后来改成“列名模糊匹配”，比如minRank列允许匹配“最低位次”“最低排位”“投档最低位次”等多种写法，同时导入前先打印前几行预览，确认解析正确再全量导入。这是对多源数据导入的基本敬畏。
第三个坑：算法在大年小年数据面前失真。
我只用近三年加权平均，但有的学校录取位次像过山车，一年 18000、一年 30000，直接平均出来的参考值没有意义。后面我加了“位次波动率”指标：三年最低位次的最大值与最小值之差除以平均值，超过 40% 的学校，推荐信息里单独标注“历年波动大，建议多参考招生计划”。这个标注比强行算出一个冲稳保标签要诚实得多。
第四个坑：新高考省份的选科规则没做对。
有的省份实行“院校专业组”，同一个学校的不同组录取分完全独立；有的省份按“专业+院校”投档，不存在调剂问题。我的基础模型适合传统文理分科和大多数专业组省份，但要真正覆盖全国，必须再加一张配置表维护各省招生规则。如果你只做单省版本，一定要先把该省最新的志愿填报政策读透，不能拿 A 省的逻辑套 B 省。
第五个坑：数据更新之后缓存没失效。
数据导入脚本更新了 2024 年录取分数线，但推荐接口的内存缓存还是旧数据，用户看到的结果错得离谱。我后来在导入接口成功返回时主动调用一次cache.clear()，同时缓存 key 里带上年份维度，保证新旧数据不会混在一起。
关于正式上线，我用 PM2 守护 Node 进程，设了NODE_ENV=production，MySQL 连接池connectionLimit调到 20。这套系统实际跑起来负载很低，多核机器不需要开 Cluster，一个进程处理几千并发查询绰绰有余，真正需要关注的还是数据本身的质量和官方口径是否一致。
最后说一句来自实际使用的体会：这类辅助系统写得再顺，也一定要在页面上反复提示用户“最终志愿方案请与省考试院官方发布的信息核对，并遵循所在省份的填报规则”。工具降低的是信息整理成本，替不了人的判断，更替不了招生政策里那些冷冰冰但必须遵守的规则。做完那套系统之后，亲戚家小孩最终稳稳进了目标学校，那一刻我比做成功任何一个技术项目都高兴。
