SpringBoot+Vue医院后台管理系统：从数据库设计到部署答辩全攻略

有人问我，SpringBoot+Vue做医院后台管理系统，到底选哪套方案最省心。我的看法很直接：如果你只想要一套能跑通、能答辩、能写论文的Java Web毕设，那么"SpringBoot+Vue+MySQL+MyBatis-Plus"这套组合，加上完整的源码、SQL脚本、接口文档，就是最稳妥的答案。

这套医院后台管理系统，覆盖了科室管理、医生排班、挂号收费、药品库存、住院管理等核心业务模块，前后端分离，接口规范，表结构清晰，启动起来就能看到数据。它适合三类人：第一类是正在准备Java Web毕设、需要完整可运行项目的学生；第二类是想把前后端分离技术栈完整走一遍的初学者；第三类是时间紧、需要快速交付演示项目的同学。这篇文章我就把整个项目的设计思路、核心表结构、后端实现、前端要点、部署流程和踩坑记录从头到尾拆一遍，包括SQL脚本里为什么这样建表、接口文档怎么写才能拿高分，都一并说清楚。

1. 项目整体设计与实现思路

1.1 为什么SpringBoot+Vue成了毕设标配

先说技术选型。SpringBoot和Vue的组合，这几年几乎成了Java Web毕设的默认答案，不是没有道理。

从后端角度看，SpringBoot把Spring繁琐的XML配置全部干掉，内嵌Tomcat，一个mvn spring-boot:run就能起服务，项目结构可以用maven脚手架一键生成。医院管理系统涉及的增删改查、分页模糊搜索、权限控制、事务回滚，SpringBoot加Spring MVC加MyBatis-Plus全覆盖，代码量小、学习曲线平滑，参考资料也多到搜不完。

从前端角度看，Vue的单文件组件、Element UI组件库、Axios异步请求，配合Vue CLI，做后台管理页面跟拼积木一样。表格用el-table，表单用el-form，弹窗用el-dialog，分页用el-pagination，菜单布局用el-container，组件现成的，改改数据字段就行。即便你前端基础一般，只要把组件文档开着，就能把页面堆出来。

这套组合还有一个隐藏优势：前后端分离的架构本身就是答辩加分点，因为可以说"前端独立部署、后端独立发布、通过RESTful接口交互、并行开发效率高"——这话是标准的专业表述，说出口评委不会追问。

1.2 功能模块是怎么划分的

医院后台管理系统，核心业务逻辑戴着一顶医院帽子，本质上还是典型的"多模块后台管理"，但业务表之间有关联，做起来比单纯的用户管理更有内容。我按模块拆给你看。

模块和模块之间的典型流程是：管理员建科室→科室下添加医生→医生设置排班→患者挂号→患者看诊后创建收费单→医生开药后扣减库存。一张挂号的记录，背后至少关联医生排班表、患者表、用户表、科室表四张数据来源，这套逻辑做完整了，业务上就站得住脚。

我在指导毕设时的一贯建议是：模块不必贪多，但核心链路一定要完整。哪怕只做挂号、医生、科室、收费、药品这几个模块，把挂号到收费的链条跑通，加上权限和登录，再配点统计图表，答辩时比那些堆了一堆功能却互相孤立的项目要强太多。

1.3 表之间的关系提前理清楚

医院管理系统最忌讳把关联结构做乱。你在设计SQL脚本之前，先花半小时把实体关系画出来，后面所有代码、接口、页面都会好写很多。

我的习惯是：用户表和医生表通过userId作为外键关联；医生表和科室表通过deptId关联；挂号表分别对医生排班、患者、操作挂号均需记录；收费明细表通过挂号记录关联收费单。设计原则很简单，查询频率高的关联字段建立索引，状态字段全部用tinyint，金额字段统一用decimal(10, 2)。这些细节在SSH老项目里可能无所谓，但SpringBoot+MyBatis-Plus环境下，字段类型不对会直接引发查询报错、兼容性故障。

