SpringBoot+Vue宿舍管理系统实战：从数据库设计到前后端部署全攻略

做过几个宿舍管理类的项目之后，我最大的感受是：这类系统看起来简单，无非是学生、宿舍、报修、公告那几张表，但真正动手写起来，从数据库设计到前后端联调，再到部署上线，坑一点都不少。特别是最近几年SpringBoot版本迭代快，老教程还在用2.3，新项目一上来就是3.x，JDK版本一变，很多老写法直接跑不起来。这篇就把我基于SpringBoot + Vue + MyBatis + MySQL做学生宿舍信息管理系统的完整思路、核心代码和排查经验整理出来，给正在做课程设计、毕业设计或练手项目的朋友一个可以直接参考的模板。

先说清楚这套系统能做什么。它主要解决宿舍管理中最常见的几件事：学生信息的维护、宿舍资源的分配与调换、入住和退宿的流程管理、宿舍报修的处理，以及公告通知的发布。前端用Vue负责页面交互，后端用SpringBoot提供接口，MyBatis负责数据库操作，MySQL存数据。整体结构属于典型的前后端分离项目，既有完整的CRUD流程，又包含关联查询、事务处理、权限拦截这些企业级开发的基础能力。适合有一定Java和前端基础、想完整走一遍全栈流程的人，也适合需要快速出一套可演示项目的学生。

1. 技术选型：为什么是SpringBoot + Vue，版本怎么搭才不会翻车

1.1 前后端分离的选型逻辑

先聊选型。宿舍管理系统这种业务，用传统的JSP + Servlet能做，用Thymeleaf服务端渲染也能做，但我现在更推荐前后端分离。原因很简单：业务边界清晰，前端只负责渲染和数据交互，后端只负责接口和数据处理，两边可以并行开发，也方便后面扩展移动端。比如你以后想加一个小程序端，后端接口基本不用动，直接用现有API就行。

在这个体系里，SpringBoot承担的是接口服务端。它帮我们把Spring的配置自动化了，以前SSH时代要写一堆XML配置，现在一个application.yml加几个注解就搞定。MyBatis在这里负责持久层，它比Spring Data JPA更灵活，SQL可以自己掌控，尤其是宿舍管理这种涉及多表关联、条件统计的业务，手写SQL反而更好调优。MySQL则承担数据存储，轻量、稳定、用的人多，遇到问题一搜就有答案。

Vue作为前端框架，最大的优势是组件化和响应式。宿舍管理页面里有很多表单、弹窗、表格，用Vue的组件化开发能把每个功能模块拆得很干净，维护起来比jQuery时代一把梭舒服太多。

1.2 版本匹配：SpringBoot版本太高真的会出事

这几年帮人看项目，发现一个高频问题：SpringBoot版本太高。很多新手在创建项目时直接选最新稳定版，结果JDK版本跟不上，一堆依赖报错。这里我直接给出目前最稳的组合方案。

对于学生宿舍管理系统这种体量的项目，我的推荐是：SpringBoot 2.7.x + JDK 8，或者SpringBoot 3.x + JDK 17。这两个组合是经过大量项目验证的，千万别跨版本乱配。

这里要多说一句：SpringBoot 3.x之后，原来用的 javax.servlet、javax.persistence 这些包名全部换成了 jakarta.*，如果你在3.x项目里还写 import javax.servlet.http.HttpServletRequest，代码直接编译不过。另外，SpringBoot 3.x最低要求JDK 17，如果你的电脑只装了JDK 8，就别硬上3.x，老老实实用2.7.x。

1.3 环境准备：从零开始把项目跑起来

如果你是从零开始搭环境，按照这个顺序来：先装JDK，再装Maven，然后装MySQL，最后装Node.js。别反过来，因为SpringBoot项目启动依赖Java和Maven，前端构建依赖Node。

JDK安装比较基础，但有一点要提醒：装完之后一定要配环境变量JAVA_HOME和PATH。很多新手在命令行敲 java -version 能出来版本号，但Maven打包时却报找不到JDK，这就是JAVA_HOME没配好。

