社区医疗服务可视化系统：SpringBoot+Vue+MySQL全栈实战与部署指南-AI智能范式网

社区医疗服务可视化系统：SpringBoot+Vue+MySQL全栈实战与部署指南

happy最紧要·2026-10-13·阅读 24 GEO检测（免费）

社区医疗可视化系统SpringBoot

|难度：普通|阅读约 16 分钟

别人要搭一套社区医疗系统，从零写前后端至少要两三周，但如果你手里拿到的是一份结构完整的源码工程，第一要务不是埋头看代码，而是先把它的设计思路、运行方式和能改的地方摸清楚。本文要聊的就是这套“社区医疗服务可视化系统”——SpringBoot后端、Vue前端、MySQL数据库，标题里写着“可直接运行”，我先替你把整条链路拆开，再带你把它真正跑起来，最后把容易踩的坑和扩展方向一并说透。

这套系统适合谁？一类是在校学生做毕业设计或课程设计，拿它做二次开发非常顺手；另一类是社区卫生服务站点、小型门诊想做一套内部管理系统，又不想花大价钱采购商用软件，那这个项目就是很好的改造底座。我尽量用大白话把前后端的关联讲清楚，哪怕你之前只接触过SSM框架，或者只写过一点Vue，也能跟上节奏。

1. 项目定位与整体设计思路

1.1 这个系统的定位是什么

先从名字看，“社区医疗服务可视化系统”包含两层意思：第一层是“管理”，也就是说它要处理社区医疗服务中的基础信息——居民健康档案、慢病随访记录、体检数据、预约挂号、医生排班等；第二层是“可视化”，也就是把冷冰冰的数据转成图表，让管理者一眼看出片区的健康趋势、重点人群分布、服务量变化。

很多做医疗信息化的系统要么只做了数据录入，要么图表只是摆设。这个项目比较聪明的做法是，把统计报表直接做进业务模块里，比如居民档案列表旁边就能看到年龄段分布饼图，预约模块上方就能看到一周预约量柱状图，这样用户不会觉得图表是“额外功能”，而是业务的自然延伸。这是我拆项目时比较认可的交互思路。

后端SpringBoot负责提供数据接口，前端Vue负责展示页面和图表，MySQL负责持久化存储。三者关系用一句话概括：前端只关心界面和数据长什么样，后端只关心数据怎么存取、权限怎么校验，数据库只负责把数据老老实实存下来。前后端通过JSON格式进行通信，这也是目前企业级项目最主流的动作模式。

1.2 为什么选这套技术组合

SpringBoot现在基本是Java后端的事实标准，它最核心的价值是“自动装配”。传统Spring项目要写一大堆XML配置，还要手动引入各种依赖，SpringBoot把这些都自动化了——你只要在pom.xml里引入starter，再用注解声明一下，默认配置就生效了。学习成本低，社区资料多，是学生项目和企业小团队的首选。

Vue作为前端框架，优点在于组件化开发和响应式数据绑定。组件化意味着每个页面模块可以拆成独立零件，比如居民信息表格是一个组件，统计图表是另一个组件，互不干扰；响应式数据绑定意味着数据变了页面自动更新，不用像原生JavaScript那样手动操作DOM。配合Element UI这类组件库，后台管理页面能很快堆出来。

MySQL就更不用说了，开源、稳定、生态完善，社区服务系统的数据量级远没到需要上Oracle或PostgreSQL特殊功能的程度，MySQL完全够用。开发环境用5.7或8.0都行，我后面会提到两个版本要注意的差异点。

这套组合的优势我用表格简单概括：

维度	说明
开发效率	前后端分离，各干各活，接口定好就能并行开发
学习成本	三件套都是主流技术，资料多、踩坑少
二次开发	功能模块化清晰，加字段、加接口、加页面都方便
部署难度	SpringBoot可打包成jar包，前端构建成静态文件，一台服务器就够

1.3 前置准备与项目结构导读