2. 数据库设计与SQL脚本解读

2.1 核心表结构逐个拆解

SQL脚本是整个项目的基石。我见过不少同学拿到源码，结果SQL脚本一导入就报错，最后发现是表顺序建错、外键找不到父表、编码不一致。为了避免这些问题，我先说建表的整体约定：

• 数据库字符集统一用utf8mb4，排序规则用utf8mb4_general_ci，这样患者姓名存生僻字不报错；
• 主键用bigint自增，逻辑删除字段deleted默认0，创建时间create_time和更新时间update_time每个业务表必须有；
• 金额字段用decimal(10,2)，数量字段用int，状态字段用tinyint，日期用datetime或者date，不存字符串。

具体表结构，我用医生表和挂号表举例说明。

医生表的核心字段包括：

CREATE TABLE `doctor` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '医生ID', `user_id` bigint(20) DEFAULT NULL COMMENT '关联用户ID', `dept_id` bigint(20) NOT NULL COMMENT '所属科室ID', `doctor_name` varchar(50) NOT NULL COMMENT '医生姓名', `doctor_title` varchar(50) DEFAULT NULL COMMENT '职称', `skill` varchar(255) DEFAULT NULL COMMENT '擅长领域', `doctor_status` tinyint(1) DEFAULT '1' COMMENT '出诊状态 1出诊 0停诊', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, `deleted` tinyint(1) DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_dept_id` (`dept_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='医生信息表';

挂号表的设计要稍微用心，因为挂号是业务的核心节点：

CREATE TABLE `registration` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `patient_id` bigint(20) NOT NULL COMMENT '患者ID', `doctor_id` bigint(20) NOT NULL COMMENT '医生ID', `dept_id` bigint(20) NOT NULL COMMENT '科室ID', `schedule_id` bigint(20) NOT NULL COMMENT '排班ID', `registration_no` varchar(32) NOT NULL COMMENT '挂号单号', `reg_type` tinyint(1) DEFAULT '1' COMMENT '号别 1普通 2专家', `reg_fee` decimal(10,2) NOT NULL COMMENT '挂号费用', `reg_status` tinyint(1) DEFAULT '0' COMMENT '0待就诊 1已就诊 2已退号', `visit_date` date NOT NULL COMMENT '就诊日期', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_patient_id` (`patient_id`), KEY `idx_doctor_id` (`doctor_id`), KEY `idx_schedule_id` (`schedule_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='挂号记录表';

注意挂号表里我建立了三个索引，分别是patient_id、doctor_id和schedule_id。因为业务上最常见的查询就是"查某个患者的挂号记录"、"查某个医生某天的挂号情况"、"根据排班查剩余号源"，这三个索引能直接命中。你可以现在打开SQL脚本，对照看看有没有和我这个设计匹配。

2.2 SQL脚本里的初始化数据为什么重要

很多人低估了初始化数据的重要性。一套医院管理系统，SQL脚本里如果不带初始数据，启动后页面上全是空表，演示效果会大打折扣。我在项目里做好的SQL脚本通常包含几类数据：管理员账号、测试患者、测试医生、科室数据、药品基础数据，以及几条演示用的挂号记录。

特别是管理员账号，我强烈建议SQL脚本里直接初始化一个账号：admin/123456，密码存的是MD5加盐后的值。因为答辩演示时你不可能现场注册账号，评委第一眼一定看登录页，账号顺利进系统，后面演示才能继续。

数据该怎么给才合理，这里有个经验：科室至少给10个以上，比如内科、外科、儿科、妇科、骨科、眼科、耳鼻喉科、皮肤科、口腔科、急诊科；每个科室配2到3个医生；药品给几十条常用药；挂号记录给个五六条覆盖不同状态。这样页面打开后列表页有数据、图表页有数可聚，观感完全不同。

2.3 外键到底建不建

这个问题我在带毕设时被问过无数次：表结构要不要加外键约束。

