SpringBoot+Vue医院资源管理系统：预约调度与MyBatis实战

1. 项目概述

医院资源管理系统，第一次听到这个名字可能会觉得是个大而全的信息化平台，但真正拆开来看，核心需求其实非常清晰：让医院里的场地资源看得见、管得住、排得顺。这里说的资源不只是病床，还包括大型检查设备、手术室、诊疗科室、药品库存、救护车辆等等。我这次用SpringBoot做后端接口、Vue做前端界面、MySQL存业务数据、MyBatis负责持久层，把一套完整的“资源台账+预约调度+使用记录”流程跑通，源码也整理成了可以直接运行的项目。

这套系统能解决什么问题？举几个最典型的场景：护士站想知道明天还有几张空床位，不需要打电话问病区；设备科想知道CT机下午哪些时段空闲，也不需要翻纸质排班表；药房发现某类药品库存低于预警线，系统自动提醒；预约中心在患者取消预约后，空出的设备资源立即释放给其他患者使用。这些在真实医院里都是高频痛点，也正是我选择做这个题目的原因。

适合谁来参考？如果你是刚接触SpringBoot和Vue的后端开发，或者正在做JavaWeb毕业设计、课程项目，这个项目算是一个很标准的“前后端分离业务型Demo”。它的复杂程度不像电商系统那么高，但涉及到了用户权限、数据库设计、接口联调、资源状态并发处理这几个关键点，比单纯“增删改查”有营养得多。当然，如果你只是想把这套代码跑起来看看效果，我也会在后文把每一步启动细节写清楚。

2. 整体设计与技术选型解析

2.1 为什么是SpringBoot + Vue + MySQL + MyBatis

做JavaWeb项目，选型其实不需要炫技，关键看三点：团队熟悉度、社区成熟度、维护成本。SpringBoot在Java后端市场占有率极高，内置Tomcat、自动配置、starter机制让项目启动变得非常简单；Vue是目前国内前端团队用得最多的框架之一，组件化和响应式开发效率很高；MySQL是免费开源的明星数据库，医院管理系统这种中低频事务业务完全够用；MyBatis作为ORM框架，最大的优势是SQL可以由开发者完全控制，遇到复杂报表查询、多表关联时很好排查问题。

这套组合还有一个好处：前后端职责边界很清楚。前端只管页面渲染和用户交互，后端只暴露JSON接口，数据存储完全交给MySQL。我在设计时没有引入特别重的中间件，比如消息队列、分布式缓存，原因很简单——这个业务的并发量还没到那一步，加了反而增加部署和调试成本。当然，在资源预约模块里我用到了MySQL的行锁和事务控制，保证同一时间同一资源不会被重复预约。

项目整体是三段式结构：前端Vue工程（负责路由、页面、前端状态管理）；后端SpringBoot工程（负责鉴权、业务逻辑、数据访问）；数据库脚本（负责初始化和演示数据）。三者通过HTTP接口通信，Token存放在请求头里。如果你以前用纯JSP/JSP和Servlet做过Web项目，切换到这套结构后最大的感受应该是：改页面不用重启后端，加接口不用管页面，分工清爽很多。

2.2 模块划分与数据库核心设计

数据库设计是整个系统最值得花时间的环节。我把核心表分成基础数据和业务数据两大类。基础数据包括：部门表（医院科室）、用户表（管理员、医生、护士）、资源表（设备、床位、药品、车辆），其中资源表专门用一个resource_type字段区分资源种类；业务数据包括：预约记录表、排班表、使用记录表、库存预警表。这样设计的好处是，无论新增什么类型的医疗资源，都不需要重新建表，只需要在资源类型字典里加一条记录。

以床位为例，一张床位的状态我建议设置成五个值：空闲、已预约、使用中、维修中、停用。为什么不用简单的是否占用？因为真实的医院流程里，“预约”并不等于“已使用”。患者预约了床位，但在就诊当天可能取消；床位设备维修时，系统必须不让护士继续预约。如果状态设计得太少，业务分支就会写得很乱。设备表我也加了location字段和manager_user_id字段，前者记录设备所在位置，后者记录设备管理员，方便后续做责任划分。

