企业官网建设流程全解析

做毕设选了“基于Spring Boot的社区医疗健康管理系统”，或者还在观望要不要选这个方向？作为一个带过几届毕业设计、自己也完整走过一遍开发全流程的人，我可以直接告诉你：这个题目的性价比极高。既有技术深度能拿得出手，又不像AI识别、高并发秒杀那种方向一样容易把自己写进死胡同，而且源码、文档、演示视频一整理，整套材料出来非常规整，答辩时老师问什么你都能接得住。

这篇文章我把整个项目的里里外外拆开讲——从为什么选Spring Boot、系统核心模块怎么设计，到数据库表怎么建、接口怎么写、JWT登录怎么弄，再到小程序端、健康数据采集、文档怎么写，甚至答辩老师最爱问的几个陷阱问题，我都一次性给你梳理清楚。文章不会只是扔一个源码链接完事，我会把里面最容易卡住你的点全部标出来，让你拿到手不是“看不懂的代码”，而是“能讲清楚的作品”。

1. 系统整体设计与技术选型，为什么Spring Boot是这个题目的最优解

1.1 社区医疗的现实场景与技术拆解

社区医疗和大型三甲医院的信息化系统有个本质区别：三甲医院需要的是超大规模并发、复杂业务流程、多系统集成，而社区医疗面向的是辖区居民、慢性病患者、老年人群体，核心诉求是“小、快、灵”——小规模部署、快速建档、灵活随访、方便基层医护操作。

这个题目表面看是一个管理系统，实际上是两套逻辑的融合：一套是面向医护人员的业务后台，管居民档案、管预约、管随访记录；另一套是面向居民的服务入口，查档案、约医生、看健康资讯。两套逻辑共用同一个数据底座、同一套权限体系，但前端形态和使用场景完全不同。

所以技术选型的核心矛盾就一句话：怎么用最成熟稳定的方案，在最短时间内把两套逻辑跑通，而且不能让代码变成一坨自己都看不下去的“大杂烩”。

1.2 为什么选Spring Boot而不是Spring Cloud或SSH

很多同学纠结要不要上微服务，我的建议非常直接：单体的Spring Boot是你唯一应该考虑的方案。理由有三个层面。

第一，业务规模不过载。社区医疗系统的用户量级通常是几万居民、几十个医护工作人员，支撑这个规模的业务一台普通服务器绰绰有余。微服务带来的注册中心、配置中心、网关、分布式事务这些复杂度，在这种场景下纯属帮倒忙。

第二，毕设周期不允许。你要在三个月内完成可运行的系统加一篇像样的论文，如果时间花在折腾Nacos、OpenFeign、Sentinel这些组件上，核心业务代码反而写不完。Spring Boot的自动配置、内嵌Tomcat、起步依赖这套机制，能让你把80%的精力放在业务逻辑而不是环境适配。

第三，答辩时你能讲清楚。老师问到“你这个系统架构是什么样的”，如果你能清晰说出“单体的Spring Boot应用，按模块分包，通过JWT做无状态认证，数据存储用MySQL”，这个回答比含糊其辞地说“用了微服务”要好得多。微服务不是不能用，而是你要能解释清楚为什么需要它——解释不清楚的点，就是答辩扣分的点。

1.3 技术栈明细：一套能落到纸面上的组合

我推荐的这套技术栈最大特点是：每个组件都是市场主流，每个选择都能在论文里写出“为什么选它”的三个理由。

后端开发语言用Java 8或Java 11，框架用Spring Boot 2.7.x。为什么不用Spring Boot 3？因为3.0强制要求JDK 17，有些老代码和插件兼容性会出问题，而且很多网上资料基于2.x写，你照着排错也方便。

持久层用MyBatis Plus，它的核心价值是单表CRUD不用写SQL，内置分页插件一键搞定分页，还能和Spring Boot无缝整合。不用JPA的原因很实际：社区医疗系统里多表关联查询特别多，MyBatis的XML写复杂SQL更直观，JPA的规范语法反而绕。

数据库选MySQL 8.0，这是毫无疑问的。权限认证用JWT（JSON Web Token），前端缓存用户状态，后端无状态校验，适合这种前后端分离的项目。

前端有两条线：管理后台用Vue 2 + Element UI，这是老牌组合，组件全、资料多、上手快；居民端用微信小程序原生开发，不引入uniapp，因为项目的核心是后端管理系统，小程序只是辅助功能，原生开发调试方便，发布流程也简单。