我的建议是：物理外键不要加，逻辑外键要有。原因很简单，SpringBoot项目里用了MyBatis-Plus之后，业务删除数据时经常先查后代删，物理外键会导致删除顺序卡死。加上医院管理系统里有大量跨表查询，物理外键的约束在并发下还容易引发死锁。你在SQL脚本里保留逻辑外键字段（比如doctor表里的dept_id），查询时用JOIN把两个表关联起来，这样既满足功能，又避免操作麻烦。很多企业项目现在也是这么做的，这个思路写进论文，答辩时还能表述一下"采用逻辑外键保证灵活性和查询性能"。

3. 后端SpringBoot核心环节拆解

3.1 项目结构和基础依赖

拿到源码之后，你要先看项目结构，再改配置，最后才跑得起来。我的建议是不要上来就改业务代码，先把目录结构和Maven依赖梳理清楚。

标准的SpringBoot项目结构是这样的：

com.hospital ├─ common // 通用工具、常量、返回结果封装 ├─ config // 配置类，如MyBatis-Plus分页、CORS跨域 ├─ controller // 控制器层，RESTful接口 ├─ service // 服务层接口及实现 ├─ mapper // MyBatis-Plus的Mapper接口 ├─ entity // 实体类，对应数据库表 ├─ interceptor // 登录拦截器 └─ HospitalApplication.java // 启动类

pom.xml里的核心依赖我会列这几个：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、jjwt（JWT工具）、spring-boot-starter-validation、hutool-all。这三个最常用：MyBatis-Plus负责持久层、JWT负责登录鉴权、Hutool负责日期和ID生成工具。

需要特别注意版本号。如果你用的Java版本太高，比如JDK 17或更高，而SpringBoot版本还在2.3.x，启动时会直接报"Unsupported class file major version"错误。一般推荐SpringBoot 2.7.x配JDK 8或JDK 11，这个组合最稳定；如果非要上JDK 17，可以换SpringBoot 3.x，但MyBatis-Plus也要跟着换成3.5.3以上版本，因为旧版对Jakarta命名空间不兼容。

3.2 登录鉴权：Token方案怎么做

医院后台管理系统必然要登录鉴权，这里选型有两个方向：Session方案和Token方案。这个项目用的是Token方案，我解释一下为什么是它。

Session方案在前后端分离场景下有个致命问题：前端和后端不一定部署在同一台服务器，跨域请求时Session的Cookie携带很麻烦，而且Tomcat的Session是单机的，一旦服务重启，所有登录状态全部失效。Token方案则把用户信息签进一串加密字符串里，后端无状态，前端每次请求在Header里带上，服务端拦截器统一校验，部署起来完全不用关心会话同步问题。

实现Token方案我推荐用JWT，核心流程是：

1. 登录时根据数据库中查询到的用户信息生成JWT，设置过期时间，通常2小时；
2. 前端收到token后存进localStorage，axios请求拦截器从localStorage取出token，放进请求头；
3. 后端写一个LoginInterceptor，实现HandlerInterceptor接口，在preHandle方法里从Header拿到token，解析校验，如果无效直接返回401状态码；
4. 把拦截器注册到WebMvcConfigurer，放行登录接口、静态资源，其他接口全部拦截。

代码里最关键的两行是把JWT的密钥和过期时间放在application.yml配置里，不要写死在代码中。我见过不少项目把jwt相关常量散落在多个类里，换一个人维护就找不到。我参考的几个毕业设计源码都把它集中到JwtUtil工具类，密钥写死也在代码里，但启动时调试还行，交到别人手里就成隐患。

JWT工具类里生成token和解析token的方法，写法如下：