动手之前，建议先把环境准备好。我这里列一份清单，能省掉后面很多麻烦：

JDK：1.8或以上，建议用8或11，稳定且和SpringBoot 2.x兼容性最稳
Maven：3.6以上，用于后端依赖管理和打包
Node.js：14以上，用于前端依赖安装和构建，16或18都行
MySQL：5.7或8.0，建议8.0，但要注意驱动和连接串配置
开发工具：后端用IDEA，前端用VS Code，两个工具各有侧重

拿到源码后，第一件事不是急着运行，而是先看目录结构。一般这份项目会分成两个目录，一个类似backend或server，管后端；一个类似frontend或web，管前端。后端工程能看到明显的分层——controller处理请求、service处理业务逻辑、mapper操作数据库、entity对应数据表、config放配置类。前端工程能看到views目录下面按业务模块分页面，router目录管路由，api目录管请求封装。

我接到这个项目时做的第一件事，是打开总的README或者项目说明文档，把启动步骤先读一遍。很多源码能不能跑起来，往往就卡在某个配置项上。接下来我会按数据库、后端、前端三个部分逐步拆解。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据库设计与后端核心实现

2.1 数据模型设计的几个关键表

数据库是整个系统的基础，表结构设计得好不好，直接决定后端代码能不能写得顺畅。这套系统里，我认为有几张核心表值得重点看。

第一张是居民健康档案表。社区医疗服务的对象就是辖区居民，这张表通常包含姓名、性别、出生日期、身份证号、联系电话、家庭住址、血型、过敏史、既往病史、建档日期等字段。设计时要特别注意身份证号设置唯一索引，因为它是居民身份的唯一标识，避免同一居民重复建档。

第二张是慢病随访表。社区医疗的重要工作之一就是慢性病管理，高血压、糖尿病、严重精神障碍患者都要定期随访。这张表一般包含居民ID、疾病类型、随访日期、血压值、血糖值、用药情况、随访医生、下次随访日期等字段。业务上常见的统计诉求——比如某个片区高血压控制率、随访完成率——都靠这张表出数据。

第三张是预约挂号表。包含居民ID、科室、医生、预约日期、时段、状态。这张表和可视化关系最紧密，因为“一周预约量”“热门科室排行”这类图表可以直接从这张表聚合出来。

第四张是医生信息表和排班表。医生表记录姓名、科室、职称、简介，排班表记录某医生在一周内某个时段的出诊安排。

表之间的关系也不复杂：居民是核心主体，随访记录、预约记录都通过居民ID关联；医生和排班也是主从关系。这种结构如果你用Navicat或DataGrip打开数据库，一眼就能看懂。重要的是理解设计理念：业务对象分清楚，每条记录有明确的归属和关联，统计查询时才好写SQL。

2.2 后端工程结构

SpringBoot工程的结构基本是固定的，这套项目也不例外。我习惯把工程分为这几个包：

controller：接收前端请求，调用service层，返回JSON数据
service：写业务逻辑，比如建档时校验身份证号、统计报表时组装查询条件
mapper：负责数据库操作，可以基于MyBatis的XML或注解写SQL
entity：每个类对应一张表，字段名与表字段一一对应
config：放跨域配置、拦截器配置等
common：放通用返回结果类、异常处理类、工具类

举个例子来说明各层怎么配合。前端要请求“获取居民列表”，那么controller里有个方法接收page、size、keyword参数，接着调用service层，service层又调用mapper层，mapper层执行一条带条件的SQL，把结果一层层返回给前端。中间service层可以加一些业务校验和逻辑处理，controller层只负责参数接收和结果返回。这样的好处是每一层职责单一，出了问题能快速定位是参数问题、业务问题还是SQL问题。

实际项目中，通用返回结果类也非常重要。我见过很多项目里的接口返回格式不统一，前端处理起来很痛苦。正常做法是定义一个公共类，固定格式包含code、message、data三个字段，code为200表示成功，非200表示业务错误，前端可以统一拦截处理。