预约表是整个系统的核心业务表，它的字段必须包含：资源ID、预约人ID、开始时间、结束时间、预约状态、创建时间。这里有个关键点：资源和时间必须联合起来判断冲突。我在appointment表上建了一个联合索引(resource_id, start_time, end_time)，同时后端在插入预约之前会执行一次“重叠时间查询”，只有查询不到冲突记录才允许插入。后面处理并发时，我还会在SQL层面加for update锁，这个放到第3节详细说。

2.3 前后端交互流程与数据格式约定

我设计接口时没有用什么复杂协议，就是非常标准的RESTful JSON。后端返回结构统一是：

json复制{
  "code": 200,
  "message": "success",
  "data": { }
}

code为200代表成功，401代表未登录或Token失效，500代表业务异常。前端Axios拦截器里先判断code，如果不是200，直接用Element Plus的Message组件弹出后端返回的message。后端也有一个统一异常处理器，代码里抛出的自定义异常（比如“该设备已被预约”）最后都会被转成这个标准结构。这么做前后端联调时非常省心，不用每个接口单独讨论返回格式。

权限认证我选择的是JWT（JSON Web Token）。用户登录成功后，后端把用户ID、用户名、角色封装进Token，设置7天过期时间，然后返回给前端。前端把Token放在每次请求的Authorization请求头里，后端通过拦截器统一解析。医院系统的菜单权限其实还应该按角色区分，比如管理员能看到“设备维护”菜单，普通医生不行，所以在登录接口返回的数据里会有role字段，前端根据角色动态生成菜单和路由。这个过程不复杂，但非常实用，属于前后端分离项目必备的能力。

3. 后端核心实现与MyBatis实战细节

3.1 SpringBoot工程结构与自定义机制

后端工程我是按标准Maven结构搭建的，重点包划分如下：

text复制com.hospital.resource
├── config          // 配置类：跨域、拦截器、MyBatis配置
├── controller      // 接口层：只做参数接收、结果封装
├── service         // 业务层：事务、业务规则、流程控制
├── mapper          // MyBatis Mapper接口
├── entity          // 数据库实体类
├── dto             // 接收参数对象、返回视图对象
├── common          // 通用类：Result、异常、工具类
└── interceptor     // JWT拦截器

我喜欢在实体类上使用@Data注解，省去手写getter/setter的麻烦。Controller层保持“薄”，只负责参数校验、调用Service、返回Result。业务判断全部放在Service层，因为预约冲突、资源状态流转这些逻辑如果在Controller里散落，后面想加事务或者加权限约束会非常痛苦。事务我在Service层加了@Transactional(rollbackFor = Exception.class)，保证预约创建过程中的状态更新、预约单插入、操作日志写入要么全部成功，要么全部回滚。

MyBatis的配置我写在application.yml里，包括Mapper XML文件路径、实体类别名、驼峰自动映射。需要注意的是，默认驼峰映射在mybatis.configuration.map-underscore-to-camel-case=true配置下，数据库字段是resource_name，Java实体字段是resourceName，MyBatis会自动转换，不需要手写一堆as别名，这个技巧能省很多无用重复代码。

3.2 Mapper XML与动态SQL的核心写法

MyBatis真正的威力在Mapper XML里的动态SQL。以资源分页查询为例，我们需要支持按资源名称模糊搜索、按类型筛选、按状态筛选、按创建时间排序。如果全靠Java代码拼接SQL，不仅容易漏条件，还容易产生SQL注入风险。所以我写了这样一个动态SQL：