public class JwtUtil { private static final String SECRET = "hospital-secret-key"; private static final long EXPIRE = 1000 * 60 * 60 * 2L; public static String createToken(Long userId, String username) { return Jwts.builder() .claim("userId", userId) .claim("username", username) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

密码存储方面，数据库里存的一定要是经过MD5或BCrypt处理后的密文。MD5加盐实现简单，BCrypt安全性更高，毕设用MD5加固定盐就够了，论文里提一句"密码加盐哈希存储"，专业度直接上了一个档次。

3.3 统一返回体和全局异常处理

前端在请求数据时，最痛恨的就是后端一会儿返回"{code:200,data:...}"，一会儿又返回一个裸的List。为了让前端对接省心，这个项目里我把所有接口的返回格式统一封装成Result对象，结构是状态码、提示消息、数据体三件套。

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String msg) { Result<T> result = new Result<>(); result.setCode(code); result.setMsg(msg); return result; } }

全局异常处理也要配套，不然后端一报错，前端拿到的是项目默认错误页，毫无辨识度。用@RestControllerAdvice注解写一个GlobalExceptionHandler，捕获业务异常、参数校验异常、系统异常三类，分别返回不同的Result对象。这个类虽然是辅助功能，但面试答辩时问到"你怎么做异常兜底"，这就是你的加分点。

3.4 一个核心接口的完整链路：医生排班

我拿"医生排班"这个高频接口走一遍整个后端的实现链路，你照着理解，所有模块的套路都一样。

先说需求：前端要展示某个科室下医生的排班表格，包含排班日期、时段、号源总量、剩余号源、挂号费，同时支持新增班次。

后端三层代码分别这样写。

Controller层，接口设计为GET /api/schedule/list，参数是deptId和date：

@RestController @RequestMapping("/api/schedule") public class ScheduleController { @Autowired private ScheduleService scheduleService; @GetMapping("/list") public Result<List<ScheduleVO>> list(@RequestParam Long deptId, @RequestParam String date) { return Result.success(scheduleService.getScheduleList(deptId, date)); } }

Service层，调用Mapper查询指定日期和科室的排班数据。这时要注意：排班表里有doctorId，前端页面显示时不能显示ID而要显示医生姓名，所以Service层要组装一次VO，把医生姓名、科室名称联表查出来填进去。

Mapper层，用MyBatis-Plus的LambdaQueryWrapper就能搞定单表查询：

public List<Schedule> selectScheduleByDeptAndDate(Long deptId, String date) { LambdaQueryWrapper<Schedule> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Schedule::getDeptId, deptId) .eq(Schedule::getScheduleDate, date) .eq(Schedule::getDeleted, 0); return scheduleMapper.selectList(wrapper); }

排班新增时，需要做一步去重校验：同一个医生在同一天的同一个时段不能排两次，否则会崩。这个逻辑放在Service层，先查重复再插入，用数据库唯一索引做兜底，前端显示"该医生此时段已排班"的提示。

整个模块没有花哨的技术，就是标准的CRUD加联表组装。但注意几个细节：日期条件必须用字符串等于，不要用时间范围，因为排班天然是按照自然日做的；剩余号源你也不要单独存一个字段，而应该用"号源总量 - 已挂号数量"来实时计算，这样退号之后剩余号源自动恢复，不需要额外维护。

4. 前端Vue核心实现要点

4.1 环境的坑：Node和依赖装上才能跑

后端代码配置好之后，前端还要花点心思。我看过很多人跑SpringBoot+Vue项目，后端启动成功，前端npm run dev报一堆错，最后发现是Node版本不兼容。

我的建议很明确：前端工程用的是Vue 2，配套的是Vue CLI 4或5，Node版本要求是10到16之间，我实测用Node 14最稳。如果你的电脑上Node已经是18或20，直接运行老项目很可能会报"ERR_OSSL_EVP_UNSUPPORTED"，这不是项目代码的问题，而是OpenSSL新版本对老Webpack的兼容性崩了。解决办法是改package.json的dev脚本为：set NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve，Windows下这个写法有效，Mac和Linux要把set换成export。

依赖安装走npm install，如果速度慢或者卡住，就临时改用镜像源。装完依赖后运行npm run dev，默认端口是8080，而你后端接口跑在8080或8888，跨域问题直接用前端开发服务器的代理配置解决。在vue.config.js里配一个devServer.proxy，把/api开头的请求转发到后端地址：

devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8088', changeOrigin: true } } }

配好代理之后，前端页面里的axios请求路径就不要写全地址了，统一写/api/xxx，这样开发环境和生产环境都不需要改代码。

4.2 路由和权限控制：动态路由还是静态路由

医院后台管理系统的页面结构一般是侧边菜单加顶部栏加主内容区，菜单项对应路由。做路由有两种做法：静态路由和动态路由。

静态路由就是所有页面在router/index.js里写死，登录之后全部可访问。简单是简单，但如果你的项目里有角色权限区分，比如管理员能看到系统管理菜单，普通医生只能看到排班和患者模块，那就必须做动态路由。

动态路由的实现套路是：菜单表存在数据库里，后端在登录成功后返回当前用户的路由列表，前端用router.addRoute动态注册，再配合el-menu根据路由生成侧边菜单。这套逻辑比静态路由复杂，但只要做出来，项目档次明显不一样，也是答辩时可以重点讲的"亮点"。

如果时间紧张，最省事的方案是路由守卫只做登录校验，菜单权限先不做细分，把所有菜单都渲染出来。但我个人建议，既然已经拿到了完整源码，还是把动态路由的部分研究透，哪怕是照葫芦画瓢改一遍，对你理解权限控制的原理都有很大帮助。常见操作是前端定义一个常量路由表存基本页面，后端接口返回动态路由地址，配合Vuex的permission模块管理，刷新页面时再从后端重新拉取并重新注册。

4.3 Axios封装和处理

前端每个页面都要请求接口，所以axios请求工具一定封装成公共模块。我在项目里的做法是：在src/utils/request.js里创建一个axios实例，统一设置baseURL为/api，设置超时时间，添加请求拦截器和响应拦截器。

请求拦截器做的事主要是从localStorage取出token，放进Header的Authorization字段。响应拦截器做的事主要是判断返回的code，如果等于401说明token过期或未登录，直接跳转到登录页并清空本地存储；其他非200状态码统一弹出错误提示。

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code === 401) { localStorage.removeItem('token'); router.push('/login'); return Promise.reject(new Error(res.msg)); } return res; }, error => { Message.error(error.response?.data?.msg || '请求失败'); return Promise.reject(error); } );

这里我踩过一个坑：不要把整个token字符串原封不动放进Authorization，也不要加"Bearer "前缀的一致性不一致，否则后端解析时容易互相闪躲。可以在生成token时就把"Bearer "前缀定义好，前后端约定一致，把这步作为接口文档中的一个注意事项。

4.4 核心页面怎么写：挂号记录列表

方建挂号记录的页面是典型的"搜索条件+表格+分页+弹窗表单"四件套，我把它的写法拆给你看。

搜索区一般有三个条件：患者姓名、医生姓名、挂号状态。表格列的字段一般是挂号单号、患者姓名、医生姓名、科室、号别、挂号费、状态、就诊日期、操作按钮。分页组件绑定当前页和每页条数，切换时重新请求列表接口。弹窗表单用来新建挂号记录，表单里有患者、医生、就诊日期、号别几个字段，医生选择之后自动带出挂号费，这个联动效果用el-select的change事件实现。

前端表格数据的格式往往和后端返回的不完全一致，所以我建议后端直接返回一个VO，把状态码转换成状态文字，比如0转成"待就诊"、1转成"已就诊"、2转成"已退号"，前端只需渲染，不需要自己维护一个翻译字典。但如果后端偷懒返回了数字，前端可以用一个filters函数转换，也是常见做法，不过最好还是后端统一处理。

页面里的"删除"和"退号"操作，一定要加二次确认弹窗，el-popconfirm或MessageBox.confirm都行。不要小看这个操作，没有确认框的单据类型页面，误点删除后数据就找不回来了，演示时手一抖就是事故现场。

5. 接口文档、部署与毕设答辩筹备

5.1 接口文档该怎么写才算专业