2.3 核心接口实现要点

我选中几个核心接口，带你看一下实现逻辑，这样你自己改业务时就知道往哪里找代码。

居民模块的接口一般包括：分页查询列表、新增居民、编辑居民、删除居民、根据ID查询详情。分页查询是列表页最常用的接口，参数里通常有pageNum、pageSize、keyword，后端通过MyBatis的PageHelper或者手写LIMIT实现分页。如果你发现项目里用了PageHelper，注意引入依赖即可，在service里startPage然后紧跟着查询就能自动分页，这个工具比较方便。

新增居民时要注意业务校验。身份证号18位校验、手机号格式校验、建档时自动生成档案编号，这些都是典型的业务逻辑。代码上可以用Spring的@Validated注解加上实体里的校验注解，比如@NotBlank、@Pattern，让参数问题在入口处就拦截住，别让脏数据进入数据库。

统计报表接口是可视化的核心。以“居民年龄段分布”为例，后端SQL大概是这样：

sql复制SELECT 
  CASE 
    WHEN TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) < 18 THEN '0-17'
    WHEN TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) < 40 THEN '18-39'
    WHEN TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) < 60 THEN '40-59'
    ELSE '60以上'
  END AS age_group,
  COUNT(*) AS cnt
FROM health_record
GROUP BY age_group

这种SQL的意义在于把数据统计逻辑放在数据库层完成，前端拿到结果直接画图，不用在前端做二次计算。性能也好，毕竟社区站点数据量有限，一条聚合SQL毫秒级就能返回。

这里有个经验：统计类接口尽量只返回图表需要的数据结构，比如一个数组，每个对象里包含name和value字段。前端ECharts的饼图、柱状图天然就吃这个结构，两边都很省事。

2.4 一键启动配置

SpringBoot项目能“可直接运行”，最关键的是配置文件写对了。打开application.yml或application.properties，你需要重点确认这几项：

配置项主要包括端口号（默认8080）、数据库连接地址（jdbc:mysql://localhost:3306/xxx）、用户名、密码、MyBatis的mapper-locations路径，以及数据库方言设置。如果项目自带SQL脚本，你建好库后导入即可。

一个常见问题是MySQL 8.0和5.7的驱动不一样。MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，连接串里通常还需要加上useSSL=false和serverTimezone=Asia/Shanghai，否则启动会报时区错误。如果你用的5.7，驱动类名是com.mysql.jdbc.Driver。这个细节我踩过不少坑，代码里如果报“Unable to load authentication plugin”，多半是驱动版本和数据库版本不匹配。

另一个常见问题是数据库账号权限。默认root用户密码如果不匹配配置，直接启动就会报Access denied。建议把数据库密码也统一改成配置文件里的值，或者干脆新建一个专用账号，只授权这一个库的权限，更安全。

2.5 安全与权限控制

社区医疗系统涉及居民健康数据，权限控制不能完全不管。这个项目可能会用JWT做登录认证，也就是用户登录后服务器签发一个令牌，后续请求都带上这个令牌，后端校验通过才放行。实现上一般由拦截器或过滤器统一处理，白名单放行登录接口、验证码接口，其他接口都要校验。

如果你是拿这套系统做二次开发，至少要保留登录和用户管理两个模块。大多数真实项目都有管理员和普通医护人员的角色区分，管理员能看全量数据和报表，普通人员只能看自己负责的患者或只读不能改。权限这块做深了很复杂，但做基础的角色区分并不难，前端根据角色动态显示菜单，后端根据角色拦截接口就行。

我见过有些学生在答辩时被问“你的系统怎么保证数据安全”，结果答不上来。哪怕你只做了登录验证和角色区分，也比完全没有要好得多，最好再补充一句“用户密码经过MD5或BCrypt加密存储”。BCrypt比MD5更安全，因为自带盐值，推荐使用。

3. 前端可视化与交互细节

3.1 工程结构与页面划分