xml复制<select id="selectResourcePage" resultType="com.hospital.resource.entity.Resource">
    SELECT * FROM resource
    <where>
        <if test="resourceName != null and resourceName != ''">
            AND resource_name LIKE CONCAT('%', #{resourceName}, '%')
        </if>
        <if test="resourceType != null and resourceType != ''">
            AND resource_type = #{resourceType}
        </if>
        <if test="status != null and status != ''">
            AND status = #{status}
        </if>
    </where>
    ORDER BY create_time DESC
</select>

这里标签会自动处理掉第一个条件的“AND”关键字，比写死WHERE 1=1优雅得多。分页我使用的是PageHelper，这个插件只有一行依赖和一行配置，使用时代码里直接PageHelper.startPage(pageNum, pageSize)，紧接着的查询SQL就会被自动拦截成LIMIT ?，返回值还被包装成带总记录数的Page对象。如果你不想引第三方插件，也可以直接手写LIMIT #{offset}, #{limit}，但PageHelper省的代码真心不少。

Mapper接口和XML关联的细节也容易踩坑：接口方法名必须和XML中每条SQL的id完全一致；接口的入参如果超过两个参数，必须用@Param("xxx")或者在XML里使用param1、param2这种不友好的参数名。我建议尽量用实体对象或@Param传参，可读性会好很多。还有一个老生常谈的点：MyBatis查询结果实体类必须有无参构造，这点和Jackson反序列化的要求是一样的。

3.3 MyBatis配置文件的初始化流程与你可能不知道的TypeHandler

说到MyBatis，很多人会忽略它是怎么启动的。如果你看过mybatis-spring-boot-starter的自动配置源码，会发现核心流程是：SqlSessionFactoryBean构建Configuration对象，期间会解析mybatis-config.xml或SpringBoot属性配置，再加载Mapper XML到MappedStatement集合。网上热词里有个XMLConfigBuilder，其实就是MyBatis解析XML配置文件的入口类，它把settings、typeAliases、mappers等标签逐项读取并注册到Configuration中。理解这个过程后，遇到“自定义Configuration怎么继承”“怎么向Configuration里追加TypeHandler”这类问题，就大约知道往哪里下手了。

TypeHandler是MyBatis里比较低频但很有用的扩展点。缺点场景是Java对象有List<String>类型的标签数组，想直接存成MySQL的JSON字段。默认MyBatis只能把List映射成普通字符串，所以我写了一个JsonTypeHandler，继承BaseTypeHandler<List<String>>，重写setNonNullParameter和getNullableResult方法，插入时用Fastjson把List转成JSON字符串，查询时再把字符串解析成List。然后在使用这个字段的Mapper XML里写#{tags, typeHandler=com.hospital.common.JsonTypeHandler}。第一次用会有点绕，但搞通之后处理复杂字段非常顺手。

3.4 MyBatis一级缓存二级缓存与拆坑

MyBatis默认开启一级缓存，作用范围是同一个SqlSession内，也就是同一个Mapper调用在同一个事务里，相同的查询不会重复查库。听起来挺好，但如果你在事务里先查询了一个资源的状态，接着另一个Service方法把状态改了，然后你在同一个事务里再查一次，拿到的还是旧数据。这个坑我在调试“预约后状态没刷新”的问题时踩过一次。所以在一个长事务里，如果涉及状态的更新和再查询，建议在两个查询之间调用SqlSession.clearCache()，或者直接在方法上用@Transactional划分短事务，避免把不那么相关的查询塞进同一个大事务。

二级缓存默认是关闭的，因为它跨Mapper共享缓存很容易造成脏读。尤其是我有资源表（Resource）、预约表（Appointment）这种关联查询，如果Resource的缓存和Appointment查询里联查了Resource，两边缓存数据不一致，会出现“明明预约了，列表里却看不到占用状态”这类诡异问题。我的建议是：这种业务系统没必要开二级缓存，数据库撑得住，别给自己挖坑。真要缓存热点字典数据（比如资源类型、科室名称），直接用Spring Cache或Caffeine，可控性高很多。

3.5 MyBatis打印SQL与日志配置

开发阶段最关键的一件事就是让MyBatis把执行的SQL和参数值打印出来。最直接的方法是在application.yml里加：

yaml复制mybatis:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样每条SQL都会打印到控制台，效果类似Preparing: SELECT * FROM resource WHERE resource_id = ?和Parameters: 1(String)。如果你用的是Logback，还可以单独给Mapper包设置日志级别为DEBUG：

yaml复制logging:
  level:
    com.hospital.resource.mapper: debug

这种方式不仅能打印SQL，还能打印日志时间戳，配合接口性能排查很方便。我在排查“某接口为什么越来越慢”时，就是靠SQL日志确认了某个循环查询（N+1问题）的存在，之后改用批量查询一次性查完所有预约记录，接口响应直接从2秒降到300毫秒。这个经验对任何MyBatis项目都通用。

4. 前端Vue页面搭建与联调要点

4.1 Vue工程初始化与依赖安装细节

前端我用的是Vue 3 + Vite + Element Plus。为什么不用Vue 2？因为Vue 3生态现在已经很成熟，而且Vite启动速度比Webpack快非常多，开发体验完全是两个时代。初始化命令非常简单：

bash复制npm create vite@latest hospital-web -- --template vue
cd hospital-web
npm install

这里要注意：npm install在国内网络环境下容易卡在某个包上，尤其是node-sass这类原生编译依赖。我的建议是安装之前先切换镜像源：

bash复制npm config set registry https://registry.npmmirror.com

安装依赖成功后再npm run dev，Vite默认跑在5173端口。因为后端接口跑在8080，前端开发时调用/api前缀的接口会有跨域问题。我在vite.config.js里加了代理：

javascript复制server: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true,
      rewrite: path => path.replace(/^\/api/, '')
    }
  }
}