很多同学以为接口文档就是列一堆URL，这是一个很明显的误区。一份能打动评委的接口文档，至少要为每个接口包含以下六部分内容：请求地址、请求方式、请求参数说明（参数名、类型、是否必填、含义说明）、请求体示例、响应示例、错误码说明。

同一个接口我用挂号列表举例：

接口名称：挂号记录分页查询 请求方式：GET /api/registration/page 请求参数： | 参数名 | 类型 | 必填 | 说明 | | pageNum | int | 是 | 页码，从1开始 | | pageSize | int | 是 | 每页条数 | | patientName | string | 否 | 患者姓名模糊搜索 | | regStatus | int | 否 | 挂号状态 0待就诊 1已就诊 2已退号 | 响应示例： { "code": 200, "msg": "操作成功", "data": { "total": 100, "records": [ { "registrationNo": "20250115001", "patientName": "张三", "doctorName": "李医生", "regType": "普通号", "regFee": 10.00, "regStatus": "待就诊" } ] } }

接口文档统一用Markdown格式写，最好按模块拆分成多个文件，放在项目的doc目录下。我在实际体验中发现，如果接口文档与代码结构保持一致，比如controller的类名对应接口文档的章节名，维护起来就很顺手。而且接口文档能够作为交付物的一部分，很多公司里后端交付也是要附接口文档的，这一项在答辩中还能单独立一个"规范开发过程"的亮点。

5.2 打包部署：前后端怎么跑起来

后端部署，先在application.yml里确认数据库账号密码和端口，然后在项目根目录执行mvn clean package -DskipTests，打出一个jar包。启动就一行命令：java -jar hospital.jar。如果想指定端口，加--server.port=8888。在Linux服务器上跑，用nohup java -jar hospital.jar > log.log 2>&1 &，这样退出终端服务不会断。

前端部署，先执行npm run build，生成dist目录。dist目录是纯静态文件，可以直接扔到Nginx的html目录，或者跟后端jar包放在一台机器上，用Nginx做代理。

Nginx配置的核心是两段：一段把前端静态资源指到dist文件，另外一段把/api请求反向代理到后端的Java端口：