MySQL 8.0的安装建议直接去官网下载MySQL Installer，Windows下用图形化安装器最省心。安装时记得选对字符集，推荐utf8mb4，这个字符集能完整支持中文和emoji，避免日后的乱码问题。安装完之后用命令行或者MySQL Workbench验证一下连接，确认能连上再继续。

Node.js的安装要注意版本。Vue 3的项目建议Node 16以上，如果你要开Vite开发服务器，Node版本太低会直接报错。装完Node之后，npm会自带，建议再装一个yarn或pnpm，后面拉依赖会快一些。

另外有个小乐趣：SpringBoot启动时那个Banner可以自定义。网上有SpringBoot Banner在线生成器，把ASCII艺术字生成后放到 src/main/resources/banner.txt 里，启动项目时就会显示你自己的图标，面试或答辩时这个小细节还是挺加分的。

2. 数据库设计：先把宿舍管理这件事想清楚再动手

2.1 核心业务表结构与关系

很多初学者拿到需求就急着写代码，写到一半发现表结构缺字段，又回去改，很浪费时间。宿舍管理系统的业务其实非常固定，核心是“人”和“房”的对应关系。

基础表大致有这些：学生表（student）、宿舍表（dormitory）、宿舍楼表（building）、入住记录表（check_in）、报修表（repair）、公告表（notice）。如果涉及管理员和权限，再加一张用户表（user）和角色表（role）。

先看宿舍楼和宿舍的关系。一栋楼有多个房间，所以building和dormitory是一对多。每个宿舍有床位数量、已住人数、宿舍类型（比如4人间、6人间）、设施信息（空调、独卫等）。当已住人数等于床位数量时，这个宿舍就不可再分配了。

学生和宿舍的关系则通过入住记录表来维护。为什么不直接把宿舍ID写进学生表？因为学生可能中途换宿舍，或者毕业退宿，直接在学生表上改字段会丢失历史数据。有了入住记录表，每次入住和退宿都是一条记录，后面统计换宿次数、查历史入住情况都方便。

我给的参考表结构如下：

sql复制CREATE TABLE `student` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `student_no` varchar(20) NOT NULL COMMENT '学号',
  `name` varchar(50) NOT NULL COMMENT '姓名',
  `gender` tinyint DEFAULT NULL COMMENT '性别：1男 0女',
  `phone` varchar(20) DEFAULT NULL,
  `college` varchar(100) DEFAULT NULL COMMENT '学院',
  `major` varchar(100) DEFAULT NULL COMMENT '专业',
  `status` tinyint DEFAULT '0' COMMENT '状态：0在住 1离校',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_student_no` (`student_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

sql复制CREATE TABLE `dormitory` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `building_id` bigint NOT NULL COMMENT '所属楼栋ID',
  `room_no` varchar(20) NOT NULL COMMENT '宿舍号',
  `beds` int NOT NULL COMMENT '床位数',
  `occupied` int DEFAULT '0' COMMENT '已住人数',
  `type` tinyint DEFAULT '1' COMMENT '类型：1四人间 2六人间',
  `status` tinyint DEFAULT '1' COMMENT '状态：1可用 0停用',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_room` (`building_id`, `room_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.2 状态字段的设计：别用业务逻辑里的硬编码

在设计表时，我习惯把所有“状态”用整型字段表示，并且在代码里定义常量或者枚举。比如学生状态只取0和1，管理员登录的状态、宿舍状态、报修状态都是这样。好处是查询效率高、对比方便，前端渲染时再通过字典翻译成中文。

这里有一个比较隐蔽的设计点：入住记录表建议加一个状态字段，比如 status 为0表示在住，1表示已退宿。很多人在查询“某个宿舍当前住了哪些人”时直接去学生表里找宿舍ID，但前面说过这样会丢历史数据。更合理的做法是通过入住记录表查询当前状态为“在住”的记录，再关联学生表取基本信息。这样做有个额外好处：以后统计退宿人次、按时间段查入住流水，都有据可依。

2.3 数据库维护中的几个常见问题

搜索关键词里很多人关心MySQL的update语法、存储过程、int+5这类问题，我在做这个项目时也确实踩过几个相关的坑。

第一个是update语句的坑。比如我写一个把宿舍已住人数加1的SQL，新手容易写成 UPDATE dormitory SET occupied = occupied + 1 WHERE id = 1，这个写法本身没问题。但如果要限制“不能超过床位数”，就会写成：