这样前端请求/api/resource/list，实际会转发到http://localhost:8080/resource/list，绕过了浏览器的CORS限制，也让前端代码里的baseURL不用区分环境。

4.2 页面布局与组件拆分的实战思路

医院资源管理系统的页面并不复杂，我把它分成三大块：布局框架、业务页面、通用组件。布局框架使用Element Plus的el-container：顶部导航栏显示系统名称和当前用户，左侧菜单显示资源管理、预约管理、排班管理、系统设置，右侧内容区放路由视图。菜单根据角色动态生成，这部分逻辑放在路由守卫里。

业务页面中最核心的是资源列表页和预约日历页。资源列表页是一个典型的“查询表格+编辑弹窗+删除确认”组合。表格列包括资源名称、类型、状态、所属位置、管理员、操作；查询表单放在表格上方，点击查询后重新请求分页接口；新增和编辑共用一个弹窗组件，通过传入的resourceId来区分是更新还是插入。预约日历页我用的是v-calendar组件，按月展示每个设备或者床位的占用情况，点击日期弹窗创建预约，这个交互其实更接近真实排班场景。

组件拆分的原则是“一个页面一个组件，不要在页面里堆上千行代码”。比如编辑资源的弹窗，我把表单单独抽成ResourceFormDialog.vue，里面包含所有表单校验规则，父组件只负责传visible和resource对象。这样以后要加字段、改校验规则，不用动到列表页，影响范围小很多。

4.3 Axios封装、Token处理与接口联调规范

前端请求我统一封装了一个request.js模块，创建Axios实例时设置baseURL为/api，请求拦截器从localStorage取出Token并放到Authorization请求头。响应拦截器里做了三件事：返回code=200时直接返回data字段，简化业务代码；返回401时提示登录过期并跳转登录页；其他错误码统一弹出后端message。

联调过程中最容易出的问题就是字段名对不上。后端Java实体是resourceName，前端对象也写成resourceName，这没问题，但如果后端某个接口返回了resource_name，前端就取不到值。所以我在后端所有实体上都加了@JsonProperty统一约定以驼峰命名返回，前端接口文档也规定一律用小驼峰。这是小事，但统一约定能省掉至少半天的联调时间。

还有一点：接口入参不要直接传Map，因为后端很难做参数校验和文档生成。我在前端定义好接口请求函数时，都会把参数写得清清楚楚，比如：

javascript复制export function getResourcePage(data) {
  return request({
    url: '/resource/page',
    method: 'post',
    data
  })
}

后端Controller接收的是ResourceQueryDTO对象，所有参数都有Java校验注解。这样即使前端传参不规范，后端也会返回明确的“参数错误”。

