SpringBoot+Vue+MySQL社区医院管理系统毕业设计完整指南

做毕业设计选“SpringBoot+Vue+MySQL社区医院管理系统”这个题目的同学，我每年都能碰到一批。这个题目火，不是因为技术多前沿，而是它刚好踩中了毕业设计最理想的几个要素：业务场景清楚、数据模型典型、前后端分离完整、扩展空间大。更关键的是，这类题目要求的“源码+数据库+论文+部署文档”整套交付物，每一块都有成熟打法，按部就班做就能出活。

这篇内容我结合自己带项目的实操经验，把完整链路拆开讲：课题怎么定位才不会被评审老师质疑、数据库怎么建才经得起提问、后端接口和前端页面怎么落地最快，以及论文、部署文档这些“看起来不重要但决定成败”的材料到底怎么写。无论你是准备开题、正在开发，还是已经写完代码卡在论文和部署上，这篇都能直接对着做。

1. 课题定位：社区医院管理系统为什么是毕业设计的“万金油”选题

1.1 社区医院和大型医院管理系统的本质区别

社区医院（社区卫生服务中心）的日常业务，核心就是门诊：居民来挂号、医生接诊、开处方、药房发药、收费结算。它和三甲医院的HIS系统完全不是一个量级，后者要管住院、手术、检验、影像、医保对接、多院区协同，一个毕业设计做那种规模绝对做不完。

社区医院管理系统的优势恰恰在“轻”：数据量不大，业务环节清晰，单表几万条记录就足够演示，但是麻雀虽小五脏俱全，该有的业务闭环一个不少。你做一套完整的门诊流程，评审老师一眼就能看明白系统“是干什么的、怎么干的”，这比做一个概念新颖但功能残缺的系统要稳得多。

从数据库设计的角度看，社区医院系统也特别“典型”。患者、医生、科室、药品、挂号、处方、收费、库存，这些表之间的关系既有1对多，也有多对多，还涉及状态流转和事务操作，能把经典业务场景全练一遍。对大多数本科生来说，这个复杂度刚好卡在“够得着、做得出”的位置。

1.2 核心业务闭环怎么划定

一套能拿得出手的社区医院管理系统，核心闭环至少包括：挂号、接诊、开方、收费、发药、退号退款。角色至少要覆盖管理员、医生、药房人员、收费员（或者由管理员兼任收费）。患者端可以做成小程序预约，但那是加分项，不建议放到第一版里。

我建议你在系统设计阶段就把“一条业务主线”画出来：患者挂某个医生的号 → 医生在待接诊列表里看到患者 → 点击接诊、填写病历和诊断 → 开具处方（含多条药品明细）→ 收费员对待收费处方进行结算 → 药房人员核对处方并发药 → 药品库存相应扣减。这条线走通，系统就能演示了，论文里也能画出清晰的业务流程图。

如果学校工作量的要求比较高，你可以在这个闭环之上扩展：医生排班管理、患者健康档案、药品效期预警、门诊量统计报表、操作日志。这些扩展模块都是“挂在大主干上的分支”，不影响核心流程，也能凑字数和截图。

1.3 功能边界：能砍的功能不要犹豫

很多同学一开始就把功能列得特别多，住院管理、检验管理、体检管理、预约挂号小程序全要做。等做到一半发现时间根本不够，核心功能反而稀碎，这是毕业设计最常见的翻车原因。

我的原则是：先做核心闭环，扩展模块只保留一到两个，其余全部写进论文的“系统展望”里。例如住院模块，你可以只建三张表（入院登记、床位管理、出院结算）做成一个只读演示页面，也可以在论文里明确说“本系统以门诊业务为核心，住院功能作为后续扩展方向”。答辩老师不会因为你不做住院而扣分，反而会因为你把门诊闭环做得完整、逻辑自洽而加分。

功能边界的另一个作用是控制数据库表数量。核心闭环加系统管理，十五张表左右就够。表太多，写SQL脚本和造演示数据的工作量会翻倍；表太少，又撑不起论文的数据库设计章节。这个数量是我实测下来工作量与展示效果最平衡的范围。

2. 技术选型：SpringBoot+Vue+MySQL这套组合背后的取舍

2.1 SpringBoot版本选择：先确认答辩环境的JDK

