简介：面向Java毕业设计与课程设计的考研咨询网站系统完整交付包，基于SpringBoot与MySQL开发，覆盖学生前台、管理员后台、学生后台三大端口，适合需要整体方案与可运行源码的开发者参考。压缩包共1806个文件，约94.26MB，包含Java源码、Vue页面、JS脚本、Class编译文件、SQL数据脚本，以及开发说明文档、LW论文、PPT和演示视频，整体结构清晰。系统实现考研资讯、报考指南、资料信息、论坛交流、购物车、客服等前台功能，后台支持资讯管理、学生管理、资料分类、论坛管理、订单管理等业务模块，业务链路完整。压缩包内附1-install.bat与2-run.bat启动脚本，配合文档可快速完成环境配置与部署。目前已有64人学习下载，适合正在开展毕业设计或课程设计的学生直接使用。
1. 基于 SpringBoot 的考研咨询网站，源码包里先看哪三样东西
一个考研学生想确认某校往年的复试线，经常要在官网、论坛、公众号之间来回切换才有结论。基于 SpringBoot 的考研咨询网站系统把这类信息收拢成「院校库 + 在线咨询」两个闭环：学生查学校、查专业，有问题就提交咨询，管理员在后台回复，全程留痕。毕业设计选这个方向，正好把 SpringBoot 的自动配置、MyBatis-Plus 条件查询、登录拦截、事务和部署都串起来，难度适中，演示效果又直观。源码包里真正决定能不能跑起来的，往往不是那几百个 .java 文件，而是数据脚本、表结构和配置文件这三样。刚学完 java 基础的人，按下面顺序从表开始读，很快能对上大部分代码。
2. 考研咨询系统的数据脚本：库表设计从建表 SQL 到自动初始化
2.1 用户、院校、咨询：三类核心实体的表结构怎么定
数据脚本目录里通常会有schema.sql（建表）和data.sql（初始数据），有些压缩包会把两张表合到一个init.sql里。这套系统的表不多，一般落在 8 张以内，核心其实只有三类：账号、院校、咨询。把这三张表拆清楚，整个系统的数据流也就清楚了。
毕业设计里的表名通常不太统一，有的叫school，有的叫school_info。我下面的写法按school_info举例，实际以压缩包schema.sql为准，注意两处保持一致。实体层的@TableName和 XML 里的表名都要跟随数据脚本，这是「改完一个文件就启动报错」最常见的原因。
2.1.1 院校与专业属于典型的“主表 + 子表”
院校本身是一张主表，专业是它的子表。一个学校对应多个专业，所以专业表里必须有school_id作为外键字段，再加一个联合唯一键防止重复插入。
CREATE TABLE IF NOT EXISTS `school_info` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `name` VARCHAR(128) NOT NULL COMMENT '院校名称', `province` VARCHAR(32) NOT NULL COMMENT '所在省份', `city` VARCHAR(32) DEFAULT NULL COMMENT '所在城市', `school_type` VARCHAR(16) NOT NULL DEFAULT '普通' COMMENT '985/211/双一流/普通', `view_count` INT NOT NULL DEFAULT 0 COMMENT '浏览热度，排序用', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_province_type` (`province`, `school_type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='院校信息表';这段 SQL 里有几个值得留意的参数。school_type用定长 VARCHAR(16) 而不是 TINYINT，是因为这类枚举值后期会加「双一流」之外的分类，直接存中文可读性更好，也方便管理后台直接编辑，代价是多占几个字节，对毕设体量毫无压力。联合索引idx_province_type覆盖「按省份筛 985/211」这个高频查询，数据量过万时效果很明显。create_time用DEFAULT CURRENT_TIMESTAMP而不是在 Java 里手动 set，减少一层业务代码。
专业子表的写法类似，核心是uk_school_major(school_id, major_name)这个唯一键。没有它，数据脚本重复执行一次，同校同专业就会插出两行。
2.1.2 咨询记录用一行状态字段代替流程表
咨询业务看起来像一个流程：用户提问、管理员回复、用户追问、关闭。如果为此引入 Flowable 或 Activiti 这类工作流引擎，学习成本和部署复杂度都会立刻失控。毕设场景下，一张表加一个status字段就够了，后续给状态升级留好空间即可。
CREATE TABLE IF NOT EXISTS `consultation` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `user_id` BIGINT UNSIGNED NOT NULL COMMENT '提问学生', `type` TINYINT NOT NULL DEFAULT 0 COMMENT '0 择校 1 专业 2 复试', `content` VARCHAR(1000) NOT NULL COMMENT '提问内容', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0 待回复 1 已回复 2 已关闭', `answer` VARCHAR(2000) DEFAULT NULL COMMENT '管理员回复', `answer_admin_id` BIGINT UNSIGNED DEFAULT NULL COMMENT '回复人', `answer_time` DATETIME DEFAULT NULL COMMENT '回复时间', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_time` (`user_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='咨询记录表';status用数字而不是字符串的好处是排序和比较都便宜，坏处是代码里不能频繁写魔法数字，前后端约定一个枚举或者常量类。content上限 1000、answer上限 2000，这是针对「顶多几百字」的真实场景做的约束，避免了 TEXT 类型带来的额外存储和排序限制。
三张核心表的职责可以归纳成下面这个对照：
| 表名 | 职责 | 关键字段 | 与其他表的关系 |
|---|---|---|---|
| user_info | 学生与管理员账号 | username, password, role | role 为 0 学生、1 管理员 |
| school_info | 院校基本资料 | name, province, school_type | 与 major 子表一对多 |
| consultation | 用户提问到回复的完整记录 | user_id, status, answer | 通过 user_id 关联 user_info |
2.2 数据脚本的两种导入方式与重复执行问题
拿到源码后第一件事不是启动项目，而是先把表建出来。很多人直接mvn spring-boot:run，控制台报Table 'xxx doesn't exist，才开始回头找 SQL 文件，这一步完全可以省掉。
2.2.1 手动 source，再让 SpringBoot 接管初始化
先手动建库导数据，是和 SpringBoot 的自动初始化互补的做法。手动方式适合第一次跑通，确定脚本本身没有语法错误：
mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS kaoyan DEFAULT CHARSET utf8mb4;" mysql -uroot -p kaoyan < db/schema.sql mysql -uroot -p kaoyan < db/data.sql-p后面不直接跟密码是基本习惯，因为明文密码会出现在 shell 历史里。如果data.sql里初始化了管理员账号，记得后面登录后台用的是这里面的用户名和 BCrypt 加密后的密码，不是让你去注册页面重新注册一个管理员。
SpringBoot 本身也提供了初始化入口，2.5 之后的配置在 yml 里写spring.sql.init.*，这一组配置对应「启动时自动执行指定 SQL 文件」的能力：
spring: datasource: url: jdbc:mysql://localhost:3306/kaoyan?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&createDatabaseIfNotExist=true sql: init: mode: always schema-locations: classpath:db/schema.sql >@Data @TableName("school_info") public class SchoolInfo { @TableId(type = IdType.AUTO) private Long id; private String name; private String province; private String city; @TableField("school_type") private String schoolType; private Integer viewCount; }三个容易出问题的点。第一，表名必须和实体上的@TableName一致，数据脚本里叫school_info，实体写@TableName("school")必然 404 或 SQL 报错。第二，school_type这种下划线字段在 mapUnderscoreToCamelCase 开满时可以不写@TableField，但如果全局配置没开，就必须手动写清楚。第三，createTime这类字段如果依赖 MyBatis-Plus 自动填充，还要配置MetaObjectHandler，很多毕设项目省了这一步，插入后时间字段全是 null，只能靠数据库默认值兜底。
这一类问题在追流程时会频繁出现。把 MyBatis 源码里MapperMethod的 execute 分支翻出来看，会发现所有注解 SQL、XML SQL、条件构造器生成的 SQL，最后都走同一条SqlSession通路。想明白这一点，调试条件构造器就不会只停留在「换个方法试试」的层面。
3.2 写一个能直接跑的分页模糊查询接口
院校列表页是这套系统的主入口，功能点就两个：分页、按关键词模糊搜。以下代码可以原样抄进工程，替换掉 Service 里的空实现。
3.2.1 Controller 层：查询对象收参 + 参数上限
@RestController @RequestMapping("/api/schools") public class SchoolController { private final SchoolInfoService schoolInfoService; public SchoolController(SchoolInfoService schoolInfoService) { this.schoolInfoService = schoolInfoService; } @GetMapping public Result<Page<SchoolInfoVO>> page(SchoolQuery query) { if (query.getCurrent() == null) { query.setCurrent(1); } if (query.getSize() == null || query.getSize() > 50) { query.setSize(10); } Page<SchoolInfo> page = new Page<>(query.getCurrent(), query.getSize()); String keyword = query.getKeyword(); LambdaQueryWrapper<SchoolInfo> wrapper = new LambdaQueryWrapper<>(); wrapper.and(StringUtils.hasText(keyword), w -> w .like(SchoolInfo::getName, keyword) .or().like(SchoolInfo::getProvince, keyword) .or().like(SchoolInfo::getSchoolType, keyword)) .eq(StringUtils.hasText(query.getProvince()), SchoolInfo::getProvince, query.getProvince()) .orderByDesc(SchoolInfo::getViewCount); Page<SchoolInfo> result = schoolInfoService.page(page, wrapper); return Result.ok(result.convert(this::toVO)); } }前端传?current=1&size=10&keyword=北京&province=北京时，SpringMVC 会自动把 query string 绑定到SchoolQuery对象。size上限 50 是保护性约束，防止传一个超大分页值把数据库拖垮。Result是统一返回包装，前端拿到{ "code": 200, "data": { "records": [], "total": 100 } }后，用total算总页数，records渲染列表。
3.2.2 Service 层：条件构造器里的 and/or 优先级
上面的 wrapper 用and(condition, consumer)把所有模糊条件包进一对括号里，拼出来的 WHERE 长这样：
WHERE (name LIKE ? OR province LIKE ? OR school_type LIKE ?) AND province = ? ORDER BY view_count DESC如果少了外层wrapper.and(...)，直接在wrapper级联写三个like().or().like()，再跟一个.eq()，拼出的 SQL 会变成(name LIKE ? OR province LIKE ? OR school_type LIKE ? AND province = ?)，OR 的优先级低于 AND，导致「北京 + 985」这类组合过滤失效，把不属于该省份的学校也捞出来。这就是 MyBatis-Plus 条件构造器最经典的优先级坑，场景越复杂出现概率越高。
分页参数这块可以整理成一张表，方便对接口时对照：
| 参数 | 默认值 | 约束 | 对应 SQL 片段 |
|---|---|---|---|
| current | 1 | 从 1 开始 | LIMIT offset, size |
| size | 10 | 最大 50 | LIMIT offset, size |
| keyword | 空 | 可空，空时不过滤 | LIKE '%keyword%' |
| province | 空 | 可空 | province = ? |
3.3 登录后才能用的接口：@RequireLogin 拦截器最小实现
咨询必须登录后才能提交，后台回复必须管理员才能操作。最省事的鉴权方案是自定义一个注解加一个拦截器，而不是在每个 Controller 里手动判断 session。
3.3.1 拦截器判断注解而不是判断路径
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod = (HandlerMethod) handler; RequireLogin login = handlerMethod.getMethodAnnotation(RequireLogin.class); if (login == null && handlerMethod.getBeanType() .getAnnotation(RequireLogin.class) == null) { return true; } String token = request.getHeader("Authorization"); LoginUser user = tokenService.parseToken(token); if (user == null) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); return false; } UserContextHolder.set(user); return true; } }按注解判断而不是按路径判断的好处是，加新接口时不需要同步维护拦截器白名单，没有@RequireLogin的接口天然匿名可访问。Swagger、静态资源这些本来就不带业务注解，不会被误拦，省掉一长串 excludePathPatterns。这里的handler instanceof HandlerMethod判断是为了放行静态资源映射，否则静态资源请求走到这里会直接转失败。
3.3.2 ThreadLocal 用户上下文与请求结束清理
登录用户不能每个方法都手动传参，常见做法是放进 ThreadLocal，再封装一个静态工具类取用。
public class UserContextHolder { private static final ThreadLocal<LoginUser> HOLDER = new ThreadLocal<>(); public static void set(LoginUser user) { HOLDER.set(user); } public static LoginUser get() { return HOLDER.get(); } public static void clear() { HOLDER.remove(); } }拦截器里afterCompletion中必须调用UserContextHolder.clear()。Tomcat 的工作线程是池化复用的，线程处理完 A 请求后不清理 ThreadLocal，B 请求复用同一线程时会读到 A 的用户信息，这就是「请求串号」的根因。这个点也是 java 面试题里的高频考点，从 ThreadLocal 的内存泄漏讲到弱引用回收，都能接得上。
4. 考研咨询的问答闭环：提交、后台回复与状态流转
4.1 状态字段驱动流转，为什么不用工作流引擎
咨询的状态在整个系统里只需要三个：待回复、已回复、已关闭。用工作流引擎来处理三态流转，是把简单问题复杂化的典型。status字段加上 Service 层的校验，就足以覆盖所有合法路径。
| status | 含义 | 可执行操作 | 操作后状态 |
|---|---|---|---|
| 0 | 待回复 | 管理员回复 / 关闭 | 1 或 2 |
| 1 | 已回复 | 用户追问 | 回到 0 |
| 2 | 已关闭 | 无 | 无 |
用户追问回到 0 的原因是，一次咨询代表一个上下文。学生问「这个专业复试线多少」，管理员回复后，如果学生还要问「报录比呢」，此时新建一条记录会把上下文拆散，而回到待回复状态能保持对话的连贯性。毕设答辩时，这个设计比一贴到底的留言板要完整得多。
4.2 提交咨询与后台回复的 Transactional 实现
提交咨询是最常见的写入接口，逻辑上就是组装一条记录后保存。回复操作则涉及状态校验和更新，不能允许「对一条已回复的咨询再次回复」造成数据覆盖。
@Transactional public void answer(Long consultationId, String answer, Long adminId) { Consultation item = consultationService.getById(consultationId); if (item == null || item.getStatus() == 2) { throw new BizException("咨询不存在或已关闭"); } if (item.getStatus() == 1) { throw new BizException("该咨询已回复，如需修改请先撤回"); } item.setAnswer(answer); item.setStatus(1); item.setAnswerTime(LocalDateTime.now()); item.setAnswerAdminId(adminId); consultationService.updateById(item); notifyService.sendToUser(item); }@Transactional放在 service 方法上而不是 Controller 上，是为了保证「更新咨询 + 发通知」要么都成功，要么都失败。默认只对RuntimeException回滚，BizException如果继承了 RuntimeException，就能被正确感知。需要注意，同一个类里另一个方法直接this.answer()调进来，事务是不会生效的，因为 Spring 的 AOP 代理拦截不了内部自调用。很多人在这里栽过，排查事务为什么没回滚时，先检查是不是被自调用绕过了。
并发场景下，两个管理员同时打开同一条待回复咨询，又同时点回复，会出现后写覆盖先写。毕设项目可以在实体上加乐观锁字段：
@Version private Integer version;加上@Version后，MyBatis-Plus 生成的 UPDATE 会带上version = 旧值条件，第二个管理员更新时影响行数为 0，可以在代码里识别并提示「该咨询已被其他人回复」。注意不要把@Version和逻辑删除的@TableLogic混用，效果完全不同，一个是控制更新条件，一个是控制删除行为。
4.3 用 Redis 做今日咨询量统计时的一次序列化报错
咨询模块通常要顺手统计「今日咨询量」，用 Redis 计数器是最直接的方式：
String key = "consult:today:" + LocalDate.now(); Long count = stringRedisTemplate.opsForValue().increment(key);这段代码在单独使用StringRedisTemplate时没有任何问题。但毕设项目往往同时注入了RedisTemplate<String, Object>做缓存，问题就从这里冒出来。StringRedisTemplate的 key 和 value 都用 String 序列化，存进 Redis 的是裸字符串"1"；而默认的RedisTemplate用的是 JDK 序列化，key 和 value 前面都带一串\xAC\xED二进制头。两个 template 混用同一个 key，increment读到一个带序列化头或者带类型信息的 value，直接抛ERR value is not an integer or out of range。
| 现象 | 根因 | 处理方式 |
|---|---|---|
| increment 报 not an integer | value 被 JDK/JSON 序列化 | 统一用 StringRedisTemplate |
| 用另一个 template 读不到 key | key 的字节序列不同 | 切 Redis 可视化工具确认实际 key |
| 数字看起来带引号 | 写入了 JSON 字符串 | 改用 StringRedisSerializer |
这类报错和 Redis 本身无关，Redis 只是忠实执行了「对一个非数字文本做自增」。排查方向应该是项目里到底用了几种 RedisTemplate，以及它们是否共用了同一个 key。统一用StringRedisTemplate后，再给计数器加一个过期时间，就能避免手动清零：
stringRedisTemplate.expire(key, Duration.ofDays(1));到时间自动过期，第二天重新从 0 开始，演示当天本来就是完整的。这个设计比写定时任务清零简单得多，也少一条定时任务的部署依赖。
5. 不靠演示视频也能跑起来：启动顺序、打包部署与三个高频报错
5.1 本地启动前，先按这四步走
演示视频只能证明这套系统曾经跑通过，你的机器上要从零跑通，建议固定执行这个顺序：
# 1. 解压后先看 db 目录下的脚本和 application.yml 里的库名 mysql -uroot -p < db/schema.sql mysql -uroot -p < db/data.sql # 2. 编译并跳过测试，避免测试用例连不上数据库 mvn clean package -DskipTests # 3. 启动，观察日志是否出现 Tomcat started java -jar target/kaoyan-learning-0.0.1-SNAPSHOT.jar # 4. 用 curl 验证接口 curl "http://localhost:8080/api/schools?current=1&size=3"clean是必须的，不然上次编译的旧 class 可能和新改的表结构不一致。-DskipTests跳过的是测试执行，不是编译，测试类本身还是会编过。如果 yml 里配置了spring.sql.init.mode=always，数据库里已经手动导过数据，就可能出现重复执行，此时把模式改成never，只保留手动脚本即可。
5.2 打包成 jar 部署到云主机的最小命令
实测最省事的部署方式是单 jar + 外置配置，项目打出来 jar 后传到服务器：
scp target/kaoyan-learning-0.0.1-SNAPSHOT.jar root@your-server:/opt/app/ ssh root@your-server cd /opt/app nohup java -Xms256m -Xmx512m -jar kaoyan-learning-0.0.1-SNAPSHOT.jar \ --spring.profiles.active=prod > app.log 2>&1 &-Xms和-Xmx都设成 512m 以内，是因为便宜的云主机通常是 2G 内存起步，给 JVM 分配过大会拖垮整机。--spring.profiles.active=prod切换 prod 环境的数据库连接，不要在命令行里直接拼数据库密码，密码留在application-prod.yml里即可。如果想让密码不被一眼看穿，至少做一轮 Jasypt 加密，数据源配置只保留密文。
检查进程用jps -l，查看日志用tail -f app.log，看到Started ... in N seconds再访问 8080 端口。端口被占时用lsof -i:8080找到进程号后 kill，别反复重启碰运气。
5.3 三个高频启动报错与定位手段
| 报错现场 | 原因 | 处理方式 |
|---|---|---|
Tomcat started on port(s): 8080后几秒自己退掉 | 端口被其它进程占用，或循环依赖 | lsof -i:8080看占用，再查启动日志里 Caused by |
Communications link failure | application.yml 里数据库地址、账号或密码写错 | 检查 url 的 host、port、库名，再用 mysql 命令手动连一次 |
Table 'kaoyan.consultation' doesn't exist | 数据脚本没执行，或实体 @TableName 与表名不一致 | 先确认 schema.sql 建表成功，再对比实体注解 |
SpringBoot 版本和 JDK 版本不匹配也是这一两年常见的新坑。2.7.x 对应 JDK 8/11，3.x 要求 JDK 17 起步。如果本地默认 JDK 是 17 却用 2.7 构建，启动时大概率出现IllegalStateException或 class 版本错误，检查java -version和 pom 里的spring-boot-starter-parent版本号就能定位。这类报错十有八九都能在日志前二十行里找到根因，按上面的表格对照一遍再动手改代码，效率比猜配置高得多。
本文还有配套的精品资源，点击获取