前端Vue工程一般走标准目录拆分。src下面通常有views、components、router、api、utils几个目录。views按页面维度组织，比如resident对应居民管理页面、appointment对应预约挂号页面、statistics对应统计报表页面。components放可复用的组件，比如一个通用搜索栏、一个通用表格组件、一个图表卡片组件。router管理路由，决定哪个路径对应哪个页面。api目录把请求接口按模块封装好，页面里直接调用对应的api函数，不直接写axios。

页面规划方面，一套完整的社区医疗可视化系统，建议至少包含这些模块：

登录页：账号密码登录，登录后跳转首页
首页仪表盘：放核心指标卡片和整体趋势图表
居民档案管理：表格展示居民列表，支持搜索、新增、编辑、删除
随访管理：慢病随访记录的增删改查
预约挂号管理：预约记录的列表和状态管理
医生排班管理：医生及排班信息的维护
统计可视化页：多个业务图表的集中展示

首页仪表盘是我比较推荐重点看的页面，因为它最能体现“可视化系统”这个词。一般会放四个指标卡片——总居民数、随访中人数、今日预约量、医生总数，下面再放两到三个图表，比如近七天的预约趋势折线图、居民年龄段分布饼图、科室服务量柱状图。这一个页面就能看出整个系统的业务广度和技术能力。

3.2 请求层封装

前端和后端通信要靠axios，但我不建议在每个页面里都直接写axios.get这种散装代码。工程化做法是在api目录里统一封装。

首先在utils或request.js里创建一个axios实例，配置baseURL和超时时间，然后设置请求拦截器——每次请求都从localStorage里取出token，放到请求头里。响应拦截器里处理两种情况：后端返回code为200时正常返回数据，非200时弹出错误提示；后端返回401时说明登录过期或未认证，直接跳转登录页。

封装好后，每个业务模块的接口调用都很清爽。比如居民模块的api文件可能是这样：

javascript复制import request from '@/utils/request'

export function getResidentList(params) {
  return request({
    url: '/api/resident/page',
    method: 'get',
    params
  })
}

export function addResident(data) {
  return request({
    url: '/api/resident',
    method: 'post',
    data
  })
}

export function updateResident(data) {
  return request({
    url: '/api/resident',
    method: 'put',
    data
  })
}

实际开发中，页面里只需调用这些函数，传入参数，then里接收返回结果。这样后端接口地址如果变了，只需要改api文件里的一个url，不用满项目搜索替换。这个习惯我从实际项目里练出来之后，维护成本降低非常明显。

值得注意的是跨域问题。前端开发服务器的默认端口和SpringBoot的8080端口肯定不一样，浏览器会拦截跨域请求。解决方案有两种：一是在后端写一个CORS配置类，允许所有来源访问；二是在前端vue.config.js里配置devServer的proxy代理，把/api开头的请求代理到http://localhost:8080。我个人推荐第二种，因为生产环境前端静态资源部署到Nginx后，也可以用Nginx做反向代理，思路一致。

3.3 可视化图表落地

“可视化系统”的核心就看图表漂不漂亮、数据准不准、交互顺不顺手。常见方案是ECharts，这个库很强，饼图、柱状图、折线图、地图、雷达图都能做，而且渲染性能好。

在Vue项目里使用ECharts，我建议按需引入，而不是全量引入。全量打包会让前端构建体积大不少。示例代码如下：

javascript复制import * as echarts from 'echarts/core'
import { BarChart, LineChart, PieChart } from 'echarts/charts'
import { GridComponent, TooltipComponent, LegendComponent } from 'echarts/components'
import { CanvasRenderer } from 'echarts/renderers'

echarts.use([BarChart, LineChart, PieChart, GridComponent, TooltipComponent, LegendComponent, CanvasRenderer])

图表组件写好后，关键是数据从接口拿。我一般在mounted里调用接口，拿到数据后调用setOption渲染图表。这里有个常见坑：图表容器必须有明确的高度，否则ECharts计算不出尺寸，图表就显示空白。很多新手卡在这里，以为代码写错了，其实只是CSS没给高度。