SpringBoot目前主流有两个大版本路线：2.7.x系列基于JDK8，3.x系列基于JDK17及以上。很多同学一上来就装最新的SpringBoot 3.3，结果发现自己电脑的JDK是8，或是学校机房、云服务器环境不支持JDK17，最后部署的时候痛苦不堪。

我个人的建议是：除非你的开题报告明确写了SpringBoot 3.x，否则优先选SpringBoot 2.7.x + JDK8。原因有三：第一，JDK8在绝大部分学校机房和低配云服务器上都能跑，兼容性最稳；第二，网上能搜到的资料、以及你大概率拿到的项目源码，大部分基于2.7或更老的2.3，二次开发成本低；第三，毕业设计答辩关注的是你“为什么这么选”，你完全可以说“为了保证部署环境的兼容性和第三方生态的稳定性，选择了成熟的2.7版本”，这个回答比“因为最新”要专业得多。

后端选型还要一并确认持久层框架。当前最推荐的是MyBatis-Plus 3.5.x，它既保留了MyBatis的灵活SQL，又提供了BaseMapper内置方法、分页插件和代码生成器，能帮你省下大量重复的CRUD代码。如果题目里没有强制要求手写MyBatis配置，不要自讨苦吃一个mapper一个XML手写。

2.2 Vue2还是Vue3，取决于你手上的源码基线

前端部分，新建项目就直接上Vue3 + Vite + Element Plus，这是目前社区最活跃、资料最多的组合。但如果你是从网上下载或购买的源码，先看清楚它用的是Vue2还是Vue3再动工。Vue2用Element UI，Vue3用Element Plus，这两个组件库的API有不小差异，强行混用会报一堆莫名其妙的错误。

还有一个容易忽略的点：Node.js版本。Vue3 + Vite项目通常要求Node 16以上，Vue2老项目可能反而在Node 18下会出现依赖兼容问题。拿到源码后，第一件事不是改代码，而是先跑一遍node -v和npm install，确认环境能装上依赖再说。我在实际接触的项目里，至少有三分之一的问题是node_modules没装干净或版本不对导致的，而不是代码本身有问题。

2.3 持久层与数据库工具链

MySQL版本建议8.0以上，字符集utf8mb4。如果服务器上只能装5.7也能跑，但要注意两个版本在驱动、时区配置上有差异：连接串里一定要带上serverTimezone=Asia/Shanghai和useSSL=false，否则启动报时区错误或SSL握手超时。

数据库可视化工具，Navicat、DBeaver、DataGrip都行，我更推荐DBeaver，免费且对MySQL 8支持好。用它做数据库设计、导出SQL、生成E-R图都方便。如果你需要快速生成实体类，还可以用MyBatis-Plus的代码生成器，或者直接在IDEA里用EasyCode插件，根据表结构一键生成entity、mapper、service、controller。注意：生成器生成的代码只是“能用”，业务逻辑还是要自己写，别指望一键生成完事。

2.4 前后端分离的正确性

“SpringBoot + Vue + MySQL”之所以是毕业设计标配，是因为它天然贴合前后端分离架构：前端通过HTTP接口调后端，后端通过MyBatis操作MySQL，三层各自职责清晰。答辩时你能把这套架构讲明白，本身就值不少分。

这里有一个“为什么选型”的经典回答思路：前后端分离不是因为它流行，而是它能解决协作和部署的实际问题——前端专注于页面交互，后端专注于业务逻辑与数据，两者通过JSON交互，可以独立开发、独立部署。你把这个理由写进论文的“相关技术介绍”章节，比单纯罗列技术名词要高级得多。

3. 数据库设计：十五张表撑起完整业务闭环

3.1 核心表清单与职责划分

社区医院管理系统的数据库表，我按业务域列在这里：

核心思路是“主表+明细表”和“流水表”两条线：处方主表保存一次开方的总状态，明细表保存每个药品的数量和单价；收费表统一记录所有收钱行为，并保留支付方式、支付时间、操作员。这样设计的好处是，统计报表直接对payment表聚合，非常方便。

3.2 从挂号到药品扣减的关系链条

整个系统最关键的表关系，我建议你画成一条链：

patient 对 registration 是 1 对 N；registration 对 medical_record 通常 1 对 1，可以用registration_id直接关联；一次接诊可开多张处方，所以medical_record对prescription是1对N；一张处方包含多个药品，通过prescription_item做中间关系，item里存drug_id、数量、单价；drug表要有库存字段和效期字段，发药或者收费时扣减。