sql复制UPDATE dormitory 
SET occupied = occupied + 1 
WHERE id = 1 AND occupied < beds;

这里有个关键点：affected rows返回0时，说明update没有命中条件，也就是宿舍已经满了，需要在业务层判断。这个技巧在并发抢宿舍的场景下特别有用，比先查再更新更安全。

第二个是MySQL关键词冲突。比如字段名叫type、key、order，在一些方言里虽然能用MySQL执行，但作为表字段名很容易埋雷。建议所有字段命名时避开MySQL保留字，如果实在要保留，写SQL时用反引号包起来，比如 type_name 就比 type 更稳妥。

第三个是关于存储过程。有人说宿舍管理系统用存储过程做分配逻辑，我不太建议。MySQL的存储过程调试不方便，版本兼容性也一般，这类业务逻辑放到Java的Service层里处理，事务管理更清晰，代码也更容易测试和维护。存储过程适合处理特别复杂的统计报表逻辑，但在这种规模的项目里属于过度设计。

3. 后端核心代码落地：从Mapper到接口的完整实现

3.1 项目结构化分与依赖配置

后端项目我习惯按功能模块分包，而不是按技术层分包。也就是说，不要建一堆controller、service、mapper包然后把所有文件丢进去，而是每一个业务模块建一个子包，里面放自己专属的Controller、Service、Mapper。比如 student 包下面有 StudentController、StudentService、StudentMapper，这样找代码、加功能都直观很多。

一个标准的SpringBoot项目结构大概长这样：

code复制src/main/java/com/example/dormitory/
├── config/          // 配置类：跨域、拦截器、MyBatis配置等
├── controller/      // 接口层
├── service/         // 业务层，接口+impl
├── mapper/          // MyBatis的Mapper接口
├── entity/          // 数据库实体类
├── vo/              // 前端交互的数据对象
├── common/          // 通用类：统一返回、异常处理、工具类
└── DormitoryApplication.java

依赖文件的配置是第一步。在 pom.xml 里，核心依赖只有几个：spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-j。如果你选了SpringBoot 3.x，注意MySQL驱动依赖的groupId会有变化，8.0以上的驱动是 com.mysql:mysql-connector-j。

另外要提醒一个点：数据库连接池。SpringBoot 2.x默认连接池是HikariCP，性能很好，不需要额外引Druid。如果你是为了看监控SQL方便，可以用Druid Spring Boot Starter。我平时排查问题更喜欢直接用MyBatis的日志输出，后面会讲。

3.2 MyBatis配置与Mapper实现：动态SQL是精华

MyBatis是这套系统里最核心的持久层框架。先看配置文件，在application.yml里要做几件事：数据库连接信息、MyBatis的驼峰映射、日志打印SQL。

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/dormitory?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.dormitory.entity
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

第3个配置 map-underscore-to-camel-case 要留意，它可以把数据库字段 create_time 自动映射到实体类的 createTime，不用每张表都写一堆resultMap。第4个配置 StdOutImpl 就是打印SQL日志的关键，开发阶段开着，SQL执行情况一目了然。

Mapper层可以用注解写SQL，但我更推荐XML文件方式，因为动态SQL在XML里写起来最顺手。比如学生列表查询往往需要按姓名、学号、学院做条件筛选，这三个条件又都是可选的，这时候动态SQL就派上用场了。

xml复制<select id="listStudents" resultType="com.example.dormitory.entity.Student">
    SELECT * FROM student
    <where>
        <if test="name != null and name != ''">
            AND name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="studentNo != null and studentNo != ''">
            AND student_no = #{studentNo}
        </if>
        <if test="college != null and college != ''">
            AND college = #{college}
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
    </where>
    ORDER BY create_time DESC
</select>

<where> 标签最大的好处是它会自动处理第一个AND关键字。如果你手动写 WHERE 1=1 也能实现，但不够优雅，而且有SQL注入风险的口碑问题会困扰你。MyBatis的 <where>、<set>、<foreach> 这几个标签是做动态查询、动态更新的核心，建议花时间熟练掌握。