5. 业务功能实现与资源调度逻辑

5.1 资源预约与冲突校验的完整流程

预约功能是整张系统中业务复杂度最高的一环。患者或者医生在前端选了资源（例如某台CT机）、开始时间、结束时间后，前端提交预约申请。后端Service层执行步骤如下：

1. 根据资源ID查询资源当前状态，如果不是“空闲”直接抛异常；
2. 查询预约表中该资源在时间窗口内是否存在其他有效预约：
   start_time < #{endTime} AND end_time > #{startTime} AND status = '已预约' AND resource_id = #{resourceId}；
3. 如果不存在重叠预约，生成预约单，状态设为“已预约”；
4. 更新资源状态为“已预约”；
5. 写一条操作日志。

第2步查询如果是正常工作日内并发不高，其实不会出问题。但在真实的抢号场景，比如同一台设备同时被两个护士提交，两个请求都通过了第2步检查，然后都插入预约单，数据就冲突了。为了解决这个并发问题，我在第3步插入预约单之前使用了SELECT ... FOR UPDATE锁住该资源记录，这样第二个请求会阻塞在第一个事务提交之后，再查询重叠预约时就能看到新增记录，从而执行失败回滚。

另一种常见方案是给资源表加version字段，乐观锁更新资源状态时校验版本号。我的体会是：对于资源预约这种“极小概率冲突但严格不允许冲突”的场景，数据库悲观锁更简单可靠，因为你不需要处理更新失败重试的补偿逻辑。如果以后系统要接高并发秒杀场景，再考虑Redis分布式锁可能更合适，但那是另一个级别的复杂度。

5.2 设备维护、药品库存与预警处理

医院资源管理系统除了预约，还要覆盖日常维护和库存监控。设备维护我单独设计了一个“维护计划表”：每台设备可以绑定固定周期，系统根据上次维护日期自动计算下次维护日期，在到期前3天给管理员生成待办任务。设备状态此时自动设为“维修中”，不允许预约。这个逻辑靠定时任务@Scheduled(cron = "0 0 2 * * ?")每天凌晨扫表实现，非常直观。

药品库存我用了“库存预警阈值”字段，库存量低于预警值后，库存列表里的状态自动变为“预警”，同时生成一条待处理工单。药品出入库记录单独记录表和当前库存表分开：每一条出入库记录都为只读，当前库存表根据出入库明细实时加减。这样就算某天数据对不上，也能逆向追溯是哪个操作导致的。这个设计思路很简单，却是我在实际项目里认为最稳的方案。

5.3 数据统计、报表与查询性能优化

系统里还有一个综合统计页面，展示资源利用率、预约取消率、科室资源使用排行。报表的SQL集中在Mapper XML中，比如统计每个科室一个月内使用设备的总时长，SQL大概是：

xml复制SELECT d.dept_name, SUM(TIMESTAMPDIFF(MINUTE, a.start_time, a.end_time)) AS total_minutes
FROM appointment a
JOIN resource r ON a.resource_id = r.resource_id
JOIN department d ON r.dept_id = d.dept_id
WHERE a.start_time BETWEEN #{startTime} AND #{endTime}
GROUP BY d.dept_name
ORDER BY total_minutes DESC

这种分组统计在数据量大了之后会变慢，解决方案不是盲目加索引，而是先用EXPLAIN看执行计划。我的经验是：appointment表的resource_id、start_time、end_time联合索引在WHERE条件里都能命中，问题通常不在单表，而在GROUP BY和JOIN。如果统计页数据需要很长时间跨度，就应该牺牲一部分实时性，每天晚上把统计结果缓存到一张报表表里，前端查询报表表而不是查明细表。这也是医院业务很常见的处理方式：明细数据和汇总数据分离。

6. 完整源码的运行与二次开发实战

6.1 环境准备与数据库初始化