这里我要特别提醒：处方明细里的单价必须在开方时从drug表带出并冗余存下来，不能只存drug_id然后每次去查实时价格。因为药品价格可能调整，如果以后改价，历史欠费和统计就会乱。毕业设计虽然不涉及历史审计，但你把这个冗余设计写进论文，答辩老师会认为你考虑到了业务细节。

3.3 状态字段：业务流转的核心

所有核心业务表都要有status字段，用整数表示状态，并在代码里用常量或枚举管理。以registration表为例：

• 0：已挂号（待就诊）
• 1：已就诊（医生已接诊）
• 2：已完成（处方已收费发药）
• 3：已退号

prescription表的状态是：未收费、已收费、已发药、已作废。这样设计之后，前端每一个列表都可以根据状态显示对应按钮：已挂号的显示“开始接诊”，已收费的显示“发药”，已退号的置灰。状态机是答辩时的高频考点，你只要能把这张流转图说清楚，基本就稳了。

挂号表中还要特别注意一个字段：registration_time和visit_date要分开。visit_date是就诊日期，registration_time是挂号的真实时间，两者含义完全不同。我见过有人只存一个create_time，导致医生工作台无法区分“今天挂号的”和“患者预约某天来就诊的”，功能直接没法做。

3.4 外键、索引与演示数据的准备

关于外键约束，我的实际经验是：建表脚本中可以不写物理外键，而是在Java代码层维护关系，E-R图里再画出逻辑关系线。理由有两个：一是物理外键会导致批量造数、删除数据时特别麻烦，尤其是表多之后；二是社区医院系统数据量不大，应用层维护完全够用。答辩如果被问“为什么不用外键”，就回答：考虑到系统扩展性与写入性能，采用应用层保证数据完整性，并通过索引保证查询效率。这个回答面试官挑不出毛病。

索引的建议：registration表要在patient_id、doctor_id、visit_date上建索引，因为这三个字段是查询最频繁的条件；payment表在payment_no上建唯一索引；prescription_item在外键字段上建普通索引。不需要把每张表的所有字段都建索引，索引过多反而拖慢写入。

演示数据一定要“像真的”。我常用的是：8个科室、15个医生、30个患者、50种药品、连续7天的排班，再加上一批挂号、处方和收费记录。药品名称用常见药，比如阿莫西林胶囊、布洛芬缓释胶囊、连花清瘟颗粒，别用abc1、abc2这种占位符。答辩演示时鼠标一点就看到一堆真实感强的数据，比空表有说服力得多。

4. 后端核心落地：SpringBoot接口设计与业务逻辑实现

4.1 分层架构与包结构

后端的包结构建议按职责分，不要所有类堆在一个包下面。一个参考结构：

com.hospital.management ├── common // 统一返回体、异常处理、工具类 ├── config // 拦截器、CORS、Jackson配置 ├── controller // REST接口层 ├── service // 业务层接口 │ └── impl // 业务实现 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体 ├── dto // 接收前端参数的模型 └── vo // 返回前端的视图模型

controller只负责接收参数、校验基础格式、调用service、返回Result对象；service里写真正的业务规则；mapper只做数据访问。很多同学把业务逻辑全写在controller里，一个登录接口二十几行，后面事务、异常处理全乱套，这是要避免的。

4.2 JWT登录认证：毕业设计首选的无状态方案

前后端分离场景下，用户认证我首推JWT。实现思路很清晰：登录接口根据用户名查出用户，用BCrypt校验密码，校验通过后生成token，把userId、username、roleCode放进去，设置过期时间（比如24小时），返回给前端。前端把token存到localStorage，每次请求在Authorization头带上，后端写一个拦截器统一解析token，解析成功后把用户信息放进ThreadLocal，controller里随时可取。

这里有两个常见的坑。第一，密码绝对不要明文存储，用BCryptPasswordEncoder加密，注册时加密、登录时匹配。答辩时几乎必问“密码怎么存的”，你答“BCrypt加盐哈希”，比答“MD5”好得多。第二，拦截器要放行登录接口和接口文档相关路径，不然你连登录都进不去。放行配置用白名单数组维护，写在Config里，别在拦截器里写死一长串if。

4.3 挂号接口：事务、并发与状态机

挂号接口是最能体现你工程能力的接口。它的请求参数是patientId、doctorId、visitDate、period（上午/下午），完整业务逻辑如下：