还有一点值得提：当浏览器窗口大小变化时，图表不会自动调整尺寸。需要在window的resize事件里调用chart.resize()方法。组件销毁时还要调用chart.dispose()释放实例，不然多次切换路由会出现内存泄漏。这些细节虽然不起眼，但直接影响用户体验和稳定性。

3.4 几张关键页面的实现细节

如果让我挑几个页面重点看，我会选首页仪表盘和居民档案管理页。

首页仪表盘是系统脸面，布局上通常用flex或el-row把多个图表卡片排列整齐。每个图表卡片放在一个独立组件里，比如TotalResidentChart.vue只负责画居民趋势折线图。我比较推荐这种做法，因为每个图表的数据源、加载状态、刷新逻辑都可以独立处理，互不影响。卡片之间用el-card包裹，设置统一的阴影样式，视觉上会很整齐。

居民档案管理页是典型的CRUD页面，也是最多人拿来改的模板。这个页面一般包含顶部搜索栏、中间操作按钮、主体表格、底部弹窗表单。搜索栏支持按姓名、身份证号、建档日期范围筛选，操作按钮支持新增和批量删除，表格最后一列放编辑和删除操作。弹窗表单里放了居民的各种字段，提交时调用对应的API。

这个页面的核心是维护多个JavaScript状态变量：loading表示加载状态，list表示表格数据，total表示总条数，queryParams表示搜索条件。每次搜索或翻页时，重新请求接口并更新这些状态。理解了数据流，你就掌握了所有列表页的通用写法。

4. 从零到一部署运行实录

4.1 环境准备

我实际操作时，会先把环境变量确认好。JDK方面，IDEA里Project Structure检查SDK版本；Maven方面，在IDEA的Settings里设置好本地仓库；Node方面，命令行里输入node -v确认版本。

这里分享一个小技巧：后端用IDEA打开时，如果Maven依赖下载慢，可以切换到国内镜像仓库。打开Maven的settings.xml文件，把mirror地址换成阿里云仓库，重新刷新依赖，速度会快很多。前端同理，npm install时如果很慢，用registry切换一下源，或者直接使用cnpm。

前端依赖安装的坑也不少。npm install报权限错误时，用管理员模式打开命令行；报python安装失败时，多半是某个node-sass这类原生模块在编译，需要先装windows-build-tools。不过现在项目基本都用sass的dart版本，这类问题已经少多了。如果实在装不上，删掉node_modules目录和package-lock.json，重新install一次。

4.2 初始化数据库

启动的第一步，是把数据库建出来。打开Navicat或者命令行，执行建库语句。我一般用Navicat图形化操作，方便很多，但命令行的语句你也得会写。

项目提供的SQL脚本通常包含建表语句和初始化数据两部分。用Navicat导入脚本时，注意选择正确的目标数据库，脚本里如果有USE语句，导入前要确认库名一致。有些SQL脚本文件很大，直接双击打开再执行可能卡住，用Navicat自带的运行SQL文件功能更稳妥。

导入完成后，检查一下表是否齐全。我习惯重点看几张核心表的数据量，如果初始化数据已经有了，后面启动测试功能就方便。正则规划时，如果项目里没有自带数据库账号，就按配置文件里的用户名密码来创建，比如账号root、密码123456，这样可以省去后续改配置的时间。

4.3 启动后端

数据库就绪后，用IDEA打开后端工程。先把maven依赖刷新一遍，等右下角进度条走完，然后找到启动类——类名通常叫Application或Main，上面有@SpringBootApplication注解的那个文件。右键点击启动即可。

启动过程中，重点看控制台日志。正常启动的话，SpringBoot会打印出Tomcat started on port(s): 8080这行关键日志，说明服务已经起来。如果报错，也不要慌，去看异常栈的第一行，博主主要的信息就是原因。数据库连不上、端口占用、依赖没有引入，90%的问题就出在这三类。