搜索词里有人在问MyBatis的if test里能不能用indexOf，这个有点冷门。实际上MyBatis的OGNL表达式里可以调用Java方法，所以 <if test="name.indexOf('张') != -1"> 这种写法是可以执行的，但意义不大，它只能判断内存里的参数值，不能反向拼SQL条件。正常的做法还是用LIKE查询或正则匹配，别折腾这种写法。

再提一下MyBatis缓存。默认情况下MyBatis一级缓存是开启的，作用在同一个SqlSession内。但如果你的项目里用了Spring，每次Mapper调用时SqlSession可能是不一样的，一级缓存的作用就被稀释了。二级缓存默认关闭，而且用起来有坑，比如多表关联查询时可能出现脏数据。宿舍管理系统这种体量，保持默认配置就好，不要为了性能硬开缓存，收益不高还可能出bug。

3.3 业务层：入住与退宿的事务处理

业务层是这套系统的精华所在。我以办理入住为例，把整个流程拆一遍。

办理入住的核心逻辑是：校验学生是否存在且当前未在住，校验目标宿舍是否存在且有空位，然后做两件事：更新宿舍已住人数，插入入住记录。这两步必须在一个事务里，否则可能出现宿舍人数更新了但入住记录没插入的数据不一致问题。

java复制@Service
public class CheckInServiceImpl implements CheckInService {

    @Autowired
    private StudentMapper studentMapper;

    @Autowired
    private DormitoryMapper dormitoryMapper;

    @Autowired
    private CheckInRecordMapper checkInRecordMapper;

    @Transactional(rollbackFor = Exception.class)
    public void checkIn(Long studentId, Long dormitoryId) {
        // 1. 校验学生
        Student student = studentMapper.selectById(studentId);
        if (student == null) {
            throw new BizException("学生不存在");
        }
        if (student.getStatus() == 1) {
            throw new BizException("学生当前已在住");
        }

        // 2. 校验宿舍并防并发更新
        Dormitory dormitory = dormitoryMapper.selectByIdForUpdate(dormitoryId);
        if (dormitory == null) {
            throw new BizException("宿舍不存在");
        }
        if (dormitory.getOccupied() >= dormitory.getBeds()) {
            throw new BizException("宿舍已满");
        }

        // 3. 更新宿舍人数（乐观更新）
        int rows = dormitoryMapper.increaseOccupied(dormitoryId);
        if (rows == 0) {
            throw new BizException("宿舍已满，请重新选择");
        }

        // 4. 更新学生状态
        studentMapper.updateStatus(studentId, 1);

        // 5. 插入入住记录
        CheckInRecord record = new CheckInRecord();
        record.setStudentId(studentId);
        record.setDormitoryId(dormitoryId);
        record.setCheckInTime(new Date());
        record.setStatus(0);
        checkInRecordMapper.insert(record);
    }
}

这里有几个细节值得展开。

第一，@Transactional 注解一定要加，遇到运行时异常时整个事务回滚。我见过有人忘了加，导致数据不一致，最后排查半天。

第二，防并发问题。宿舍分配是典型的高并发写场景，“先查再改”的做法在并发下会多卖床位。解决办法有两种：用 selectByIdForUpdate 加悲观锁，或者用 UPDATE dormitory SET occupied = occupied + 1 WHERE id = ? AND occupied < beds 乐观更新，然后检查受影响行数。我更喜欢第二种，因为悲观锁会锁行，在高并发下性能不如乐观更新。

第三，业务异常一定要自定义。不要用 RuntimeException 一把梭，不然前端无法区分参数校验错误和业务逻辑错误。我习惯写一个 BizException，配合全局异常处理器统一返回错误信息。

退宿逻辑跟入住类似但没有并发问题，核心是把入住记录的status改为1，学生状态改为0，宿舍occupied减1，同样需要事务保证。

3.4 Controller与统一返回结构

接口层设计得规范，前后端联调会省很多事。我常用的统一返回结构是：

java复制public class Result<T> {
    private Integer code;    // 200成功，500失败
    private String message;
    private T data;
}

Controller层不要写复杂逻辑，只做参数接收、调用Service、返回Result。

java复制@RestController
@RequestMapping("/api/student")
public class StudentController {

    @Autowired
    private StudentService studentService;