1. 校验患者存在，且当天同一时段没有重复挂号；
2. 校验医生排班存在，剩余号源大于0；
3. 生成registration记录，status设为已挂号；
4. 把医生排班的remaining_count减1；
5. 返回挂号成功信息。

这个方法必须加@Transactional(rollbackFor = Exception.class)，因为“生成挂号记录”和“扣减号源”是两个写操作，任何一个失败都要整体回滚，否则会出现挂号记录存在但号源没扣、或者号源扣了但挂号没生成的情况。

关于并发，我见过标准答案：扣减号源时不用“查出剩余号源，Java里减1，再update”的老写法，而是用一条SQL：

update doctor_schedule set remaining_count = remaining_count - 1 where id = #{scheduleId} and remaining_count > 0

这条SQL自带条件判断，影响行数为0说明号源已被抢完，直接抛业务异常。配合事务，就能在数据库层面保证并发不超卖。这个点你答出来，答辩现场基本就是加分项了。

4.4 收费接口：计算金额、扣库存、更新处方状态

另一个重头接口是处方收费。它串联了处方明细、支付流水和药品库存，逻辑至少包括以下步骤：

1. 根据prescriptionId查出处方和所有明细；
2. 从每条明细的price、quantity计算总金额（不要信前端传的金额）；
3. 校验处方状态是“未收费”；
4. 创建payment记录，生成唯一payment_no，状态设为已支付；
5. 更新处方状态为“已收费”；
6. 遍历处方明细，逐条扣减drug表的库存；
7. 写drug_stock_log库存流水。

扣库存同样用条件更新：update drug set stock_quantity = stock_quantity - #{num} where drug_id = #{drugId} and stock_quantity >= #{num}，影响行数为0就抛出“库存不足”异常并回滚整个事务。这个设计同时解决了“超卖”和“部分成功”两个问题，属于生产级的写法，放在毕业设计里属于降维打击。

4.5 统一返回体与全局异常处理

前后端联调时最怕接口一会儿返回{code,msg,data}，一会儿返回裸数组。建议一开始就统一Result对象：Result.success(data)、Result.fail(code, msg)，其中code是一个整数枚举，0为成功，其他为失败。

全局异常处理用@RestControllerAdvice加@ExceptionHandler实现。自定义一个BusinessException，业务规则不满足时直接throw new BusinessException("号源已满")；全局处理器捕获它后返回Result.fail，再补一个兜底的ExceptionHandler记录错误日志，防止把堆栈直接抛给前端。分页查询直接用MyBatis-Plus的Page对象，前端传current和size，后端返回总条数和记录列表，统一封装成IPage即可。

5. 前端实现：Vue管理后台的页面拆解与交互细节

5.1 前端项目初始化与目录结构

前端如果从零开始，推荐的项目结构是：

src ├── api // 每个模块的接口请求封装 ├── router // 路由配置 ├── store // Pinia状态管理 ├── views // 页面组件 ├── components // 公共组件 └── utils // request封装、工具函数

src/api里按模块拆文件，比如patient.js、registration.js、prescription.js、payment.js，每个文件导出几个方法，页面里只调用方法不直接写axios。这样后端接口路径一旦调整，只改一个文件就够了。

5.2 路由与角色权限控制

路由权限是毕业设计里相对亮眼的功能。做法是：路由表里定义一个公共路由（login、404），其余页面路由都要求登录后访问。在router.beforeEach守卫里做三件事：检查localStorage有没有token，没有就跳/login；有token但访问的是/login就跳首页；根据角色代码动态判断目标路由是否可访问，不可访问就跳404或者提示无权限。

菜单也可以按角色动态生成：登录接口返回角色信息，前端根据角色过滤菜单数组。例如医生角色只显示“医生工作台”“我的排班”，管理员角色显示全部菜单。这个功能不需要做得多复杂，能演示出“不同角色登录看到不同菜单”的效果就够了。

5.3 三个核心页面的交互拆解

挂号登记页：一块患者区域、一块医生区域、一块日期时段区域。患者和医生都做成分页搜索下拉框，选中医生后联动显示该医生当天的排班剩余号源，如果剩余为0，日期选择器对应日期禁用。提交成功后弹窗提示挂号成功并显示号序。