后端起来后，我习惯先用浏览器或者Postman测一个接口，比如直接访问http://localhost:8080/api/health，看看能不能返回JSON数据。如果返回正常，说明后端和数据库链路是通的。如果返回404，检查路由前缀是否对；如果返回错误，就去日志里找具体异常信息。

4.4 启动前端

后端正常后，打开前端工程。先执行npm install安装依赖，这个步骤可能要等几分钟，取决于网络状况。装完后执行npm run serve，Vue开发服务器默认会跑在8080之后的端口。如果8080被后端占了，Vue CLI会自动换端口，或者你直接配置vue.config.js指定一个端口。

前端启动后，浏览器会自动打开页面，跳到登录页。输入初始账号密码，正常情况能登录并跳转到首页仪表盘。如果页面能打开但接口请求报跨域错误，那就检查一下vue.config.js和axios的baseURL配置是否一致。如果接口返回401或者登录没反应，多半是后端没启动，或者登录接口地址对不上。

这里要强调一点：开发环境下一定要先启动后端，再启动前端，否则前端只是空壳，数据拿不到。我见过不少同学先启动前端，页面白屏或者转圈，然后开始怀疑代码有问题，其实顺序反了。

4.5 联调自测清单

一次完整的联调，我建议按下面清单走一遍，确保系统真的“没问题”：

登录：账号密码登录成功，错误密码能给出提示
首页：四个指标卡片有数据，图表能正常渲染，不出现空白
居民模块：分页加载、搜索、新增、编辑、删除全部正常
随访模块：新增一条随访记录，对应居民详情页能展示
预约模块：创建预约后状态流转正确，统计页数据变化
权限：未登录访问受保护页面能跳转登录页

在这个阶段遇到的问题，优先去浏览器F12的控制台和Network面板看。前端报错看Console，请求失败看Network里状态码和响应内容。后端的问题看后端控制台日志。前后端联调排查，本质上就是看数据在哪一层丢了、报错了，只要定位到层，就好解决。

5. 常见问题排查速查表

5.1 后端启动类问题

后端启动报错是遇到最多的情况，我每次接手别人源码都逃不掉这几类问题。

第一个是端口被占用。报错信息里有Port 8080 was already in use字样。解决方法是杀掉占用端口的进程，Windows下用netstat -ano | findstr 8080查到PID，再taskkill /PID xxx /F杀掉。也可以改后端端口，但注意前端代理配置也要同步改。

第二个是数据库连接失败。报错通常是Unknown database、Access denied、Communications link failure几种。一般检查三步：MySQL服务是否启动、数据库是否存在、用户名密码是否正确。用Navicat先测一下连接，通了再去启动后端。

第三个是依赖缺失或冲突。现象是编译不过，或者启动时ClassNotFoundException。解决方法是删除项目根目录的target目录，右键Maven的Reimport，强制重新加载依赖。

第四个是时区问题。MySQL 8.0连接时报serverTimezone异常，把连接串加上serverTimezone=Asia/Shanghai和useSSL=false就解决了。

5.2 前端联调类问题

前端问题很多不是代码本身的问题，而是环境或配置的问题。

最常见的跨域报错，浏览器Console里出现Access-Control-Allow-Origin字样。解决思路在后端加Cors配置，或者在前端配proxy代理。我推荐前端proxy方案，因为开发环境通用，只管前端一个地方。

页面空白但接口有数据，大概率是图表容器没有高度，或者组件还没挂载完就去初始化图表。检查DOM是否渲染完成，用this.$nextTick包一层再初始化。

请求一直转圈，Network里状态码pending，一般是后端服务没启动，或者请求地址不对。看看后端控制台有没有日志输出，没有就被前端的代理“吃掉了”。

登录跳转死循环，常见于路由守卫里判断token的写法有bug。注意登录页面要放行，判断条件别写反，进入死循环。