    @GetMapping("/list")
    public Result<PageResult<StudentVO>> list(
            @RequestParam(defaultValue = "1") Integer page,
            @RequestParam(defaultValue = "10") Integer size,
            String name, String college) {
        return Result.success(studentService.pageQuery(page, size, name, college));
    }

    @PostMapping("/check-in")
    public Result<Void> checkIn(@RequestBody CheckInDTO dto) {
        studentService.checkIn(dto.getStudentId(), dto.getDormitoryId());
        return Result.success();
    }
}

分页查询建议用PageHelper。这个插件配置很简单，引入依赖后在Mapper查询前调用 PageHelper.startPage(page, size)，MyBatis会自动拼接LIMIT语句，分页查询的代码会干净很多。

接口设计上要注意RESTful风格的语义化。列表用GET /api/student/list，新增用POST /api/student，修改用PUT，删除用DELETE。虽然宿舍管理系统不一定需要多规范，但养成好的接口习惯对后续开发帮助很大。

关于接口安全，搜索词里有人问SpringBoot的apikey安全对接。如果项目里要让第三方系统调用接口，最简单的方式是加一个自定义注解 + 拦截器，校验请求头里的API Key是否合法。但如果是内部管理系统，管理员登录用JWT或Session就足够了，不必过度设计。

4. 前端页面：Vue3如何把宿舍业务落地

4.1 环境搭建与路由设计

前端我用的是Vue 3 + Element Plus + Vite的组合。Element Plus是Vue 3生态里最成熟的UI组件库，表格、表单、弹窗、穿梭框都有现成组件，做后台管理系统效率非常高。

搭建方式直接执行命令：

bash复制npm create vite@latest dormitory-admin -- --template vue
cd dormitory-admin
npm install
npm install element-plus axios vue-router pinia

Vue Router是前端的核心。宿舍管理系统通常有三种角色：超级管理员、宿管员、学生，对应的页面权限不一样。最简单的方案是路由配置时给每个路由加meta字段，然后在路由守卫里判断登录状态和角色。

js复制{
  path: '/dormitory',
  component: Layout,
  children: [
    {
      path: 'list',
      name: 'DormitoryList',
      component: () => import('@/views/dormitory/List.vue'),
      meta: { title: '宿舍管理', roles: ['admin', 'manager'] }
    }
  ]
}

路由守卫的基本写法：

js复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  if (!token && to.path !== '/login') {
    next('/login');
  } else {
    next();
  }
});

搜索词里很多人在问Vue路由参数怎么传。这个坑确实值得讲一下：使用query传参时参数会暴露在URL里，适合分享链接的场景；使用params传参时，如果刷新页面参数会丢失，因为params只存在于内存中。在宿舍管理系统里，编辑宿舍、查看学生详情这类跳转，建议用query传ID，比如 /dormitory/detail?id=12，这样刷新页面能保留参数。用编程式导航时：

js复制// 传参
router.push({ path: '/dormitory/detail', query: { id: row.id } });

// 接收
const route = useRoute();
const id = route.query.id;

另外推荐装一个Vue Devtools插件。调试组件状态、查看路由跳转、检查Pinia状态，都离不开这个工具。装好之后，遇到页面数据不更新的问题能少掉一半调试时间。

4.2 Axios封装与请求拦截：确保登录和错误处理不出岔子

Axios是前端请求后端接口最常用的库。直接在每个页面里写axios调用会有大量重复代码，而且错误处理容易漏。我的做法是统一封装一个request模块。

js复制import axios from 'axios';
import { ElMessage } from 'element-plus';
import router from '@/router';

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
});

// 请求拦截器：统一携带token
request.interceptors.request.use(
  config => {
    const token = localStorage.getItem('token');
    if (token) {
      config.headers['Authorization'] = 'Bearer ' + token;
    }
    return config;
  },
  error => Promise.reject(error)
);

// 响应拦截器：统一处理返回码和错误
request.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code === 200) {
      return res;
    } else {
      ElMessage.error(res.message || '请求失败');
      return Promise.reject(new Error(res.message));
    }
  },
  error => {
    if (error.response && error.response.status === 401) {
      ElMessage.error('登录已过期，请重新登录');
      localStorage.removeItem('token');
      router.push('/login');
    } else {
      ElMessage.error('网络异常，请稍后重试');
    }
    return Promise.reject(error);
  }
);