医生工作台：上半部分是待接诊列表，只查当前登录医生、状态为“已挂号”的记录。点击“接诊”打开接诊弹窗，弹窗里包含病历信息表单和一个处方明细表格。表格每一行可以选药品、填数量，选中药品后自动带出单价和库存，数量超库存时给红色提示。保存后调用后端接口生成病历和处方，然后刷新列表。

药房发药页：查询状态为“已收费”的处方列表，点开能看明细，确认发药后调用接口。这一页虽然简单，但是一定要和后端确认清楚：库存到底是在收费时扣，还是在发药时扣。我见过很多项目两边对不上，收费时扣了一次，发药又扣一次，库存直接变负数。

5.4 联调阶段最容易踩的四个坑

第一个坑是跨域。开发环境下Vite配置server.proxy，把/api代理到后端http://localhost:8080，这样前端请求路径写/api/...就不会有跨域问题。生产环境用Nginx把/api反向代理到后端jar的端口，也是一样的思路。前端baseURL始终用相对路径/api，不要在axios里写死http://localhost:8080。

第二个坑是Long型主键精度丢失。MyBatis-Plus默认主键用雪花算法，生成的ID是19位数字，前端JavaScript的Number精度不够，会导致ID最后几位变成0。解决方法是后端给Long字段加@JsonSerialize(using = ToStringSerializer.class)，或者全局配置Jackson把Long统一转成String。这个坑如果你不处理，列表页点击编辑的时候传过去的ID是错的，接口会莫名其妙查不到数据。

第三个坑是日期格式。后端LocalDateTime默认序列化出来是数组形式，前端显示全是乱码。要在配置里统一指定格式：日期时间是yyyy-MM-dd HH:mm:ss，日期是yyyy-MM-dd。前端日期选择器也要加value-format，否则传参格式对不上，查询等于白查。

第四个坑是状态字段直接裸显示。前端拿到status=0就显示“0”，很丑。建议在utils里写一个字典映射函数，比如formatRegistrationStatus(status)，后端返回状态码，前端统一转中文。展示上会比直接在模板里写一堆v-if清爽得多。

6. 论文与部署文档：毕业设计交付材料的写作框架

6.1 论文怎么组织：从摘要到测试的写作顺序

论文标题建议写成《基于SpringBoot和Vue的社区医院管理系统的设计与实现》。整体结构一般是这样：

摘要：两段话，第一段写背景（社区医疗信息化需求、传统人工挂号效率低），第二段写系统做了什么、技术栈是什么、达到什么效果。关键词选“社区医院；管理系统；SpringBoot；Vue；MySQL”五个就够了。

正文顺序：绪论（研究背景与意义、国内外现状、主要研究内容）→ 相关技术介绍 → 需求分析（用例图、功能需求、非功能需求）→ 系统设计（架构图、功能模块、数据库设计）→ 系统实现（每个功能模块的截图和关键代码）→ 系统测试（测试环境、测试用例、测试结果）→ 总结与展望 → 参考文献 → 致谢。

写的时候有个技巧：先写系统实现，再回头写其他章节。因为系统实现是对着真实代码描述的，最不容易卡壳；写完之后开题报告里的背景、意义、需求分析都有实际依据了。

6.2 三张图定乾坤：架构图、功能模块图、E-R图

论文里最重要的三张图分别是系统架构图、功能模块图、数据库E-R图。系统架构图建议画四层：用户层（浏览器中的Vue管理后台）→ 接入层（Nginx反向代理）→ 业务层（SpringBoot的Controller、Service、Mapper）→ 数据层（MySQL）。这张图能讲清楚请求是怎么从前端走到数据库的。

功能模块图就按你实现的模块画：系统管理、患者管理、挂号管理、门诊病历、处方与收费、药品管理、统计报表。E-R图画核心业务表之间的关系，建议用DBeaver或Navicat的逆向模型生成，再稍作美化。这三张图不要截网图，能自己画尽量自己画，答辩老师大概率会指着图问你细节。

6.3 部署文档：一份能让老师照做就跑的文档

部署文档的写作目标不是“你自己能跑”，而是“任何一个拿到项目的人照着做都能跑”。内容至少包括：

• 环境要求：JDK1.8或17、Maven 3.6+、Node 16+、MySQL 5.7+/8.0+、Nginx（可选）；
• 数据库导入：mysql -u root -p < hospital.sql，或通过Navicat运行SQL脚本；
• 后端启动：mvn clean package打包成jar，java -jar xxx.jar运行；
• 前端构建：npm install后npm run build，把dist目录部署到Nginx；
• Nginx配置：location /api反向代理到后端端口，location /指向dist目录。

