企业官网建设流程全解析

简介：这套基于爬虫的高考志愿智能推荐系统Java毕设项目，采用SpringBoot+Vue前后端分离架构，面向计算机专业本科毕业设计、Java全栈学习或教育类系统二次开发。系统完整覆盖考生端与后台管理端，包含登录注册、专业/院校/位次查询、MBTI职业性格测试、院校识别、收藏管理、模拟志愿填报与志愿管理，后台支持专业、院校、咨询、招生计划、用户及MBTI测试管理。技术上通过Python爬虫抓取中国教育在线历年录取数据，结合知识图谱与智能匹配算法，为考生提供个性化志愿推荐。压缩包共671个文件，以Java源码、Vue组件、Python脚本、SQL数据库为主，另含设计文档、答辩PPT与说明文档，整体仅34.56MB，目录结构清晰。目前已有87人学习，适合需要完整毕业设计参考、快速理解前后端分离项目或研究教育数据推荐系统的开发者，具有较高的实战与学习价值。

1. 这套高考志愿推荐系统，卡在JDK版本上的次数最多

拿到这份「基于爬虫的高考志愿智能推荐系统」源码包时，我第一反应是这套东西肯定好装——SpringBoot 2.x + Vue 前后端分离，JDK 1.8、MySQL 5.7、Maven 都是老搭档了。结果第一次启动就翻车，后端一直报UnsupportedClassVersionError，查了半天才发现本机默认 JDK 是 17，而项目是按 JDK 1.8 编译的。这类 SpringBoot 老项目对 JDK 版本极敏感，换个大版本编译直接黑匣子式报错。这份源码带爬虫、知识图谱、MBTI 测试、模拟填报一整套功能，适合毕设或者想跑通「爬虫采集 → 数据落库 → 推荐匹配」全链路的开发者。这篇笔记就是我从零装到跑通的全过程，版本怎么选、参数怎么配、坏了怎么救都在里面。

2. 环境准备：JDK 1.8 + Maven + MySQL 5.7 的版本取舍

2.1 JDK 1.8：SpringBoot 老项目最不能乱动的一环

这套系统后端是 SpringBoot 2.x，开发语言 Java，摘要在环境说明里写死了 JDK 1.8。这不是建议，是硬性要求。SpringBoot 2.x 虽然能在高版本 JDK 上跑，但项目里如果用了依赖 JDK 1.8 内部 API 的库，换到 JDK 11 以上就会遇到java.lang.NoClassDefFoundError这类诡异报错。所以我装环境的第一步不是装新，而是把本机已有的 JDK 版本理清楚。

我一般先执行一条命令确认当前 shell 里到底用的是哪个 JDK：

java -version javac -version echo $JAVA_HOME

如果输出里带17、21这类字样但又不是 1.8，说明环境变量指向错了。不要急着卸载，老项目和新项目共存是常态，正确做法是把 JDK 1.8 单独装到一个固定路径，比如C:\Java\jdk1.8.0_202，然后在系统环境变量里把JAVA_HOME指向它，再把%JAVA_HOME%\bin挪到PATH的最前面。

注意：Windows 下PATH里如果同时存在多个 JDK 的 bin 目录，谁在前面谁生效，这是装环境最容易忽略的一个点。

JDK 1.8 的最后一个免费公共版本是 8u202，我一直用这个版本，稳定，也没有后续 Oracle 的授权问题。装完确认一下：

java -version # 期望输出包含 java version "1.8.0_202"

2.2 Maven 配置：镜像、仓库与编译期的依赖坑

Maven 是这个 SpringBoot 项目能否编译通过的关键。项目带了pom.xml，所有依赖都靠它拉取。Maven 版本我建议选 3.6.x，跟 JDK 1.8 配合最稳，3.9+ 虽然也能用，但对某些老插件的兼容性反而矫情。装完 Maven 后先改settings.xml，这一步不做，后面编译时下载依赖能卡到你怀疑人生。

settings.xml一般在 Maven 安装目录的conf下，我习惯把本地仓库指到一个独立盘符，再配一个国内镜像。核心配置长这样：

<localRepository>D:/maven/repository</localRepository> <mirrors> <mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror> </mirrors>

localRepository指定依赖包落盘路径，mirrorOf设成central表示中央仓库的请求全部走阿里云镜像。这一步默认不配的话，Maven 会去访问中央仓库，老项目的依赖又多又碎，网络稍微一抖就报Could not transfer artifact，然后整个编译流程卡死。配完镜像后验证一下：

mvn -version

能看到 Maven 版本号和Java version: 1.8.0_202就说明环境变量没问题。这里还有个血泪经验：如果mvn -version显示的 Java 版本不是 1.8，优先查JAVA_HOME，Maven 本身不挑 JDK，它只是把JAVA_HOME的路径透传给编译插件。