server { listen 80; server_name localhost; location / { root /home/hospital/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8088; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

要注意，配置里的try_files $uri $uri/ /index.html非常关键，不写这行，前端路由刷新页面时会404。这个问题在我收到的反馈中是最多的，十个人里有七个人在部署时栽在这里。

5.3 答辩演示时讲什么

项目本身跑通只是及格，答辩演示时的讲法决定分数高低。我给参加过答辩的同学总结了一个"演示三阶段"的思路。

第一阶段讲业务，时间控制在1分钟。演示登录页，输入管理员账号，进系统后先展示首页统计面板，简单说明今天挂号数量、收费金额、药品流转情况，让评委对项目整体有印象。

第二阶段讲模块，时间控制在2分钟。从科室管理进去，展示科室列表，再进医生管理，操作一下新增医生，注意新增时必须关联科室；然后进挂号模块，演示一次完整挂号操作，展示号源变化。这个流程展示的是系统的数据联动能力，不是单表CRUD的堆叠。

第三阶段讲代码，这是答辩里的加分项。切到IDE，展示项目分层结构，说清楚controller-service-mapper的调用关系，挑权限拦截器或JWT的工具类讲十几秒，最后展示接口文档，说"项目所有接口都按RESTful规范设计，文档齐全"。

整个演示不要超过5分钟，超过5分钟评委注意力就分散了。你要事先把数据准备好，不要现场临时新增带生僻字的数据，不要在演示过程中去修Bug。

6. 实际问题排查与避坑记录

6.1 跨域联调阶段最常见的坑

前后端分离开发时，跨域问题几乎是99%的项目都会遇到。前端跑8080端口，后端跑8088端口，页面请求直接报"Access-Control-Allow-Origin"错误。

解决思路有两条，我建议两条都配好。第一是在后端写一个CorsConfig，实现WebMvcConfigurer的addCorsMappings方法，允许所有来源和所有方法跨域。配置之后直接生效，不用重启时改前端。

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

第二就是前面说的vue.config.js代理方案。两条都配置的冗余设计看似重复，实际是为了保证开发环境用代理、以后若拆开部署时也能直接跨域访问，两头不误。

6.2 SQL脚本导入失败的多种可能性

如果你拿到SQL脚本导入MySQL时报错，先别急着怀疑代码，按照我的排查顺序走一遍。

第一查编码。用记事本打开SQL文件，看文件头有没有中文乱码，有乱码就把文件另存为UTF-8编码。第二查MySQL版本。如果你用的是MySQL 8.0以上，而脚本里有老版本的关键字或语法，会报语法错误，需要把脚本里的某些写法替换为MySQL 8支持的写法。第三查导入顺序。一个完整项目如果拆成多个SQL文件，必须先执行表结构脚本，再执行初始化数据脚本，最后执行视图或触发器脚本。

我见过最典型的错误是报"Unknown column"错误，原因是表格字段的注释或某个列名不匹配。这种问题按提示对应的表名去查脚本，找到就能修。

6.3 启动类包扫描问题导致Mapper找不到

SpringBoot项目启动后，如果直接报"Invalid bound statement"或者"Mapper method not found"，基本可以确定是Mapper接口没有被扫描到。

处理办法是在启动类上添加@MapperScan注解，扫描mapper包路径。不要只依赖Mapper接口上的@Mapper注解，因为接口一多容易遗漏。

@SpringBootApplication @MapperScan("com.hospital.mapper") public class HospitalApplication { public static void main(String[] args) { SpringApplication.run(HospitalApplication.class, args); } }

这个节点我也遇到过，而且是最容易让人抓狂的，明明代码照着写了，启动就报错，最后发现是mapper包名写错一个字母。所以我的习惯是：所有新增的Mapper接口，一定放在同一个包下面，启动类扫描一次就不用管了。

6.4 时间格式化不一致问题

医院管理系统里关于时间的字段特别多，挂号时间、就诊日期、出院时间，前端展示"2025-01-15 10:30"这样的格式，但后端输出默认会带一长串带毫秒的东西。

统一做法是在application.yml里配置全局的日期序列化格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

注意time-zone必须配成GMT+8，否则你查出来的记录时间和你数据库里存的时间会差8个小时，原因是MySQL连接串里的serverTimezone和Jackson序列化时区不一致。这个时区问题在国内项目里是高频事故，尤其是如果你把数据库部署在国内服务器、本地开发机时区不同，那酸爽程度更大。

6.5 简单有用的排查工具和思路

最后说排错的通用方法。后端日志是排查问题的第一突破口，启动项目时如果报错，先看控制台红色堆栈信息，把报错的关键英文翻译出来基本能定位方向。前端报错优先看浏览器开发者工具的Network面板，找到响应状态码，如果是500就是后端接口异常，如果404就要检查路由和接口路径是不是拼错。

对于SQL层面的问题，建议打开后端配置里的SQL日志输出，MyBatis-Plus在application.yml里配了日志级别后，控制台会打印每条执行的SQL语句，你拿这些SQL去数据库客户端执行一遍，就知道问题出在哪里。在mybatis-plus配置开启SQL日志的核心在于让SQL无处遁形，这在定位"前端报错但后端接口没报错"的问题时特别有用，省得瞎猜。

我在实际带项目的过程中体会最深的一件事：Java Web毕设项目，最怕的不是代码写不出来，而是不知道从哪个方向下手梳理。这套医院后台管理系统，核心价值不在于技术多新，而在于把SpringBoot+Vue的标准开发流程整个走了一遍，从表设计到接口，从接口到页面，从开发到部署，每个环节都有完整的参考。你拿到源码之后，千万不要满足于跑起来就完事，把这个项目里的每一个模块都改成自己能讲清楚的样子，把每一张表的结构吃透，把接口文档翻一遍，等到答辩那天，不管评委从哪个角度发问，你都能接得住。