文档里每个命令都要写全，不要写“安装JDK”就说一句“安装JDK”，要写清楚下载哪个版本、怎么配置环境变量。我见过太多部署文档写到一半默认读者“懂一点Linux”，结果老师跟着文档做都起不来。

6.4 交付前的材料自检清单

毕业设计交付的通常不是一个源码包，而是一个完整材料包。交付前逐项核对：

• 数据库SQL脚本能不能在一台全新电脑上直接导入成功；
• SQL脚本里内置的默认账号、密码能不能正常登录；
• 后端代码执行mvn clean package能不能一次通过；
• 前端npm install加npm run build能不能出dist；
• 部署文档里的路径、命令跟实际是否一致；
• 论文里的截图和最终代码是否为同一版本。

我在验收学生项目时，最常见的三个硬伤是：项目能跑但数据库脚本忘了交、SQL里有同学自己的绝对路径、部署文档写的密码和代码里不一致。这些都属于“技术没问题但交付不合格”的情况，一旦被卡反而最冤。

7. 答辩与验收：做完全部功能之后的自我检查

7.1 一条演示主线：挂号到报表的自然流程

答辩演示最怕东点一下西点一下，老师完全不知道系统逻辑。我建议准备一条固定演示路径：

用管理员账号登录 → 进入首页看统计概览 → 打开患者管理新增一个患者 → 到挂号管理给这个患者挂某个医生的号 → 切换医生账号登录 → 在医生工作台看到待接诊患者 → 接诊、写病历、开处方 → 切换收费员账号 → 对待收费处方进行收费 → 切换到药房账号 → 发药 → 回到管理员首页 → 查看门诊量统计和药品库存变化。

这条路径把四个角色、七个页面、两次账号切换串起来，全程不超过八分钟。演示的时候可以故意展示一次“号源已满”或“库存不足”的报错，反而比一路顺利更有说服力，因为这恰好证明业务规则生效了。

7.2 针对三个技术点的高频追问

答辩老师最常追问的是认证、事务、数据库设计。认证问题的标准回答：JWT无状态、支持跨域、服务端无需保存会话；缺点是无法主动吊销，通过缩短过期时间来缓解。事务问题的标准回答：挂号、收费都涉及多表写操作，必须加@Transactional，并用条件更新解决并发超卖。数据库设计问题的标准回答：先讲业务闭环，再讲每张表的作用，最后讲状态字段和索引策略。

还有一个容易被问到的是“测试做了哪些”。不要只说“测了功能正常”，建议准备一份功能测试用例表：编号、测试模块、操作步骤、预期结果、实际结果。比如“库存不足以扣减时，系统给出提示并回滚”，预期是“提示库存不足，处方状态保持未收费”，实际结果“通过”。这一套说完，既展示了测试方法，又侧面验证了事务代码。

7.3 现场翻车急救清单

哪怕准备再充分，答辩现场也可能抽风。记住几个高频问题的急救方案：

数据库连不上：先看后端日志里的报错，确认MySQL服务是否启动，然后核对yml里的host、port、username、password，MySQL 8要把useSSL=false和serverTimezone加上。

前端白屏或404：如果是history路由，刷新后404，就在Nginx配置里加try_files $uri $uri/ /index.html;。如果前端直接跑在node开发模式下，确认后端是否允许跨域，以及/api代理是否指向了正确的后端端口。

后端启动失败：多数是端口被占用，用netstat -ano | findstr 8080（Windows）或lsof -i:8080（Linux）找到占用进程，换掉后端yml里的server.port，或者杀掉占用进程即可。

接口返回500：别慌，看后端控制台日志，最常见的是SQL里关联字段名写错、类型不匹配、空指针。先把堆栈中第一个“Caused by”读出来，基本就能定位，别盯着整段红色日志发呆。

最后说一点带项目的真实体会：毕业设计真正拉开差距的，往往不是谁的功能更多，而是谁的交付物更完整、谁对“为什么这样设计”回答得更清楚。源码、数据库、论文、部署文档这四样东西，前两样决定你能不能跑起来，后两样决定你能不能过。把精力平均分配好，把每一样都当成正式交付物去打磨，这比堆一堆花哨功能要划算得多。