这套代码要跑起来，首先要确认本地环境。后端需要JDK 1.8或JDK 11，Maven 3.6及以上；前端需要Node.js 14以上；数据库建议MySQL 5.7或8.0，云数据库也没问题。如果你用的是MySQL 8.0，连接串里有个容易被漏掉的参数：allowPublicKeyRetrieval=true。MySQL 8.0默认使用caching_sha2_password认证插件，如果连接串不开启这个参数，JDBC连数据库时会报Public Key Retrieval is not allowed，很多新手在这里卡住，以为是密码写错了。

数据库初始化时，我提供了一个init.sql脚本，包含建库语句、建表语句和演示数据。第一次操作顺序是：

bash复制mysql -u root -p < init.sql

脚本里面我建好了一个名为hospital_resource的数据库，默认管理员账号是admin，密码是123456。建议你本地跑通之后立刻修改这个默认密码，因为网上很多开源项目的默认账号密码都被人扫过了，真实部署时这是最基本的安全底线。

6.2 后端启动与前端启动步骤

后端启动有两条路：直接用IDEA打开工程，右键HospitalResourceApplication运行；或者用命令行执行mvn spring-boot:run。第一次启动时Maven会下载大量依赖，速度慢的话可以给Maven配置阿里云镜像，这几乎是我每次搭建环境必做的操作。

前端启动步骤略多一点：

bash复制cd hospital-web
npm install
npm run dev

如果npm install时报权限错误或者依赖冲突，我一般是先删除node_modules和package-lock.json再重新安装；如果还是不行，换Node版本，用nvm管理版本非常方便。Vue项目跑起来后打开http://localhost:5173，看到登录页就说明前后端联通没问题。如果登录后接口报401，大概率是Token没存进请求头，检查一下request.js里的拦截器和大写字母Authorization是不是写错了。

6.3 从生成的Jar包反编译回Maven项目的实用思路

很多同学拿到手的是编译好的jar文件而不是完整源码，想看代码却无法直接打开。这里分享一个不算秘密但很实用的方法：先用JD-GUI或者Luyten这类反编译工具打开jar包，查看BOOT-INF/classes目录下的class文件，把对应的.class文件反编译成.java源码；然后手动按Maven标准目录结构还原整个工程。需要特别注意的是，SpringBoot的fat jar里包含所有依赖包，还原时不需要把依赖也复制出来，只需要把项目自身源码和pom.xml的依赖坐标对上就行了。