2.3 MySQL 5.7 初始化：字符集与密码策略决定后面能不能连上

数据库这块，摘要里写的是 MySQL 5.7，一句话带过，但实际安装时坑不少。MySQL 8.x 默认的密码加密方式是caching_sha2_password，而这套项目大概率用的是老驱动，不认这个加密方式，连接时报Unable to load authentication plugin。所以别贪新，老老实实装 MySQL 5.7。

Windows 上装 5.7 建议下载 zip 包手动初始化，不要用安装版——安装版会默认装成 Windows 服务、写一堆注册表，后边想换版本很麻烦。手动初始化流程：

# 解压后进入 bin 目录，执行初始化 mysqld --initialize-insecure --basedir=D:/mysql-5.7.44 --datadir=D:/mysql-5.7.44/data

--initialize-insecure表示 root 账户初始密码为空，适合本地开发，省去翻日志找随机密码的功夫。初始化完还需要手动建一个my.ini，关键几项如下：

[mysqld] basedir=D:/mysql-5.7.44 datadir=D:/mysql-5.7.44/data port=3306 character-set-server=utf8mb4 [client] default-character-set=utf8mb4

utf8mb4比utf8多支持 emoji 和生僻字，高考志愿系统里院校名称、专业名称偶尔会带特殊字符，用utf8mb4省得插入数据报Incorrect string value。配好后启动服务：

mysqld --console

另开一个窗口连进去改密码：

mysql -uroot -p ALTER USER 'root'@'localhost' IDENTIFIED BY '你的密码';

注意：5.7 的ALTER USER默认走mysql_native_password，这正是 SpringBoot 老驱动能识别的认证方式，别手动改成别的。

3. 数据库与后端启动：SpringBoot 服务是怎么一步步跑起来的

3.1 数据库导入：用 Navicat 跑 SQL 的正确姿势

源码压缩包里带 MySQL 数据库文件，一般是一个.sql脚本。我用 Navicat 导入的步骤是：新建连接填 localhost、端口 3306、用户名 root、密码填刚设置的，连接成功后右键新建数据库，库名跟脚本里的CREATE DATABASE保持一致，然后右键这个库选「运行 SQL 文件」，把脚本拖进去执行。

这里有个关键点：导入之前先确认脚本的字符集。Navicat 导入时如果识别错编码，中文全变乱码，后面页面上看到的所有院校名、专业名全是「锟斤拷」。我一般的做法是先用记事本打开.sql文件看前 20 行，找SET NAMES utf8mb4或DEFAULT CHARSET这类标记；没有的话导入时手动把编码选成 UTF-8。

导入完成后验证一下表数量和数据量：

USE 数据库名; SHOW TABLES; SELECT COUNT(*) FROM 专业表;

表名可能跟业务词不完全一致，但至少要看到用户表、专业表、院校表、录取数据表这四类核心表存在。如果COUNT(*)是 0，说明导入的数据有问题或者导错了库，趁早重来，别拖到后边启动才发现。

3.2 后端配置修改：application.yml 里的三个关键项

SpringBoot 项目的配置集中在src/main/resources/application.yml里，启动之前必须逐个核对。我整理了一份检查清单：端口、数据源、MyBatis 映射路径。这三项错一个，服务要么起不来，要么起来后接口全 500。

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/数据库名?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.jdbc.Driver

useSSL=false必须加，本机开发环境没有证书，不加会报 SSL 连接告警甚至失败。serverTimezone=Asia/Shanghai也是必须的——MySQL 5.7 的时区默认跟系统不一致，不加的话日期字段查出来会差 8 个小时，模拟志愿填报的时间戳全乱。driver-class-name有的项目写com.mysql.cj.jdbc.Driver，有的写老驱动com.mysql.jdbc.Driver，以项目里 pom.xml 的 MySQL 驱动版本为准，改错会直接ClassNotFoundException。

3.3 编译与启动：两种启动方式各自的适用场景

后端启动有两类方式：IDE 里跑和命令行跑。IDE 方式适合调试——断点、热部署都在里面，Eclipse 或 IDEA 导入 Maven 项目后直接右键SpringBootApplication主类运行。命令行方式适合部署和复现问题。

# 在项目根目录执行，先编译再启动 mvn clean package -DskipTests java -jar target/xxx.jar

clean package会清理旧产物并重新打包，-DskipTests跳过测试代码，避免测试类里连不上数据库导致打包失败。这套项目里还带了1-install.bat、2-run.bat这类脚本，本质就是上面这两条命令的封装。我习惯先用命令行跑一次，全流程走通、日志不报错之后，再进 IDE 加断点调试具体功能模块。