export default request;

这里有个容易出问题的地方：开发环境下的跨域。如果前端是 http://localhost:5173，后端是 http://localhost:8080，直接用axios请求后端会被浏览器的同源策略拦截。解决方案有两种：后端写CORS配置允许跨域，或者前端在Vite的配置里配devServer代理。我更推荐前端代理方案，因为部署到生产环境时前后端往往在同一个域名下，代理配置可以很平滑地去掉。

Vite代理配置：

js复制// vite.config.js
server: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

这样前端请求 /api/student/list 时，Vite开发服务器会自动转发到 http://localhost:8080/api/student/list，前端代码里不需要写完整的后端地址，以后换环境只改这一处配置就行。

4.3 核心页面的交互与实现：权限控制、表单校验和Computed妙用

宿舍管理页面的核心交互有三个：宿舍列表筛选、宿舍编辑弹窗、入住分配。以宿舍列表为例，页面由搜索区、表格区、分页区组成，搜索条件包括楼栋、类型、状态。

一个值得特别关注的细节是：前端拿到后端数据后，不要直接渲染原始状态码，而要做一个翻译。比如后端返回的 status 是1和0，页面上要显示“可用”和“停用”。这个功能在Vue里可以用computed来实现，但更好的做法是后端直接返回VO对象，把状态值对应的文本一并返回。这样前端少写翻译逻辑，也不会出现后端改了字典前端没同步的情况。

关于Element Plus的表格，有几个实用技巧。第一，表格里用插槽自定义状态列的显示样式，让管理员一眼看出宿舍是否已满。第二，弹窗表单的校验规则要和后端保持一致，前端用el-form的rules验证格式，后端用javax.validation注解再验一次，两层校验缺一不可。第三，列表刷新时机要注意，新增或编辑成功后要重新拉取列表，同时清空弹窗里的表单数据。

Vue的computed在列表搜索时非常实用。比如前端根据筛选条件过滤楼栋列表，不需要发请求，直接用一个computed属性计算过滤结果：

js复制const filteredBuildings = computed(() => {
  if (!searchKeyword.value) return buildingList.value;
  return buildingList.value.filter(item => item.name.includes(searchKeyword.value));
});

这里要注意computed和watch的区别。computed是依赖响应式数据变化后自动重新计算，适合派生数据；watch是监听数据变化后执行异步或较重的操作，适合搜索防抖、弹窗关闭后重置数据等场景。在宿舍管理项目里，computed使用频率远高于watch，能用computed解决的就别用watch。

如果项目里需要查看学生在宿舍里的视频监控，还会涉及m3u8播放。这不算宿舍管理核心功能，但如果在公告或安全模块用到，前端可以用video.js插件配合hls库来播放，后端提供视频流接口。这里提一句，扩展时别在Vue里直接堆逻辑，封装成一个独立的视频播放组件会更干净。

5. 联调部署与版本兼容：那些让人抓狂的坑一次性说清

5.1 前后端联调时的跨域问题

跨域问题是前后端分离项目里遇到最多的。明明后端接口用Postman测是通的，前端一调用就报错，多半是跨域。

前端代理方案已经说过了，你还可以在后端配置一个全局的CORS配置类，两种方法选其一即可。我自己的习惯是开发环境用前端代理，因为不需要后端改代码；生产环境如果是Nginx部署，直接在Nginx里配置反向代理，把 /api 转发到后端服务。

5.2 SpringBoot版本太高带来的常见问题

搜索词里“springboot版本太高”出现频率很高，这个确实是2025年大家遇到的最典型问题。我总结三个最容易踩的坑。

第一，JDK版本不匹配。SpringBoot 3.x要求JDK17，如果你用JDK8启动直接报UnsupportedClassVersionError。解决方案是安装对版本的JDK，并在IDE里把项目SDK切换到对应的版本。这里有个小技巧：项目里尽量用maven的compiler插件锁定Java版本，不要依赖IDE默认配置。

xml复制<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

第二，javax和jakarta包名变更。SpringBoot 3.x把Spring框架的Java EE API从javax迁移到了jakarta，凡是用到HttpServletRequest、HttpServletResponse、ServletContext的地方，import语句都要改成jakarta.*开头。搜索旧教程里带的javax代码直接粘贴会有编译错误，这不是你写错了，是版本差异。