如果jar包里包含原始资源文件（比如static目录、mapper/*.xml），这些可以直接解压出来，保存到对应位置。反编译得到的代码可能无法直接编译通过，因为Java反编译对泛型、注解的还原并不完美，但用于阅读业务逻辑、理解实现思路是足够用的。这里也提醒一句：如果项目作者明确开源了完整源码，尽量用作者发布的源码；反编译仅适合作为学习参考，不要用来做侵权的事。

6.4 二次开发建议：如何扩展新资源类型

系统设计了资源类型字典，新增资源类型时不需要改表结构。但这种灵活性对应的代价是前端页面必须能适配不同资源类型。我的做法是：前端资源列表根据resourceType字段，动态渲染不同的附加列和编辑表单字段。比如type=bed时显示“床位楼层/病房号”，type=equipment时显示“设备编号/厂商/维护周期”，这些字段都存到资源扩展信息JSON字段里，前端用动态表单配置来渲染。

如果你想让系统更贴近真实医院，还可以集成附件上传功能。我建议把上传的文件存到MinIO里面，而不是直接丢到数据库或者本地磁盘。SpringBoot集成MinIO非常简单，官方提供Java SDK，上传接口接收MultipartFile后，用bucket存储即可。系统里还需要做药品名称的模糊搜索，如果觉得MySQL的LIKE搜索在数据量大之后不够准，可以引入HanLP分词处理建立关键词索引，但这属于可选的进阶功能，不建议第一次就把复杂度堆起来。

7. 常见问题排查与避坑实录

7.1 MySQL连接报错与SSL问题定位

开发阶段最头疼的一类问题是数据库连接串配置不对。我总结了几种高频情况：

这里有一个非常常见的坑：在application.yml里写连接串时，&符号会被YAML解析成特殊字符，所以必须用双引号把整个url包起来，或者用&转义。我因为这个配置排查了半小时，最后发现是单元符搞鬼。

7.2 MyBatis打印SQL与缓存问题排查

如果你发现SQL一直不执行，或者查询结果“看起来不太对”，第一步永远是开启SQL日志。除了前面提到的StdOutImpl，还可以在Logback配置里加入具体Mapper的DEBUG日志。打印SQL之后，肉眼检查Preparing行的语句是否带上了多余的AND，Parameters行的参数类型是否和字段类型匹配，基本能排查掉80%的问题。

缓存问题则是更隐性的坑。如果你在开发时开了二级缓存，修改数据库数据后，查询结果还是老样子，第一个怀疑对象一定是缓存。关闭二级缓存的方法是不写<cache/>标签，或者设置mybatis.configuration.cache-enabled=false。在开发阶段建议直接关闭，也就是让MyBatis只保留默认的一级缓存，这样调试起来最直白。等项目稳定上线后，再对字典表这种超高频读取的数据做针对性的缓存优化。

7.3 SpringBoot版本过高导致的兼容性问题

现在SpringBoot 3.x已经是默认趋势，但对于老项目的改造来说，版本升级可能带来说不尽的麻烦。最典型的问题是：SpringBoot 3.x要求JDK 17，而很多学校的课程和线上服务器还在用JDK 8；SpringBoot 3把javax.servlet改成了jakarta.servlet，原有代码里的import javax.*全部要改。如果你下载的项目是基于SpringBoot 2.7写的，但本地Maven配置拉到了3.x依赖，启动时会出现莫名其妙的类不存在错误。

我的建议是：除非必要，不要在生产环境把SpringBoot从2.x升到3.x。我这次的项目就固定在2.7.18版本，配合JDK 8和Tomcat 9，兼容性最稳。如果你一定要用SpringBoot 3，那在改代码时重点排查javax改成jakarta、springfox改成springdoc、Redis的Jedis和Lettuce依赖变化等几个地方。

7.4 前端跨域报错与依赖安装失败的应对

前端页面登录成功后，如果控制台出现Access-Control-Allow-Origin相关报错，说明跨域问题没有处理好。开发环境我推荐用Vite的proxy解决，不要去后端配@CrossOrigin，因为一个项目可能对接多个前端地址，后端写死跨域源反而难维护。生产环境把前端打包成静态文件后，用Nginx部署，并配置反向代理到SpringBoot接口地址，既解决了跨域，也隐藏了后端端口，效果最好。

依赖安装失败是另一个高频问题。npm install报ELIFECYCLE错误，通常是有包在编译原生代码时失败。我一般会尝试三步：先清缓存重新装，再换Node版本，最后用镜像源。如果某个特定包怎么都装不上，可以手动指定版本号，比如npm install element-plus@2.4.4 --legacy-peer-deps，跳过依赖冲突检查。记住，遇到依赖问题不要死磕一个版本，观察报错信息里的包名，单独处理它才是最高效的路径。

8. 我的一些实操体会

整套系统从前端页面到后端接口全部跑通，我最大的体会是：项目难点从来不在技术框架的新旧，而在业务流程的状态设计。资源管理系统表面上是做了几张表、几个页面，但真正有价值的部分是怎么定义“空闲—已预约—使用中—维修中”的流转，以及并发预约时怎么保证不冲突。这些逻辑即使再换一个技术栈，核心思路依然是通用的。

对于想拿这个项目练手的朋友，我给一个很实在的建议：先别急着看全部源码，而是自己根据需求文档画出数据库ER图，理清资源表和预约表、排班表的关系，再去看源码，吸收效率会高很多。如果你能把这套预约冲突校验的代码自己默写一遍，再动手写一遍前端预约日历，比我讲任何原理都管用。

另外我还是想强调日志的重要性。开发阶段日志乱一点没关系，关键是SQL日志和异常堆栈一定要能及时看到。等系统上线后，再把敏感的SQL日志级别调高，同时保留业务操作日志，比如谁在什么时候取消了预约，这类日志在排障时能救命。多做这步，你后面接手维护这个系统时会省很多事。