启动成功的标志不是控制台停住，而是日志里出现Started Application in x.xxx seconds或者 Tomcat 端口号被打印出来。看到这行字，后端才算是真正起来了。

4. 前端与爬虫：Vue 管理后台构建 + Scrapy 数据采集链路

4.1 Vue 前端依赖安装与构建：node_modules 黑洞怎么避开

前端目录在src/main/resources/admin/admin和src/main/resources/front/front下面，一个管后台管理端，一个管考生端。两者都是 Vue 项目，各自要npm install一次。前端装依赖是这套系统里最玄学的环节——同样的命令，不同 Node 版本结果可能完全不一样。

这套源码对应的 Vue 项目要看 package.json 里 vue 的版本决定 Node 版本。Vue 2.x 的老项目建议用 Node 10 或 12 这一代，Vue 3.x 可以用 Node 14 以上。我之前在 Node 18 上装一个 Vue 2 的老项目，node-sass编译直接报错，换回 Node 12 一次通过。判断项目到底是哪一代，看package.json里的"vue"字段就知道。

安装命令本身不复杂：

npm install

但执行前我建议先看一眼package.json里有没有node-sass。有的话，这个包是 Node 版本敏感度最高的依赖，它要通过 node-gyp 编译原生模块，Node 版本对不上必挂。解决方式有两种：一是切换到匹配的 Node 版本，二是把node-sass换成sass然后稍微改一下引入方式。对毕设项目来说，我建议直接换 Node 版本，改动最小。

依赖装完后的构建命令是：

npm run build

构建产物是一个dist目录，里面是纯静态文件，可以丢给 Nginx 托管，也可以让 SpringBoot 直接当静态资源加载。前端开发模式下用的是npm run dev，会起一个带热更新的开发服务器。

4.2 Scrapy 爬虫：install 与运行流程

爬虫这块用的是 Scrapy，源码包里有独立的spider目录，里面带了scrapy.cfg、安装.bat、运行.bat。Scrapy 是 Python 的框架，所以本机还得有个 Python 环境。3.7 到 3.10 之间都行，Scrapy 对 Python 版本要求不算苛刻。

安装.bat本质就是：

pip install scrapy

如果 pip 下载慢，临时切到国内源：

pip install scrapy -i https://pypi.tuna.tsinghua.edu.cn/simple

装完验证一下：

scrapy version

运行.bat对应的命令是：

scrapy crawl 爬虫名

爬虫名要去spiders目录下的具体爬虫文件里看，一般是start_urls和name属性里定义的字符串。启动后如果控制台开始刷[scrapy.core.engine]之类的日志，说明爬虫已经在跑。

这套爬虫需要单独执行，执行前确认目标数据库连接配置跟后端一致——因为爬到的院校录取数据要写进 MySQL，通常配置在 Scrapy 项目的pipelines.py或者settings.py里。它的数据源是对公开放出的教育类录取数据站点，采集的是历年分数线这类公开内容。

4.3 前后端联调：跨域与端口配置

后端起在8080，前端开发服务器默认起在9527之类的端口。两个端口不一样，浏览器就会报跨域错误，页面能打开但接口全红。处理方式两种：一是后端加@CrossOrigin或者全局 CORS 配置，二是前端开发环境配代理转发。

老 Vue 项目一般通过config/index.js里的proxyTable做代理：

proxyTable: { '/api': { target: 'http://localhost:8080', changeOrigin: true } }

这段配置的意思是：前端发出的所有/api开头请求，都由开发服务器转发到8080端口的后端服务。changeOrigin: true保证请求头里的 Host 被替换成目标地址，不然部分后端框架会拒绝非本机来源的请求。

后端那边如果自己写了 CORS 配置，注意别跟前端代理同时开——双份跨域处理偶发冲突，表现是请求能到后端但响应被浏览器拦了，肉眼极难排查。我一般选前端代理这条路，后端少碰配置。

5. 常见问题排查：启动失败的 5 个高频坑与解决记录

5.1 端口被占用导致后端起不来

现象：启动 SpringBoot 时日志报Web server failed to start. Port 8080 was already in use，或者直接抛BindException。

原因：本机其他进程占用了 8080 端口，常见的有微信开发者工具、本地 Tomcat、另一个 SpringBoot 进程。

解决：先查谁占用了端口，再决定杀进程还是换端口。

netstat -ano | findstr 8080 taskkill /PID 进程号 /F

如果是想换端口，直接改application.yml里的server.port，但要注意前端代理配置里的target端口同步改掉，否则前端转发还是打到旧端口。

5.2 MySQL 5.7 密码认证方式引发连接失败

现象：后端启动日志报Access denied for user 'root'@'localhost'，但 Navicat 用同样的账号密码连得好好的。