接口文档工具用Swagger（springfox或springdoc）。做毕设特别需要这东西，因为答辩时老师喜欢随手点几个接口看返回数据，Swagger的调试页面演示效果非常直观，比自己拿Postman现场敲地址强太多了。

2. 核心功能模块拆解，社区医疗到底要管什么

2.1 系统角色的三权分立设计

社区医疗健康管理系统涉及三类角色：系统管理员、医护人员、居民用户。这三种角色对系统的诉求完全不同，所以模块设计的第一步是把权限边界划清楚。

系统管理员管的是基础数据，比如社区信息、用户账号的审核禁用、数据字典维护、系统日志查看。医护人员是系统的高频使用者，他们需要一个简洁好用的工作台：查居民档案、处理预约、录入随访记录、管理排班。居民用户是小程序端的使用者，他们只关心三件事——自己或家人的档案能不能查到、怎么约社区医生的号、社区最近有什么健康活动。

权限设计的落点是Spring Security + JWT。用户在登录时被赋予角色标识，每次请求经过JWT过滤器解析后，Spring Security根据角色判断该接口是否可访问。比如/api/doctor/followup/**只允许医护角色访问，/api/admin/**只允许管理员访问。这种基于角色的访问控制模型（RBAC）是最经典的实现思路，论文里能写清楚，答辩时也能画出对应的流程图。

2.2 居民电子健康档案模块，系统的地基

社区医疗管理的核心资产是居民健康档案，没有档案的系统只是一个空壳。档案模块的数据结构设计直接决定后面所有功能好不好做。

档案信息分成三层：基础信息层包含姓名、性别、出生日期、身份证号、联系方式、家庭住址；健康信息层包含血型、过敏史、既往病史、家族病史、手术史；管理信息层包含建档医生、建档时间、所属社区网格、档案状态。

建档流程要考虑实际困境：社区里很多老年人是子女帮他们线上建档的，所以“新增档案”功能里一定要有“与户主关系”这个字段。老人自己来建档，信息可能说不全，医生在后台帮他补齐。所以后台管理端要有一个“代建档”入口，前台小程序端也能填写完整表单，两条路都走通，数据才能收集上来。

档案列表的展示要注意一个问题：身份证号是敏感信息，列表页默认只显示中间四位带星号的脱敏数据，点击详情再查看完整信息。这个细节放进论文里能作为“用户隐私保护”章节的亮点，比空谈安全性更有说服力。

2.3 预约挂号与门诊管理的状态流转

预约挂号是居民使用频次最高的功能，也是最能体现系统设计功力的模块。它有一个核心难点：资源冲突。

社区医院门诊资源有限，一个医生半天只看多少个号是固定的。设计预约表时，必须把“号源库存”的字段设计进去。我的方案是在doctor_schedule表里存排班时段和总号数，在appointment表里存预约记录。每次用户提交预约，先查doctor_schedule的remaining_count是否大于0，大于0才能插入预约记录，同时把remaining_count减一。

这里有个必须处理的并发问题：两台手机同时抢同一个号源，如果代码是先查询再更新，两个请求可能都查到剩余1个号，然后都执行成功，数据就超卖。解决这个问题的标准做法是使用MyBatis Plus提供的乐观锁插件，在doctor_schedule表加一个version字段，更新时SET remaining_count = remaining_count - 1 WHERE id = ? AND remaining_count > 0，通过数据库行的原子操作保证不会超卖。

这个点的技术含量足够在答辩时单独讲三分钟。老师问“你考虑过并发吗”的时候，你能把数据库层面的解决方案讲清楚，这一段就是高光时刻。

门诊业务流程还包括：预约成功后的状态流转——待就诊、已完成、已取消；患者到院后医生在后台点“确认接诊”、填写门诊诊断、开具处方或检查建议。整个流程的状态机设计，建议在数据库设计文档里画一张状态流转表，这也是论文里的加分图。

2.4 慢病随访管理，社区医疗的特色功能

社区医院和三甲医院最大的区别在于：大医院看完病就走，社区医院要管到底。所以慢病随访模块是这个系统的灵魂功能。

高血压、糖尿病是社区慢病管理的两个大头。系统里的随访记录表要包含：随访方式（门诊/电话/上门）、随访日期、血压值或血糖值、用药情况、生活方式评估、是否转诊上级医院。

随访任务的来源有两种，一种是医生主动发起——看到某个患者好久没来随访了，在系统里登记一条随访记录；另一种是系统自动提醒——根据随访计划表的日期，在医生工作台生成“今日待随访”列表。

自动提醒的实现在论文里可以写成“基于Quartz定时任务”的模块：每天早上8点执行一次定时任务，扫描随访计划表中到达计划日期且未完成的记录，生成一条待办通知。

这个模块要做得好，关键在于“数据联动”的思路。随访记录里的血压、血糖数据，不应该只是存进一张表就完了。这些数据和居民健康档案的“健康指标”字段是关联的，每次随访后，最新的指标值要回写到档案表，这样居民打开小程序查看档案时，看到的永远是最新的健康评估数据。

3. 数据库设计与核心表结构，建表之前先想清楚这三件事

3.1 从业务名词到数据实体的映射

数据库设计是很多同学的第一步，也是踩坑最多的一步。我的建议是：千万别上来就建表，先把业务功能里的所有名词列出来，然后把名词之间的关系理清楚。

社区医疗健康管理系统的核心实体包括：用户（user）、居民档案（resident_profile）、医生排班（doctor_schedule）、预约挂号（appointment）、门诊记录（outpatient_record）、随访记录（follow_up_record）、健康资讯（health_article）、系统字典（sys_dict）。这些实体之间的关系用一句话概括：用户拥有档案，档案关联预约和随访，医生根据排班接收预约，门诊记录是预约的结果。

我用PowerDesigner或Navicat的数据建模工具画ER图，这个图最后导出为图片直接放进论文第三章“数据库设计”里，一眼就能看出你是认真做过设计的。

3.2 核心表的字段设计要点

用户表（sys_user）：主键id，用户名，密码（BCrypt加密后存储），盐值，姓名，手机号，角色标识（admin/doctor/resident），状态（0禁用1正常），创建时间。

注意密码字段的加密必须用BCrypt，论文里写“采用不可逆加密算法存储用户密码”是一句值得写的话，实际代码里就是用Spring Security自带的BCryptPasswordEncoder，不要用MD5——MD5无盐值加密在安全评审里直接被判为不合格。

居民健康档案表（resident_profile）：主键id，关联user_id，姓名，性别，身份证号，出生日期，血型，过敏史，既往病史，家族病史，婚姻状况，职业，联系人姓名，联系人电话，所属社区，建档医生id，建档时间，档案状态。

医生排班表（doctor_schedule）：主键id，医生id，排班日期，开始时间，结束时间，总号数，剩余号数，排班类型（普通门诊/专家门诊），状态（available/full/off）。

预约挂号表（appointment）：主键id，排班id，患者id，预约时间，预约日期，患者姓名，患者电话，就诊状态（待就诊/已完成/已取消），取消原因，备注。

随访记录表（follow_up_record）：主键id，居民id，随访日期，随访医生，随访方式，血压值，血糖值，用药情况，生活方式评估，是否转诊，下次随访日期，随访结论，备注。

3.3 索引设计里的小心机

数据量不算大的系统，索引别建太多，但要建得精准。我的建索引原则是：查询条件里出现的字段才建索引，WHERE和ORDER BY高频字段优先加索引。

实际建了这几个索引：appointment表的schedule_id加索引，因为要通过排班查预约列表；appointment表的resident_id加索引，因为居民要查自己的预约记录；follow_up_record表的resident_id加索引，因为档案详情页要加载随访历史；doctor_schedule表的doctor_id + schedule_date建联合索引，因为医生工作台按日期范围查排班是最高频的查询。

索引不是越多越好——每条索引在插入数据时都会增加写操作的开销，这个权衡在论文里值得简单提一句，显得你懂数据库原理，而不只是会用工具。

4. 核心功能实现与关键代码，从零到一跑通整个系统

4.1 项目初始化与基础环境搭建

这一节写给从零开始搭项目的同学。如果你用的是免费领取的源码，那么按下面的步骤把环境跑起来，基本不会出问题。

第一步，装Java。必须装JDK 1.8，不要装最新的JDK 17或21，因为老项目的编译配置经常依赖JDK 8的特性。装完以后在命令行输入java -version确认版本显示是1.8。

第二步，装IDE。用IDEA社区版就够用，免费而且支持Spring Boot项目开发。打开IDEA，File -> New -> Project from Existing Sources，选择你下载的项目根目录，等Maven把依赖全部下载完。如果下载特别慢，在pom.xml的repositories节点加一个阿里云镜像：

<repositories> <repository> <id>aliyun</id> <url>https://maven.aliyun.com/repository/public</url> </repository> </repositories>

第三步，建数据库。用Navicat或命令行新建一个名为community_health的数据库，字符集选utf8mb4，然后执行项目里搭好的sql脚本，把表和初始数据导入。

第四步，改配置文件。打开application.yml，把数据库用户名、密码改成你自己的，然后运行CommunityHealthApplication.java里的main方法，看到“Started CommunityHealthApplication”就说明成功了。

注意，如果你拿到的源码是多个版本（比如有Vue后台和小程序两个文件夹），先启动后端，再启动前端，前端配置的baseUrl指向后端的8080端口，这点不要搞反。

4.2 JWT认证的完整实现链

JWT是这个系统权限体系的核心，也是答辩时必讲的重点。它解决了什么问题？传统Session方案需要服务端保存登录状态，对于前后端分离的架构不够友好；JWT把用户身份信息加密成一段token，客户端保存token，每次请求带上token，服务端验证签名通过就相信请求者身份。

代码实现分为三步。

第一步，登录接口生成token。用户输入用户名密码，通过AuthenticationManager验证，成功后用JwtUtil工具类生成token返回给前端：

public Result login(@RequestBody LoginRequest request) { User user = userService.authenticate(request.getUsername(), request.getPassword()); if (user == null) { return Result.error("用户名或密码错误"); } String token = jwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); return Result.success().put("token", token).put("userInfo", user); }

第二步，过滤器拦截请求校验token。写一个JwtAuthenticationFilter，继承OncePerRequestFilter，在doFilterInternal里从请求头的Authorization字段取token，解析成功就把用户信息放入SecurityContext，Spring Security后续的权限判断基于这个上下文：

public class JwtAuthenticationFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); if (jwtUtil.validateToken(token)) { UsernamePasswordAuthenticationToken authentication = jwtUtil.getAuthentication(token); SecurityContextHolder.getContext().setAuthentication(authentication); } } chain.doFilter(request, response); } }

第三步，后端配置哪些接口需要认证、哪些接口开放。放行登录接口、注册接口，其他接口都要带token才能访问。

这里有一个常见坑要提醒你：Swagger接口文档的路径必须放行，否则你在浏览器里打开swagger-ui.html的时候，因为没带token，页面能打开但点击接口调试会全部401。解决办法是在SecurityConfig里把/swagger-resources/**、/v2/api-docs、/swagger-ui.html这几个路径加入白名单。

4.3 预约挂号接口的核心逻辑

预约挂号的Service层代码是整个系统业务复杂度最高的地方，也是检验你是否真正理解业务的好素材。

@Transactional public Appointment bookAppointment(Long scheduleId, Long residentId) { DoctorSchedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null || schedule.getStatus().equals("off")) { throw new BusinessException("该排班已停诊"); } if (schedule.getRemainingCount() <= 0) { throw new BusinessException("号源已满"); } Appointment appointment = new Appointment(); appointment.setScheduleId(scheduleId); appointment.setResidentId(residentId); appointment.setStatus("待就诊"); appointmentMapper.insert(appointment); int updated = scheduleMapper.decreaseRemainingCount(scheduleId); if (updated == 0) { throw new BusinessException("该号源已被抢完，请刷新重试"); } return appointment; }

注意这里先插入预约记录，再扣减号源。如果先扣号源后插入记录，插入失败会导致号源被白白扣掉；如果先插入后扣减，扣减失败可以通过抛异常让整个事务回滚，预约记录也不会残留。@Transactional注解保证这两步要么都成功，要么都失败。

这个代码片段在论文“核心功能实现”章节放出来，老师说看不懂逻辑的概率极低，但你要能用自己的话把上面的流程讲一遍——建议把“先插入预约记录，再通过条件更新扣减号源，更新影响行数为0说明已经抢完”这句话背下来。

4.4 慢病随访与健康档案数据联动的实现

随访记录的保存接口有一个动作：保存完随访数据后，要更新居民档案里的健康指标字段。这样做的代码逻辑不复杂，但体现了系统的数据设计思路——随访结果要反哺档案，档案是居民的“健康数据中心”。

public void saveFollowUp(FollowUpRecord record) { followUpMapper.insert(record); ResidentProfile profile = profileMapper.selectById(record.getResidentId()); if (record.getBloodPressure() != null) { profile.setLatestBloodPressure(record.getBloodPressure()); } if (record.getBloodSugar() != null) { profile.setLatestBloodSugar(record.getBloodSugar()); } profileMapper.updateById(profile); }

这个设计值得你在论文里写一段说明：避免了医生在系统里重复录入数据——随访结果同步更新到档案，减少基层医生的工作量。社区医疗系统落地的核心痛点就是基层医生不愿意用系统，嫌麻烦，数据联动是提升系统易用性的关键手段之一。

4.5 健康数据的采集与展示，从单一系统到数据闭环

如果你拿到的源码里附带了健康数据采集相关的功能（比如可穿戴设备接入、健康指标上传），这部分可以让整个项目的立意上一个档次。数据采集的思路分两种。

第一种是设备数据接入。居民佩戴的智能手环可以采集心率、步数、睡眠数据，设备厂商通常提供开放API。系统通过定时任务每天从API拉取数据，存入健康数据表。这类接口需要处理鉴权——设备厂商会给一个appId和secret，后端保存凭证，每次调用先获取accessToken再请求数据。

第二种是手动录入上报。居民在小程序端手动填写血压、血糖值，提交后同步到数据库。这种方式的好处是不依赖硬件，适合没有可穿戴设备覆盖的老年人群体。

数据采集上来以后，可视化的价值才发挥出来。居民在小程序的健康数据页面看到最近七天的血压曲线图，比看到一行行数字直观得多。ECharts在小程序端的实现用ec-canvas组件，后端提供查询接口返回数组格式的日期和数值，前端渲染成折线图。

这一部分做得好，系统就从一个“挂号台账”升级成了“连续监测的健康管理工具”，论文的深度和创新点都能从这里提炼。

5. 小程序端与辅助功能扩展，怎么让居民端好用不鸡肋

5.1 小程序端的功能定位与技术实现

小程序端不是后台管理系统的简单搬运，它承担的功能定位是“轻量高频”——登录查看健康档案、预约医生、查看资讯。这三个功能恰好对应社区居民的三大高频诉求。

技术实现上我推荐用原生小程序开发，不用uni-app。理由很简单：项目核心是Spring Boot后端管理系统，小程序只是其中一个展示端，原生语法就是JavaScript + WXML + WXSS，调试工具微信开发者工具直接打开就能跑，省去了跨端框架的编译链路。

小程序端和后端的接口交互要走HTTPS——微信小程序上线时强制要求后台接口域名必须配置在微信公众平台的服务器域名白名单里，必须是备案过的HTTPS域名。如果你只是在本地开发调试，在开发者工具里勾选“不校验合法域名”即可。

5.2 健康资讯模块与合规采集思路

健康资讯模块是提升社区医疗服务黏性的内容型功能，社区医院定期发布疫苗接种通知、慢性病防治知识、季节健康提示之类的科普内容。资讯内容的管理在后台管理端——管理员发布文章，居民在小程序端浏览。这个功能本身就是典型的CMS（内容管理系统）逻辑，技术含量适中，但社区医疗场景下资讯内容具有公卫宣教的现实意义，适合写进系统的社会价值部分。

如果你想把资讯内容做得更丰富，而且拿到手的源码里带了爬虫相关的功能（这正好对应标题里的“爬虫”关键词），有一点必须提醒你：爬虫采集健康资讯必须守住合规红线。只抓取公开的健康科普门户、政府卫生机构官网发布的内容，明确遵守robots.txt，控制请求频率避免给对方服务器造成压力，采集到的内容必须经过审核才能发布。不碰任何需要付费、登录、验证码绕过、加密逆向的内容，这是底线中的底线。论文里可以用一节来写“资讯内容采集策略与合规性设计”，既展示技术能力，又体现你的工程伦理意识。

5.3 消息通知模块，把用户拉回系统的关键

消息通知是很多同学容易忽略的功能，但它在社区医疗场景里的价值非常大。接种疫苗的第二针提醒、慢病患者到了随访日期、医生临时停诊，这些都需要触达用户。

实现方案分两步：系统内通知存表，通过WebSocket实时推送或前端轮询拉取；短信通知集成阿里云短信服务，在代码里封装一个SmsUtil工具类。小程序端则通过订阅消息实现，用户在预约成功后勾选订阅、同意接收提醒，到时间节点系统调用微信接口推送订阅消息。

做这个功能要考虑一下消息的模板类型要提前在微信公众平台申请，审核需要1-2天，不要拖到最后才搞。

6. 常见问题与排查技巧，这些坑我都替你踩过了

6.1 环境与启动阶段的高频故障

启动报错“数据库连接失败”是最高频问题，九成是application.yml里的数据库配置和本地环境不一致——用户名、密码、端口、数据库名四个字段逐项核对，另外确认MySQL服务已启动。如果连的是远程服务器，还要检查云服务器的安全组是否放行了3306端口。

还有一种非常隐蔽的错误：访问接口返回404但其他接口正常。这种情况通常不是代码问题，而是Controller类没有加@RestController注解，或者类的包路径没有被Spring Boot扫描到。项目启动类的@SpringBootApplication默认扫描的是该类所在包及其子包，如果你把Controller放在了其他目录下，Spring根本不知道它的存在。解决办法是在启动类加@ComponentScan指定包路径，或者把所有类都放在启动类所在包的子包里。

6.2 前后端联调时的跨域与请求头问题

后端写好了，前端一请求就报跨域错误，这是前后端分离项目的必经之路。解决办法在Spring Boot后端加一个CorsConfig配置类：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

注意一个细节：addAllowedOriginPattern和addAllowedOrigin写法有点区别，Spring Boot 2.4以后的版本用allowedOriginPatterns方法，用allowedOrigins("*")在某些版本会报错。这个坑网上资料新旧混杂，很容易踩。

联调时还有一个小坑：前端请求带token，如果代码里写的是headers: {'Authorization': token}，而后端过滤器中写的是request.getHeader("Authorization")，大小写不敏感所以没问题。问题通常出在token本身带了空格——有些同学在拼接请求头时写成了Bearer后面多了个空格，导致token解析失败。可以用token.replace("Bearer ", "")的方式清理，但更推荐前端就传干净token，后端只负责解析。

6.3 源码拿到手后居然跑不起来的排查顺序

免费领取的源代码通常来自不同来源，质量参差不齐。如果你发现项目跑不起来，按这个顺序排查绝对不会白忙。

第一，看文档。源码包里有没有README或部署说明文档，先按文档指示操作。

第二，对版本。pom.xml里声明的Java版本、Spring Boot版本、MySQL驱动版本、MyBatis Plus版本，和你的本地环境是否匹配。最常见问题是代码用JDK 8的写法，但你的环境是JDK 17，导致编译报错。

第三，清依赖。IDEA里执行mvn clean install，把target目录清空重新编译打包。Maven仓库里的依赖冲突也会导致奇怪的问题，如果报错信息指向某个类找不到，可以用mvn dependency:tree查看依赖树，手动排除冲突的传递依赖。

第四，看前端配置。Vue或其他前端项目启动后，确认proxyTable或baseURL配置的后端地址能访问。小程序端要看app.js或request.js里的baseUrl，本地调试建议把域名配置直接用http://localhost:8080。

如果以上全都检查了还是跑不起来，还有一条保底路径：把项目导入IDEA后，右侧Maven面板先点“Reload All Maven Projects”再重新运行。Maven项目不重新导入，依赖变更不会被加载，这个问题非常容易忽略。

6.4 答辩前的自查清单与实战经验

答辩时老师不问代码细节，他们最常问的是五个问题，你可以提前把答案准备好。

“为什么做这个系统？”回答思路：社区医疗是国家分级诊疗体系的基层环节，但目前很多社区医院的信息化建设落后，居民健康档案还停留在纸质阶段，系统通过数字化手段解决建档难、随访难、预约难三个实际问题。

“系统有什么难点？”回答思路：预约挂号的并发控制（条件更新防超卖）、JWT无状态认证与权限管理、慢病随访数据的关联联动。把前面第3节讲的内容用自己的话复述一遍。

“为什么选Spring Boot？”回答思路：配置简化、内嵌服务器、生态成熟、和MyBatis Plus整合方便，单体架构足够支撑社区级业务场景。

“数据怎么保证安全？”回答思路：密码BCrypt加密、JWT过期时间校验、身份证号脱敏展示、角色权限控制、无SQL注入——MyBatis的#{}预编译机制本身就能防注入。

“你还有什么可扩展的想法？”回答思路：接入可穿戴设备实时监测、对接上级医院的双向转诊、引入视频问诊。这一个问题答好了，等于给整场答辩画了一个漂亮的句号。

7. 文档、演示与完整交付，别让代码之外的东西拖后腿

7.1 毕业论文的章节结构与写作节奏

论文有固定套路可循。第一章绪论写研究背景、国内外现状、研究内容、论文结构。第二章相关技术介绍写Spring Boot、MyBatis Plus、Vue、微信小程序、JWT这些技术栈的简介。第三章系统分析写可行性分析、功能需求分析、角色分析、用例图。第四章系统设计写总体架构、功能模块设计、数据库设计、类设计。第五章系统实现写每个功能的实现界面截图和核心代码。第六章系统测试写测试用例和结果。

写作节奏上，先写第三章和第四章，因为这两章几乎是画图——用例图、流程图、ER图、表结构。然后把第五章的截图填充进去。最后写绪论和摘要，摘要要一句话高度概括做了什么、用了什么、达到什么效果。

注意一个小细节：论文里所有配图要自己截图，不要用网上的图。老师一眼就能看出图是不是你自己生成的，自己截屏的界面图最可信。

7.2 演示视频与答辩前的准备细节

演示视频的录制讲究一个“流畅”原则：录之前先写好演示脚本，按顺序把系统亮点功能走一遍。三分钟的视频里体现四个核心模块就够了——登录与权限演示、居民档案查询、预约挂号完整流程、慢病随访录入。视频不要加背景音乐，解说声音清晰即可，导出MP4格式，1080p分辨率。

PPT不需要做太多页，12页左右合适。封面、目录、研究背景、技术选型、系统架构图、数据库设计图、功能演示截图、系统测试、总结与展望。每一页只放核心关键词和一个配图，少放字。答辩现场的投影仪对满屏文字的PPT非常不友好，图片加关键词才是正确的打开方式。

答辩前在室友面前演练至少两遍。重点过一遍你自己写的项目的核心代码，至少能看懂Controller层每个接口是做什么的，Service层的主要方法逻辑是什么。有个特别管用的小技巧：把项目跑起来，自己在浏览器里点一遍所有的主要功能，记住每个页面点击后会发生什么。老师们演示环节常会问“这个红色的警告标志是什么意思？”“这个按钮点了会怎样？”，你如果能当场点给他看，比任何口头解释都有说服力。

7.3 免费源码使用时的学习路径建议

免费领到的源码有两种用法。一种同学拿到手解决了毕业设计问题，另一种同学借助源码学到真正的项目能力。我强烈建议你做第二种。

拿到源码的第一步，先读懂整体包结构。从启动类看起，然后看Controller层的每一个类，理解每个接口的作用。第二步，通读数据库脚本，对着表结构看代码，理解每个业务功能对应的表和字段。第三步，选择其中一个完整业务链——比如预约挂号——从前端页面到Controller、Service、Mapper、数据库表，完整跟一遍数据流动。第四步，尝试在源码基础上加一个自己设计的新功能，比如加一个体检报告管理模块，哪怕功能很简单，也从建模开始自己实现一遍。做完这四步，你已经具备独立开发一个小型业务系统的能力，毕业设计和入职的起点都有了。

我见过太多同学毕业答辩结束以后，源码就扔进回收站了——那太可惜。一份能跑通的完整项目代码，是学习企业级开发最好的教材，价值远不止应付一次答辩。

8. 我的几点真实体会，关于这三个月和这套系统

带过这么多年毕业设计，我最大的感受是：很多人不是做不出系统，而是卡在“不知道从哪开始”这一步。如果你现在正站在这一步上，我的建议很简单——先从启动项目开始，把系统跑起来，看到登录页面，你的信心就建立起来了。剩下的功能模块，一个一个加，每一步都有明确的目标，进度自然就推着走。

做毕设的过程比结果更重要。答辩只给了你十分钟的介绍时间，但这三个月的代码量、踩坑记录、调试心得，才是你真正带走的东西。等你工作后就会明白，毕业设计是学生时代唯一一次允许你按自己的节奏、自己的设计，完整做完一个项目的机会——以后再也不会有了。

这套基于Spring Boot的社区医疗健康管理系统，技术上不算顶尖，但它完整、扎实、贴近真实的业务场景，作为一件“能跑能讲能答辩”的东西，它是合格的。希望这篇文章能成为你的起点。拿到源码后从第一个模块开始跑，遇到问题就回来翻翻这篇文章，你会发现自己比想象中更快地进入了状态。