第三，Docker部署时的打包问题。搜索词里有人问JDK1.8打包到docker desktop，这里要提醒：SpringBoot 3.x的Docker镜像基础环境必须是JDK17，不能再用JDK8的镜像。如果你用Maven插件打包，建议直接用 com.google.cloud.tools:jib-maven-plugin，它不需要写Dockerfile就能构建出适合当前JDK版本的镜像。

xml复制<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>3.4.0</version>
    <configuration>
        <from>
            <image>eclipse-temurin:17-jre</image>
        </from>
        <to>
            <image>my-dormitory:latest</image>
        </to>
    </configuration>
</plugin>

5.3 MySQL安装配置与Docker方案

Windows安装MySQL，我推荐两种方式。第一种是官方安装包，下载MySQL Installer后按向导走，适合新手。第二种是Docker Desktop运行MySQL容器，好处是版本隔离、不留垃圾文件、环境清理干净，适合经常折腾环境的人。

Docker运行MySQL的命令：

bash复制docker run -d \
  --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=123456 \
  -e MYSQL_DATABASE=dormitory \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

安装完之后用MySQL Workbench或者Navicat连接测试。这里有一个高频坑：MySQL 8.0默认使用的是caching_sha2_password认证插件，一些老版本的客户端连接时会报认证失败。解决办法是在客户端配置里加 allowPublicKeyRetrieval=true，或者用命令行工具连接。在JDBC连接串里，我前面写的 allowPublicKeyRetrieval=true&useSSL=false 就是应对这个问题的。

5.4 常见问题速查表：高频报错直接对照

把做这个项目过程中遇到过的高频问题整理成一个速查表，方便大家遇事不慌。

这里专门说一个很多新手遇到过的Eclipse问题：新建SpringBoot项目时一直卡在downloading，很久都没反应。这通常是获取Spring Initializr元数据超时，原因主要是网络连接不畅。解决方法是把Spring Initializr的URL切换到国内镜像源，比如在eclipse的Spring工具栏里把service URL改成阿里云的地址。如果你的项目已经创建出来了，pom.xml里依赖下载慢，也可以在Maven的settings.xml里配阿里云中央仓库镜像。

5.5 如何判断技术栈选择会不会在面试中加分

宿舍管理系统虽然看上去是个常见项目，但只要你做得足够深，面试时完全可以讲出亮点。比如分布式session、接口幂等性、并发控制下的宿舍分配、基于角色的权限拦截，这些点都能体现你的思考深度。

很多人在面试时只会说“我用了SpringBoot+Vue做了个系统”，这就浪费了这个项目。你可以这样讲：在宿舍分配模块，我用了数据库乐观锁防止并发超卖；在权限控制上，我基于路由守卫和拦截器做了前后端双重鉴权；在性能优化上，我通过索引优化了宿舍查询的慢SQL。面试官听到这些，至少会认为你不是在机械地抄代码。

6. 最后的叮嘱：这个项目还能怎么扩展

如果你做完基础版觉得不过瘾，可以往这几个方向扩展：引入Redis缓存楼栋和宿舍的统计信息，减少数据库压力；增加宿舍评分和卫生检查模块，做成带图上传的评分系统；把报表统计做成ECharts可视化，展示各学院住宿率、空床位分布；对接企业微信或钉钉机器人，实现报修通知自动推送。这些方向都能让项目在功能深度和面试表现上更出彩。

我个人在实际操作中的体会是，做一个全栈项目最忌讳一上来就写代码。先把表结构设计好、把接口文档列出来、把前端路由规划好，再动手写，效率至少提升一倍。宿舍管理系统虽然看起来不复杂，但当你认真把事务、并发、异常处理这些细节都考虑到的时候，它已经能满足企业级开发的入门要求了。

最后再分享一个小技巧：项目开发过程中一定要用Git做版本管理，每完成一个功能就提交一次。我在做这个项目时，有一次改了宿舍逻辑导致整块数据异常，后来用Git回退了上次提交，省了大半天时间。别嫌麻烦，这个习惯会陪你走很远。