原因：Navicat 和 JDBC 驱动走不同的认证流程。常见场景是用户密码里带了@、#这种特殊字符，在application.yml里被解析出错；或者密码确实是错的，Navicat 记住了历史密码。

解决：先排除特殊字符问题——密码里的特殊字符在 YAML 里要用引号包起来，比如password: "abc@123"。确认无误后，用命令行手动验证：

mysql -uroot -p你的密码 -e "SELECT 1"

能执行成功说明认证没问题，问题在配置解析上；执行失败说明密码就是不对，回 MySQL 里重置。

5.3 Maven 依赖下载卡住或编译失败

现象：执行mvn clean package时卡在Downloading...半小时不动，或者报Could not resolve dependencies，某个jar显示Last updated时间很久远。

原因：默认走了中央仓库，网络延迟高；或者某个依赖版本在镜像里没有缓存。

解决：检查settings.xml里的镜像配置是否生效。确认方式：

mvn help:effective-settings

这个命令会打印实际生效的 settings 内容，能看到<mirrorOf>是否真的指到了阿里云镜像。如果镜像配置没问题但某个包还是拉不下来，去仓库目录把这个包的.lastUpdated后缀文件删掉，再重新编译。Maven 默认不重试失败的下载，不删这个文件会一直报同样的错。

5.4 前端 npm install 报错或 build 失败

现象：npm install时报node-gyp rebuild失败，或者npm run build时内存溢出，日志尾部是JS stack trace。

原因：依赖里有需要编译原生模块的包（还是 node-sass 的问题），Node 版本不匹配；构建时 Webpack 内存不够则是 Node 默认堆大小限制。

解决：Node 版本不对就换版本，这是最省事的路径。换完版本后先删掉已有的node_modules再重装，避免旧包残留：

rm -rf node_modules package-lock.json npm install

如果是构建内存溢出，单独调大 Node 堆内存：

npm run build --max_old_space_size=4096

5.5 Scrapy 爬虫能启动但采集不到数据

现象：scrapy crawl启动后日志刷了一堆，翻页也正常，但数据库里一条新数据都没写入。

原因：最常出在数据库写入管道上——数据库表结构跟 Scrapy item 字段对不上，或者数据库连接配置用的还是默认的 SQLite，数据被写进了本地.db文件而不是 MySQL。

解决：先看 Scrapy 项目的settings.py里的ITEM_PIPELINES配置，确认启用了哪个管道类；再打开对应的pipelines.py看里面连的是什么数据库。如果连的是 MySQL，检查host、user、password、db四项是否跟后端application.yml一致。改完后重启爬虫，看日志里有没有出现Item stored之类的成功标记。

6. 装完怎么验证跑通：功能级自测清单与数据链路验证

环境全部装好、服务都能启动之后，别急着截图交差，先按业务主链路把功能过一遍。我一般按「数据 → 接口 → 页面」三层验证，顺序不能反，底层数据有问题，上层页面再好看也是假跑通。

第一层验证数据完整性。登录 MySQL 服务，确认爬虫采集的数据已经落库。查看录取数据表的记录数：

SELECT COUNT(*) FROM 录取数据表; SELECT COUNT(*) FROM 专业表; SELECT COUNT(*) FROM 院校表;

三个表的数量级应该跟正常业务量匹配，如果全是 0，后边的推荐匹配就是空转。

第二层验证后端接口。打开浏览器直接访问几个关键接口路径，确认返回 JSON 而不是 404 或 500。比如：

http://localhost:8080/api/专业查询接口?keyword=计算机

接口返回正常 JSON 数组就算通过。这一步我发现很多人跳过，直接在页面上点点点，结果接口报错被浏览器控制台吞了，还以为是前端渲染问题。

第三层验证页面功能。用考生账号走一遍核心链路：注册登录 → 查询专业和院校 → 做一次 MBTI 职业性格测试 → 进入模拟志愿填报 → 添加几个志愿 → 查看推荐结果。后台管理端也值得花十分钟过一遍：用管理员账号登录，确认专业管理、院校管理、位次管理这几个菜单能打开、能编辑、能保存。

数据链路验证还有一个技巧：看推荐结果是否正确关联了历史录取数据。模拟填报后，推荐列表里应该能看到院校的历年分数线信息——这些数据来自爬虫采集。如果推荐列表有院校但分数线全是空的，说明爬虫采集的年份字段没对接到推荐逻辑上，要回溯检查爬虫数据字段的映射。

从那以后我每次拿到老项目源码，都强制自己先走一遍这条链路：查 JDK 版本、确认数据库认证方式、编译一次后端、构建一次前端、跑一个爬虫任务、最后点一遍关键页面。六个环节全绿才敢说「跑通了」。希望这篇笔记能帮到你，少走我走过的这些弯路。

本文还有配套的精品资源，点击获取