接口返回400或500，400通常是参数类型不匹配，比如后端需要Long类型前端传了字符串；500是后端抛了异常，还是去后端控制台查日志，把异常栈看到底。

5.3 业务数据类问题

系统跑通后，业务数据方面的问题也不少。

居民建档重复，解决方法是身份证号唯一索引已经建好，后端新增前再查一遍，返回友好提示。

统计图表数据不准，多半是统计SQL的条件有问题。比如随访率的分母来自慢病患者总数，分子是完成随访的人数，需要用子查询或LEFT JOIN把两个统计口径对齐。我会先检查统计口径定义：什么算“已随访”？什么周期才算“年度随访率”？口径确定后再写SQL。

日期格式不对，前端显示成了时间戳或英文格式，需要在后端返回时格式化，或者前端用日期组件统一格式处理。最简单的方式是在实体字段上加上@JsonFormat注解，统一格式为yyyy-MM-dd。

5.4 部署环境类问题

开发环境跑通后，如果要把系统部署到服务器，有几个新问题会出现。

后端打包成jar包，用mvn package命令。如果打包报测试失败，跳过测试，在IDEA右侧Maven面板执行package命令时输入-DskipTests参数，或直接用命令行mvn package -DskipTests。

jar包启动后，使用nohup java -jar xxx.jar > logs.txt 2>&1 &让它在后台运行。进程掉线的问题，可以用Linux的systemd或者supervisor做守护，保证服务重启后能自动拉起，这个细节很多教程不提，但实际项目特别重要。

前端打包成静态文件，命令是npm run build，产物会生成在dist目录。部署方式有两种：一是把dist目录扔给Nginx托管，做反向代理转发后端接口；二是用Node起一个服务托管。Nginx配置比较经典，基本配置是location /节点指向dist目录，location /api/节点proxy_pass到后端地址。

6. 项目二次开发方向与我的体会

系统跑通只是第一步，真正有价值的是你有没有能力在它基础上做出自己的东西。如果是毕业设计，我建议至少做以下几个方向的扩展，既能让系统更出彩，也能体现你的独立思考能力。

第一个方向是做慢性病管理深度分析。在现有随访表基础上增加BMI、血糖控制区间、用药依从性等字段，引入时间维度的趋势分析，展示一个患者半年内血压的变化曲线。这个功能贴近社区医疗的痛点，答辩时也容易讲清楚设计动机。

第二个方向是消息通知。当随访到期时，自动生成待办提醒，通过WebSocket推送给前端，医生登录就能看到“今天需要随访3个患者”。这个改法看似复杂，实际就是在后端加一个定时任务，查一遍随访到期名单，推给在线用户，前端弹个通知条就行。

第三个方向是导出功能。把居民列表和统计报表导出成Excel，操作上可以用EasyExcel。实际业务中卫生站经常要上报数据，导出Excel比查数据库方便得多，展示时也容易被评委认可。

第四个方向是引入缓存。热点数据比如首页仪表盘的指标统计，其实不用每次请求都查数据库，完全可以放Redis里缓存五分钟。这样不仅接口响应变快，技术栈里多一个Redis，含金量也上来了。

我个人体会是这个项目最值钱的地方不在代码量，而在于业务结构完整。一个社区医疗系统，居民、随访、预约、排班、报表全都有，各模块之间的数据关联清晰，非常适合拿来做二次开发的基础。你改了哪些地方、加了什么功能、为什么这么设计，只要能用“业务需求”这条逻辑串起来，无论是答辩还是面试，都比空谈“我会SpringBoot”有说服力得多。

最后给你一个建议：拿到源码，第一遍先别改代码，把每个模块的数据流走一遍——登录怎么进，菜单跳哪里，列表数据从哪里来，新增记录存到哪张表。把这条链路走通了，你才是真正拿到了项目的控制权。第二遍再动手改页面、加字段、调样式，这时候你做的每一步都有依据，自然不会把系统改坏。