我接手过不少社区服务类的管理系统项目但像这种前后端分离的社区医疗服务系统其实特别适合拿来练手或者做毕设改造原因很简单业务场景完整但不过度复杂技术栈主流不冷门部署起来也不会把人折腾到怀疑人生。整套系统我用的是 SpringBoot Vue MyBatis MySQL 这套组合源码和部署过程已经整理成文下面把设计思路、核心代码、部署踩坑完整拆一遍尽量让照着做的人少走弯路。这类系统真正要解决的痛点其实很接地气社区居民挂号不方便、医生排班不透明、健康档案分散在各处社区医疗管理人员又缺乏一个统一的后台去查看预约数据和患者情况。所以系统角色就得拆成三类——居民用户、社区医生、系统管理员三类人各自有操作诉求系统就得围绕这些诉求去设计模块和权限边界。1. 项目整体需求分析与功能拆解1.1 核心角色与业务场景分析先说用户角色这直接决定功能菜单怎么划分。社区医疗服务系统的用户不是单一群体而是三类明显不同的人居民用户是服务的消费者他们最关心的是能不能快捷查到社区医院有哪些医生、哪些科室、什么时候能预约社区医生是服务提供者他们需要看自己的排班表、接收患者的预约申请、维护患者档案系统管理员是运维者负责维护医生信息、公告发布、数据统计。如果你把这些角色混在一套菜单里权限控制会非常痛苦。所以我采用了最简单的 RBAC 模型用一张用户表加角色字段的方式实现分级。具体来说就是 sys_user 表存储账号信息包含角色标识前端根据角色动态渲染菜单后端通过拦截器校验接口权限双重保障下越权访问基本被堵死。1.2 功能模块边界与优先级划分功能模块我拆分成了六大块每块都有独立的页面和接口支撑用户认证模块支持登录、注册、退出这里有个细节要特别说——注册功能虽然是公开的但注册完成后默认角色一定是居民用户医生和管理员账号只能由管理员在后端手动创建或指定角色避免任何人注册个账号就能变成医生操作后台。首页展示模块包括社区医院的简介、通知公告、医生简介列表这部分是公开数据无需登录即可查看是系统最简单也是访问量最大的入口。预约挂号模块居民选择科室、选择医生、选择日期时段提交预约。核心流程是医生排班规则加上预约号源控制每个时段限定号源数量预约时实时扣减防止超挂。排班管理模块医生和系统管理员都可以查看排班日历管理员能帮医生设置排班医生能查看自己在某个时间段内有哪些预约。档案管理模块医生能够为前来就诊的患者维护基本信息、病史、诊断记录居民用户只能查看医生给自己写的档案不能修改。统计分析模块管理员查看预约数据趋势、科室热度、年龄分布等统计信息用于辅助社区医疗资源的调配决策。1.3 为什么这些功能够用、不贪多很多人做这类项目容易犯一个毛病——先把功能想得很大医生在线问诊、电子处方流转、药品库存管理全塞进去结果开发周期拉长好几倍bug 反而一堆。我建议把 MVP 思维带进来一个社区医疗服务系统最核心的闭环其实是“查医生、约医生、去看病、留档案”把这条链路跑通了这个项目就立住了。至于在线支付、药品商城那些模块后续扩展的余地并不小但初次开发没必要背上这么大包袱。这套系统的后续扩展其实很方便——比如加个健康资讯模块无非是再建一张文章表加两个接口的事。2. 技术选型为什么是 SpringBoot Vue MyBatis MySQL2.1 后端选型逻辑SpringBoot 近十年来基本就是 Java 后端的中坚力量选它核心理由很简单它把过去的 SSM 时期的 Spring 配置简化到了极低程度内嵌了 Tomcat开发者只需要一个 main 方法就能启动服务极大缩短了环境搭建到写业务之间的时间。尤其是这种中小规模的管理系统SpringBoot 的约定大于配置真的能省下很多事。ORM 框架我选了 MyBatis 而不是 JPA 或者 MyBatis-Plus原因有几个。第一MyBatis 对 SQL 的控制力是直接而透明的写什么 SQL 就执行什么 SQL遇到复杂多表查询、统计分析的时候调试起来比 Hibernate 自动生成的 SQL 要直观得多第二很多老项目、教学项目都用 MyBatis团队协作时沟通成本低第三这种社区系统的查询场景有不少动态条件组合MyBatis 的if、where标签做动态 SQL 非常顺手。当然 MyBatis-Plus 也很优秀如果你想少写简单的 CRUD 代码完全可以换但我这里为了演示原生的完整 SQL 写法保持 MyBatis 基础版。MySQL 的选择不多解释一句话——小型项目选它稳如老狗。部署方便、资料海量、主流云厂商一键安装性能完全够用。与之对比的 PostgreSQL 也很优秀但社区里大部分想要的排错案例都基于 MySQL遇到问题搜索结果更多。2.2 前端选型逻辑Vue 在这套系统里用的版本是 Vue2 Element UI说起来可能显得保守但这是有考量的。Element UI 的组件成熟度极高表格、表单、日期选择器、对话框每一个都能直接拿过来拼成后台管理界面开发速度确实快。如果你用 Vue3生态选择就变成了 Element Plus本质上差别不大但 Vue2 的学习资料、案例数量仍然是庞大的对于要快速出成果的场景Vue2 配上 Element UI 是不容易出错的老搭档。前端状态管理用了 Vuex路由用的 Vue Router。这里要说一个很多新手容易忽略的问题前端路由守卫必须配合后端接口鉴权一起做。前端守卫只解决页面跳转的拦截问题真正的数据安全必须由后端接口鉴权兜底。前端判断用户没有 token 就跳转到登录页这只是锦上添花图片来源服务器如果没有 token 就返回 401那才是硬隔离。两边都做系统才是真安全。2.3 前后端分离架构的本质优势这套系统的架构是典型的前后端分离前端独立部署在 Nginx通过 HTTP 请求后端 API后端不返回任何页面视图只返回 JSON 数据。开发阶段用 Vue CLI 的 devServer 做跨域代理生产阶段用 Nginx 反向代理把/api的请求转发给 SpringBoot 服务。这样拆的好处非常直接前后端两组人可以并行开发约定好接口文档就能各干各的后端接口可以被小程序端、App 端复用未来想做移动端前端重写就行后端接口不变。你要非问有什么缺点那也就是部署多了一道 Nginx 配置跨域问题要提前设计好这两点在后面实操部分我都会详细讲到。3. 数据库设计一张表一个业务的边界3.1 核心表结构与字段设计数据库这块我建了 8 张核心表整个系统的业务数据都落在这几张表上。下面挑几个核心的表结构展开讲。用户表 sys_userid 主键自增username 唯一登录名password BCrypt 加密后的密码real_name 真实姓名phone 手机号role 角色标识1 管理员、2 医生、3 居民avatar 头像地址status 账号状态1 正常、0 禁用create_time 注册时间医生信息表 doctor_infoid 主键user_id 关联 sys_user 的 iddepartment 科室名称如全科门诊、中医科、儿科title 职称如主治医师、副主任医师intro 医生简介is_online 在线状态这个字段是为未来在线问诊预留的预约记录表 appointmentid 主键patient_user_id 预约的居民用户 iddoctor_user_id 被预约的医生用户 idappointment_date 预约日期time_slot 时段如上午、下午status 状态0 待接诊、1 已接诊、2 已取消symptom_desc 症状描述居民预约时填写create_time 创建时间健康档案表 health_recordid 主键patient_user_id 患者用户 iddoctor_user_id 建档医生 iddiagnosis 诊断结果prescription 医嘱建议record_date 记录日期表之间的关联关系并不复杂通过 user_id 互相引用来体现。这里要特别提一个设计经验不要把医生信息直接堆在用户表里单独拆一张 doctor_info 表这样一旦以后要加医生的职称晋升、科室转调、工作时长等字段扩展起来不动主表结构更可控。3.2 时间字段与状态字段的设计规范设计表的时候有几个细节经常影响系统稳定性先看时间字段。MySQL 中的 datetime 类型在 Java 里对应的是 LocalDateTime但要注意时区问题——服务器设置 UTC 时间后Java 往数据库写时间会自动转换偏移经常出现差了 8 小时的问题。我在数据库连接参数里强制指定了serverTimezoneAsia/Shanghai同时在 SpringBoot 配置文件中设置了spring.jackson.time-zoneGMT8两边对齐基本能根治时区串扰。状态字段统一用 tinyint0 和 1 表达既不花哨也不会出错。遇到类似预约状态这种字段我还会写上注释什么数字代表什么含义表结构里一目了然省得后面维护的人翻半天代码才猜到 2 代表已取消。3.3 数据初始化与测试数据准备建完表之后一定要准备初始化数据否则前端页面展示出来全是空荡荡的。我用一个data.sql文件在项目启动时执行把管理员账号、几个医生信息、排班数据、通知公告记录全部预设好。这样就避免反复手动往数据库里插测试数据尤其当你要把项目交给别人本地运行的时候初始化数据的价值立刻体现出来——别人 clone 项目之后不用折腾数据库启动即用。4. 后端核心实现从接口定义到具体逻辑4.1 项目结构与分层设计后端按照经典的三层架构来组织controller → service → mapper。controller 层只做参数接收和结果封装service 层写业务逻辑和事务mapper 层是 MyBatis 的接口定义配合 XML 或注解写 SQL。这个分层虽然老套但极其稳定你可以在不破坏整体结构的前提下替换任何一层。比如说这一块的结构大致是这样config 包跨域配置、拦截器配置、MyBatis 配置controller 包按模块拆分的控制器service 包业务逻辑实现类mapper 包数据库操作接口entity 包实体类common 包统一返回结果、异常处理器、工具类dto 包参数接收对象用于区分提交参数和数据库实体统一返回结果类 Result 是后端设计里很重要的一个约定。所有接口都返回{ code: 200, message: 操作成功, data: {...} }结构前端拿到结果后根据 code 决定怎么渲染。如果成功则 code 为 200未登录则返回 401业务异常则返回 500。这样前后端对接时心智负担极低你不用每个接口单独设计返回格式。4.2 JWT 认证与拦截器鉴权实现登录流程这里详细讲讲。用户提交用户名密码后后端用 BCrypt 算法比对密码比对成功则签发一个 JWT token 返回给前端。前端把 token 存在 localStorage 里之后每次请求在 axios 请求拦截器里加上Authorization: Bearer token这样一个请求头后端拦截器从 Header 里取 token 并验证。密钥和有效期我放在了 application.yml 中jwt: secret: your-secret-key-change-in-production expire: 86400000有效期的单位是毫秒86400000 正好是 24 小时。生产环境建议把时间缩短到 2-4 小时并且配合前端在 401 时跳转登录页强制重新登录这样即使 token 泄露被滥用的窗口期也不会太长。拦截器实现的时候只用到一个 HandlerInterceptor重写 preHandle 方法在方法里排除掉登录、注册、图片验证码这些不需要认证的路径剩下的路径全部校验 token。校验失败的统一返回 401 状态码和统一的 JSON 信息而不是直接把用户重定向到某个页面——记住后端服务只认数据不认页面前端拿到 401 自行处理跳转逻辑才是分离架构下的正确姿势。关于 BCrypt 再补充一个细节不要用 MD5 去加密密码。MD5 配合彩虹表攻击很容易被破解BCrypt 自带盐值是随机生成的每次加密同一个明文得到的结果都不一样这就能有效防御彩虹表攻击。Spring Security 提供了 BCryptPasswordEncoder但我不想为了一个加密功能引入整套 Security 框架所以直接引用了spring-security-crypto工具包只保留加密和匹配方法轻量好维护。4.3 核心业务接口预约流程的执行细节预约挂号是系统最重要的业务链路它的接口逻辑必须严密防止出现并发超挂的问题。预约接口的 service 层实现步骤是根据医生 id 和预约日期时段做防重复校验查询是否已有预约记录有就直接抛业务异常查询该医生当日时段已经有多少号源被占用如果大于等于设定的排班号源数抛出号源已满异常插入一条预约记录状态设为待接诊更新排班表已约人数这里防并发超挂的技术手段是给数据库操作加行锁。具体做法是在 appointment 表里同一医生同一天同一时段通过唯一索引约束(doctor_user_id, appointment_date, time_slot, patient_user_id)来防止同一个人重复预约通过一个排班表的已约人数字段加上乐观锁控制即 update 的时候带上where already_count max_count条件当影响行数为 0 说明号源已满事务回滚。这种方式不需要显式使用悲观锁也没有死锁风险在医院就诊预约这种并不极端的并发场景下完全够用。如果你要对极端并发做压力测试那需要引入 Redis 分布式锁或者 Redisson 方案但作为社区级系统现在这套实现稳定性和性能已经平衡得很好了。项目临交付前我模拟了并发压力测试30 个线程同时抢最后一个号源最终只有一个请求成功没有超卖。4.4 统计分析模块的数据处理统计分析模块是这类系统的亮点功能也是面试官比较关注的地方。我这里提供了三个统计接口预约趋势、科室热度分布、居民年龄分布。预约趋势的 SQL 实现思路是按日期分组统计预约量查出最近 7 天每天预约量通过 map 转成前端 ECharts 折线图能识别的结构。 科室热度分布则是关联预约表和医生表按医生所属科室分组统计预约量然后用饼图展示。 年龄分布则是从用户表中根据出生年份计算年龄区间然后按区间分组统计。这三种统计接口都只有简单的单表或双表查询没必要上复杂的 OLAP 计算和宽表设计。社区系统数据量在十万级别以内MySQL 原生聚合函数完全秒出结果。要注意的是后端把数据返回给前端的方式我统一采用ListMapString, Object类型前端不用关心实体结构直接透传到图表组件里即可。5. 前端核心实现从页面到交互5.1 项目结构与路由守卫前端项目用 Vue CLI 创建标准的 Vue2 项目结构。src 下面的目录拆成 api、router、store、views、components、utils。api 目录统一存放 axios 请求方法按业务模块拆文件比如 user.js、appointment.js、doctor.js每个方法对应一个后端接口这个习惯能让你在后期维护接口时特别省事。路由配置是关键一环。系统有三类角色菜单显示完全不一样这个动态控制逻辑分为两步第一步在路由表里给所有页面配置 meta 字段里面存 roles 数组指定哪些角色能访问第二步在路由守卫里拿到当前用户信息后判断用户角色通过 router.addRoutes 动态添加可访问路由。登录页到首页的流程是用户登录后后端返回的 data 中不仅包含 token还包括用户信息和角色标识。前端把这些信息存到 Vuex 和 localStorage然后根据角色跳转到对应的首页。之后每次刷新页面时在 App.vue 的 created 钩子里调一次获取用户信息的接口重新把用户信息装入 Vuex防止刷新后路由守卫判断不到角色而导致误拦截。5.2 Axios 封装与请求拦截axios 的封装直接决定前端开发效率我把请求工具单独放在 utils/request.js 里做三层处理第一层是请求拦截器把 token 从 localStorage 取出来放到请求头第二层是响应拦截器如果后端返回 code 200 就直接把 data 抛出如果 code 401 则跳转登录页并清空本地缓存如果 code 500 则全局弹出错误提示框。这套流程下来业务页面里的调用就非常干净。一个实际的请求调用示例// api/user.js import request from /utils/request export function login(data) { return request({ url: /api/auth/login, method: post, data }) } export function getDoctorList(params) { return request({ url: /api/doctor/list, method: get, params }) }页面里调用的时候const res await getDoctorList({ department: 中医科 }) this.doctorList res.data.rows后端返回的字段层级在前端有统一约定data 字段里放具体业务数据List 查询还会包含 total 总数返回给分页组件。这样不管是做页面还是做后续的接口联调双方都知道数据长什么样减少沟通成本。5.3 核心页面逻辑预约挂号页面实现预约挂号页面是前端交互的重点。页面把整个预约流程拆成三个步骤通过一个 stepper 组件引导用户逐步完成每一步对应一个独立的子组件。第一步选择科室。科室列表由后端接口返回页面用卡片式布局展示选中的卡片用高亮边框标识。第二步根据科室筛选医生这里要把医生卡片展示出来卡片上包含医生的头像、姓名、职称、简介和排班信息。排班信息尤其重要用户在选医生时就要看到未来 7 天哪个时段还能约绿色可约、灰色已满。第三步是选择日期时段、填写症状描述确认提交。第三步的后端交互有一个关键设计提交预约之前前端会先调一个查询剩余号源的接口如果发现已经被约满页面立刻给出提示并禁用提交按钮。这虽然不能替代后端的事务并发控制但对用户体验的提升非常明显——与其等用户填完表单提交后才被告知约满不如在交互过程中就拦住。医生端页面主要是查看预约列表和建档。预约列表按日期筛选展示当天患者预约信息医生点击“接诊”后系统弹出建档对话框填写诊断结果和医嘱完成后预约状态变更为已接诊。6. 部署实操本地到服务器全流程6.1 本地开发环境快速启动本地启动这套系统分为三步第一步MySQL 建库建表并把初始化数据导入第二步后端启动用 IDEA 打开 backend 项目等待 Maven 依赖下载完毕后运行 Application 主类第三步前端启动用 VSCode 打开 frontend 项目在终端执行 npm install然后执行 npm run serve浏览器访问本地地址即可。开发阶段需要处理跨域问题。Vue CLI 的 devServer 配置中设置 proxy 代理是最简单的方案// vue.config.js module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样配置后前端请求/api/auth/login会被开发服务器自动转发到http://localhost:8080/api/auth/login浏览器的同源策略不会被触发前端代码里也不用写完整的后端地址全部使用相对路径 /api 开头。6.2 生产环境部署步骤生产环境我建议用一台 2 核 4G 的 Linux 云服务器装好 Nginx、JDK 1.8、MySQL。部署流程如下第一后端打包。在项目根目录执行 Maven 打包命令mvn clean package -DskipTests打包完成后target 目录下会生成一个 jar 包大小大约 50-80MB。通过 FTP 或者命令行工具把 jar 包传到服务器然后运行启动命令nohup java -jar med-community-server.jar --spring.profiles.activeprod server.log 21 nohup 命令让 Java 进程在后台运行输出日志写入 server.log 文件这时候后端服务已经在服务器的 8080 端口待命。第二前端打包。在前端项目目录执行构建npm run build生成 dist 目录里面就是纯静态文件。把 dist 目录下的所有文件通过 FTP 上传到服务器 Nginx 的 html 目录比如/usr/local/nginx/html/med-community/。第三Nginx 配置。这是前后端分离部署的关键点配置文件参考server { listen 80; server_name your-domain.com; location / { root /usr/local/nginx/html/med-community; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这个配置里有三个要点。第一行的 location / 是静态资源服务告诉 Nginx 当访问根路径时去 html 目录找静态文件。第三行的 try_files 配置解决的是 Vue Router 用 history 模式时刷新页面 404 的问题它会把所有非文件路径的请求都回退到 index.html由前端路由接管。第二个 location /api/ 是把所有以 /api 开头的请求转发到后端的 8080 端口。要注意的是生产环境的跨域问题不需要前端代理来处理了因为 Nginx 反向代理让前后端变成了同源浏览器不会出现跨域校验错误。所以在生产打包时axios 的 baseURL 直接用/api相对路径和开发环境保持一致即可。6.3 常见部署问题与排查技巧部署过程一定会遇到问题这里列几个高频问题。第一个是数据库时区报错。启动后端时如果出现The server time zone value Öйú±ê׼ʱ¼ä这样的报错说明 MySQL 连接字符串里没有加时区参数。解决方法是在 JDBC URL 后面加上serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8。第二个是端口被占用。启动后端时如果报端口被占用可以用命令查看占用端口的进程然后杀掉netstat -tlnp | grep 8080 kill -9 进程号第三个是 Nginx 配置改完后没生效。改了 Nginx 配置后必须重启或者执行 reload 命令/usr/local/nginx/sbin/nginx -s reload不执行 reload 或者 restart 的话配置不会自动加载。另外很多第一次用 Nginx 的人会忽略一个细节——改了 html 目录里的前端静态文件后不需要重启 Nginx静态文件是实时读取的刷新浏览器即可看到效果。第四个是前端刷新 404 的问题。如果出现这种状况大概率是 Nginx 配置里少了 try_files 那一行加上并 reload 即可。6.4 服务器防火墙与安全配置服务器安全这块不能省尤其系统里有居民的健康数据属于敏感个人信息。我做的基础加固措施有服务器只开放 80 和 22 端口MySQL 的 3306 端口绝不对外开放只允许本机访问后端接口不使用明文 HTTP 传输生产环境有条件就上 HTTPS现在云平台都能免费申请 SSL 证书数据库账号权限最小化项目启动用的账号只授予需要用的几个库的增删改查权限不给 root 权限。后端代码层面也有几处安全细节登录接口加一个简单的验证码校验防止批量暴力破解密码通过拦截器限制接口的访问频率比如同一账号每分钟只能调用登录接口 10 次超了就临时锁定前端所有用户输入都做长度限制后端也同步做校验防止有人绕过前端直接调接口塞超长数据。7. 常见问题排查与实操心得7.1 联调阶段的核心问题实录这套系统在联调和测试阶段暴露出来的问题最有代表性的有两个。第一个是跨域配置出错导致登录请求发送不了排查方法是打开浏览器开发者工具看网络请求的报错信息如果提示 CORS 相关的字样就说明代理配置没生效或者后端跨域配置有误。常见原因是在 vue.config.js 里配置了代理但后端又同时开启了 CORS 跨域支持两套机制叠加后反而出现预检请求处理异常。解决的思路是开发环境用代理生产用 Nginx 反代后端不开启 CORS 跨域支持反而最稳定。第二个是 Vue 打包后白屏。排查这类问题要按顺序来先看浏览器控制台的报错信息如果提示接口 404那是 Nginx 的 /api 代理路径没配对如果提示静态资源 404那是打包后静态文件路径引用问题需要在 vue.config.js 中设置 publicPath 为相对路径./如果什么资源都不加载查看 Nginx error.log 和 dist 目录的文件权限大概率是上传文件时权限为 root 所有但 Nginx 运行用户是 nobody没有读权限chmod -R 755 解决。7.2 快照备份和回滚方案部署到生产之后每一次大的版本更新都有翻车风险所以养成了快照备份的习惯。在云平台上定期给服务器做快照尤其是更新之前强制手动快照一次。如果部署后系统报错直接回滚到上一个快照服务恢复时间不超过 5 分钟。数据库的话用 mysqldump 做逻辑备份mysqldump -u username -p med_community med_community_$(date %Y%m%d).sql加上 crontab 定时任务每天凌晨备份一次数据库保留最近 7 天重复数据占用空间也不大但关键时刻能救命。7.3 一套可复用的前后端分离开发流程做完这个项目之后我复盘了一下整个流程感觉这套组合拳对中小型管理系统通用性很高。第一步先把数据库表结构设计好这是整个项目的地基表关系理不清后面全是返工第二步后端按模块逐个开发和测试使用 Postman 或 Apifox 管理接口文档第三步前端并行开发根据接口文档模拟数据做页面等后端接口就绪后联调第四步前后端联调完成后打包部署第五步完善部署文档和项目 README。如果你要把这个项目作为独立作品或者毕设展示我强烈建议在部署完成后录制一个 5-10 分钟的功能演示视频把核心流程走一遍并且准备好回答几个关键问题数据库表怎么设计的、预约并发是怎么控制的、JWT 认证是怎么实现的、项目改进方向是什么。面试官或者评审老师问得最多的就是这几个提前梳理清楚很重要。7.4 关于扩展方向的一些建议如果后续想继续完善这套系统有几个扩展方向值得考虑接入在线支付把预约闭环走完整开发一个居民端小程序直接把预约、查档案的功能搬到手机上用 Redis 做缓存和分布式会话提升并发处理能力加上 WebSocket 实时通知医生确认接诊后能主动推送给居民用户。这些方向任何一个拎出来都能做成独立的模块也都能在简历上单独列成一条亮点。我的个人经验是一个项目最终的价值不取决于它用了多少新技术而在于它是不是把一条完整的业务链路走通了。这套社区医疗服务系统从登录注册到预约挂号从医生接诊到档案留存从数据统计到生产部署是一条完整的链路这才是这类项目最值钱的地方。照着上面的步骤和环境动手跑一遍你会对前后端分离开发、权限控制、并发处理、生产部署的整套流程形成一份完整的、属于自己的理解。 
长河君 · 2026/10/17 11:22:45 · 阅读 1.2k 社区医疗服务系统实操：SpringBoot + Vue前后端分离项目设计与部署
我接手过不少社区服务类的管理系统项目但像这种前后端分离的社区医疗服务系统其实特别适合拿来练手或者做毕设改造原因很简单业务场景完整但不过度复杂技术栈主流不冷门部署起来也不会把人折腾到怀疑人生。整套系统我用的是 SpringBoot Vue MyBatis MySQL 这套组合源码和部署过程已经整理成文下面把设计思路、核心代码、部署踩坑完整拆一遍尽量让照着做的人少走弯路。这类系统真正要解决的痛点其实很接地气社区居民挂号不方便、医生排班不透明、健康档案分散在各处社区医疗管理人员又缺乏一个统一的后台去查看预约数据和患者情况。所以系统角色就得拆成三类——居民用户、社区医生、系统管理员三类人各自有操作诉求系统就得围绕这些诉求去设计模块和权限边界。1. 项目整体需求分析与功能拆解1.1 核心角色与业务场景分析先说用户角色这直接决定功能菜单怎么划分。社区医疗服务系统的用户不是单一群体而是三类明显不同的人居民用户是服务的消费者他们最关心的是能不能快捷查到社区医院有哪些医生、哪些科室、什么时候能预约社区医生是服务提供者他们需要看自己的排班表、接收患者的预约申请、维护患者档案系统管理员是运维者负责维护医生信息、公告发布、数据统计。如果你把这些角色混在一套菜单里权限控制会非常痛苦。所以我采用了最简单的 RBAC 模型用一张用户表加角色字段的方式实现分级。具体来说就是 sys_user 表存储账号信息包含角色标识前端根据角色动态渲染菜单后端通过拦截器校验接口权限双重保障下越权访问基本被堵死。1.2 功能模块边界与优先级划分功能模块我拆分成了六大块每块都有独立的页面和接口支撑用户认证模块支持登录、注册、退出这里有个细节要特别说——注册功能虽然是公开的但注册完成后默认角色一定是居民用户医生和管理员账号只能由管理员在后端手动创建或指定角色避免任何人注册个账号就能变成医生操作后台。首页展示模块包括社区医院的简介、通知公告、医生简介列表这部分是公开数据无需登录即可查看是系统最简单也是访问量最大的入口。预约挂号模块居民选择科室、选择医生、选择日期时段提交预约。核心流程是医生排班规则加上预约号源控制每个时段限定号源数量预约时实时扣减防止超挂。排班管理模块医生和系统管理员都可以查看排班日历管理员能帮医生设置排班医生能查看自己在某个时间段内有哪些预约。档案管理模块医生能够为前来就诊的患者维护基本信息、病史、诊断记录居民用户只能查看医生给自己写的档案不能修改。统计分析模块管理员查看预约数据趋势、科室热度、年龄分布等统计信息用于辅助社区医疗资源的调配决策。1.3 为什么这些功能够用、不贪多很多人做这类项目容易犯一个毛病——先把功能想得很大医生在线问诊、电子处方流转、药品库存管理全塞进去结果开发周期拉长好几倍bug 反而一堆。我建议把 MVP 思维带进来一个社区医疗服务系统最核心的闭环其实是“查医生、约医生、去看病、留档案”把这条链路跑通了这个项目就立住了。至于在线支付、药品商城那些模块后续扩展的余地并不小但初次开发没必要背上这么大包袱。这套系统的后续扩展其实很方便——比如加个健康资讯模块无非是再建一张文章表加两个接口的事。2. 技术选型为什么是 SpringBoot Vue MyBatis MySQL2.1 后端选型逻辑SpringBoot 近十年来基本就是 Java 后端的中坚力量选它核心理由很简单它把过去的 SSM 时期的 Spring 配置简化到了极低程度内嵌了 Tomcat开发者只需要一个 main 方法就能启动服务极大缩短了环境搭建到写业务之间的时间。尤其是这种中小规模的管理系统SpringBoot 的约定大于配置真的能省下很多事。ORM 框架我选了 MyBatis 而不是 JPA 或者 MyBatis-Plus原因有几个。第一MyBatis 对 SQL 的控制力是直接而透明的写什么 SQL 就执行什么 SQL遇到复杂多表查询、统计分析的时候调试起来比 Hibernate 自动生成的 SQL 要直观得多第二很多老项目、教学项目都用 MyBatis团队协作时沟通成本低第三这种社区系统的查询场景有不少动态条件组合MyBatis 的if、where标签做动态 SQL 非常顺手。当然 MyBatis-Plus 也很优秀如果你想少写简单的 CRUD 代码完全可以换但我这里为了演示原生的完整 SQL 写法保持 MyBatis 基础版。MySQL 的选择不多解释一句话——小型项目选它稳如老狗。部署方便、资料海量、主流云厂商一键安装性能完全够用。与之对比的 PostgreSQL 也很优秀但社区里大部分想要的排错案例都基于 MySQL遇到问题搜索结果更多。2.2 前端选型逻辑Vue 在这套系统里用的版本是 Vue2 Element UI说起来可能显得保守但这是有考量的。Element UI 的组件成熟度极高表格、表单、日期选择器、对话框每一个都能直接拿过来拼成后台管理界面开发速度确实快。如果你用 Vue3生态选择就变成了 Element Plus本质上差别不大但 Vue2 的学习资料、案例数量仍然是庞大的对于要快速出成果的场景Vue2 配上 Element UI 是不容易出错的老搭档。前端状态管理用了 Vuex路由用的 Vue Router。这里要说一个很多新手容易忽略的问题前端路由守卫必须配合后端接口鉴权一起做。前端守卫只解决页面跳转的拦截问题真正的数据安全必须由后端接口鉴权兜底。前端判断用户没有 token 就跳转到登录页这只是锦上添花图片来源服务器如果没有 token 就返回 401那才是硬隔离。两边都做系统才是真安全。2.3 前后端分离架构的本质优势这套系统的架构是典型的前后端分离前端独立部署在 Nginx通过 HTTP 请求后端 API后端不返回任何页面视图只返回 JSON 数据。开发阶段用 Vue CLI 的 devServer 做跨域代理生产阶段用 Nginx 反向代理把/api的请求转发给 SpringBoot 服务。这样拆的好处非常直接前后端两组人可以并行开发约定好接口文档就能各干各的后端接口可以被小程序端、App 端复用未来想做移动端前端重写就行后端接口不变。你要非问有什么缺点那也就是部署多了一道 Nginx 配置跨域问题要提前设计好这两点在后面实操部分我都会详细讲到。3. 数据库设计一张表一个业务的边界3.1 核心表结构与字段设计数据库这块我建了 8 张核心表整个系统的业务数据都落在这几张表上。下面挑几个核心的表结构展开讲。用户表 sys_userid 主键自增username 唯一登录名password BCrypt 加密后的密码real_name 真实姓名phone 手机号role 角色标识1 管理员、2 医生、3 居民avatar 头像地址status 账号状态1 正常、0 禁用create_time 注册时间医生信息表 doctor_infoid 主键user_id 关联 sys_user 的 iddepartment 科室名称如全科门诊、中医科、儿科title 职称如主治医师、副主任医师intro 医生简介is_online 在线状态这个字段是为未来在线问诊预留的预约记录表 appointmentid 主键patient_user_id 预约的居民用户 iddoctor_user_id 被预约的医生用户 idappointment_date 预约日期time_slot 时段如上午、下午status 状态0 待接诊、1 已接诊、2 已取消symptom_desc 症状描述居民预约时填写create_time 创建时间健康档案表 health_recordid 主键patient_user_id 患者用户 iddoctor_user_id 建档医生 iddiagnosis 诊断结果prescription 医嘱建议record_date 记录日期表之间的关联关系并不复杂通过 user_id 互相引用来体现。这里要特别提一个设计经验不要把医生信息直接堆在用户表里单独拆一张 doctor_info 表这样一旦以后要加医生的职称晋升、科室转调、工作时长等字段扩展起来不动主表结构更可控。3.2 时间字段与状态字段的设计规范设计表的时候有几个细节经常影响系统稳定性先看时间字段。MySQL 中的 datetime 类型在 Java 里对应的是 LocalDateTime但要注意时区问题——服务器设置 UTC 时间后Java 往数据库写时间会自动转换偏移经常出现差了 8 小时的问题。我在数据库连接参数里强制指定了serverTimezoneAsia/Shanghai同时在 SpringBoot 配置文件中设置了spring.jackson.time-zoneGMT8两边对齐基本能根治时区串扰。状态字段统一用 tinyint0 和 1 表达既不花哨也不会出错。遇到类似预约状态这种字段我还会写上注释什么数字代表什么含义表结构里一目了然省得后面维护的人翻半天代码才猜到 2 代表已取消。3.3 数据初始化与测试数据准备建完表之后一定要准备初始化数据否则前端页面展示出来全是空荡荡的。我用一个data.sql文件在项目启动时执行把管理员账号、几个医生信息、排班数据、通知公告记录全部预设好。这样就避免反复手动往数据库里插测试数据尤其当你要把项目交给别人本地运行的时候初始化数据的价值立刻体现出来——别人 clone 项目之后不用折腾数据库启动即用。4. 后端核心实现从接口定义到具体逻辑4.1 项目结构与分层设计后端按照经典的三层架构来组织controller → service → mapper。controller 层只做参数接收和结果封装service 层写业务逻辑和事务mapper 层是 MyBatis 的接口定义配合 XML 或注解写 SQL。这个分层虽然老套但极其稳定你可以在不破坏整体结构的前提下替换任何一层。比如说这一块的结构大致是这样config 包跨域配置、拦截器配置、MyBatis 配置controller 包按模块拆分的控制器service 包业务逻辑实现类mapper 包数据库操作接口entity 包实体类common 包统一返回结果、异常处理器、工具类dto 包参数接收对象用于区分提交参数和数据库实体统一返回结果类 Result 是后端设计里很重要的一个约定。所有接口都返回{ code: 200, message: 操作成功, data: {...} }结构前端拿到结果后根据 code 决定怎么渲染。如果成功则 code 为 200未登录则返回 401业务异常则返回 500。这样前后端对接时心智负担极低你不用每个接口单独设计返回格式。4.2 JWT 认证与拦截器鉴权实现登录流程这里详细讲讲。用户提交用户名密码后后端用 BCrypt 算法比对密码比对成功则签发一个 JWT token 返回给前端。前端把 token 存在 localStorage 里之后每次请求在 axios 请求拦截器里加上Authorization: Bearer token这样一个请求头后端拦截器从 Header 里取 token 并验证。密钥和有效期我放在了 application.yml 中jwt: secret: your-secret-key-change-in-production expire: 86400000有效期的单位是毫秒86400000 正好是 24 小时。生产环境建议把时间缩短到 2-4 小时并且配合前端在 401 时跳转登录页强制重新登录这样即使 token 泄露被滥用的窗口期也不会太长。拦截器实现的时候只用到一个 HandlerInterceptor重写 preHandle 方法在方法里排除掉登录、注册、图片验证码这些不需要认证的路径剩下的路径全部校验 token。校验失败的统一返回 401 状态码和统一的 JSON 信息而不是直接把用户重定向到某个页面——记住后端服务只认数据不认页面前端拿到 401 自行处理跳转逻辑才是分离架构下的正确姿势。关于 BCrypt 再补充一个细节不要用 MD5 去加密密码。MD5 配合彩虹表攻击很容易被破解BCrypt 自带盐值是随机生成的每次加密同一个明文得到的结果都不一样这就能有效防御彩虹表攻击。Spring Security 提供了 BCryptPasswordEncoder但我不想为了一个加密功能引入整套 Security 框架所以直接引用了spring-security-crypto工具包只保留加密和匹配方法轻量好维护。4.3 核心业务接口预约流程的执行细节预约挂号是系统最重要的业务链路它的接口逻辑必须严密防止出现并发超挂的问题。预约接口的 service 层实现步骤是根据医生 id 和预约日期时段做防重复校验查询是否已有预约记录有就直接抛业务异常查询该医生当日时段已经有多少号源被占用如果大于等于设定的排班号源数抛出号源已满异常插入一条预约记录状态设为待接诊更新排班表已约人数这里防并发超挂的技术手段是给数据库操作加行锁。具体做法是在 appointment 表里同一医生同一天同一时段通过唯一索引约束(doctor_user_id, appointment_date, time_slot, patient_user_id)来防止同一个人重复预约通过一个排班表的已约人数字段加上乐观锁控制即 update 的时候带上where already_count max_count条件当影响行数为 0 说明号源已满事务回滚。这种方式不需要显式使用悲观锁也没有死锁风险在医院就诊预约这种并不极端的并发场景下完全够用。如果你要对极端并发做压力测试那需要引入 Redis 分布式锁或者 Redisson 方案但作为社区级系统现在这套实现稳定性和性能已经平衡得很好了。项目临交付前我模拟了并发压力测试30 个线程同时抢最后一个号源最终只有一个请求成功没有超卖。4.4 统计分析模块的数据处理统计分析模块是这类系统的亮点功能也是面试官比较关注的地方。我这里提供了三个统计接口预约趋势、科室热度分布、居民年龄分布。预约趋势的 SQL 实现思路是按日期分组统计预约量查出最近 7 天每天预约量通过 map 转成前端 ECharts 折线图能识别的结构。 科室热度分布则是关联预约表和医生表按医生所属科室分组统计预约量然后用饼图展示。 年龄分布则是从用户表中根据出生年份计算年龄区间然后按区间分组统计。这三种统计接口都只有简单的单表或双表查询没必要上复杂的 OLAP 计算和宽表设计。社区系统数据量在十万级别以内MySQL 原生聚合函数完全秒出结果。要注意的是后端把数据返回给前端的方式我统一采用ListMapString, Object类型前端不用关心实体结构直接透传到图表组件里即可。5. 前端核心实现从页面到交互5.1 项目结构与路由守卫前端项目用 Vue CLI 创建标准的 Vue2 项目结构。src 下面的目录拆成 api、router、store、views、components、utils。api 目录统一存放 axios 请求方法按业务模块拆文件比如 user.js、appointment.js、doctor.js每个方法对应一个后端接口这个习惯能让你在后期维护接口时特别省事。路由配置是关键一环。系统有三类角色菜单显示完全不一样这个动态控制逻辑分为两步第一步在路由表里给所有页面配置 meta 字段里面存 roles 数组指定哪些角色能访问第二步在路由守卫里拿到当前用户信息后判断用户角色通过 router.addRoutes 动态添加可访问路由。登录页到首页的流程是用户登录后后端返回的 data 中不仅包含 token还包括用户信息和角色标识。前端把这些信息存到 Vuex 和 localStorage然后根据角色跳转到对应的首页。之后每次刷新页面时在 App.vue 的 created 钩子里调一次获取用户信息的接口重新把用户信息装入 Vuex防止刷新后路由守卫判断不到角色而导致误拦截。5.2 Axios 封装与请求拦截axios 的封装直接决定前端开发效率我把请求工具单独放在 utils/request.js 里做三层处理第一层是请求拦截器把 token 从 localStorage 取出来放到请求头第二层是响应拦截器如果后端返回 code 200 就直接把 data 抛出如果 code 401 则跳转登录页并清空本地缓存如果 code 500 则全局弹出错误提示框。这套流程下来业务页面里的调用就非常干净。一个实际的请求调用示例// api/user.js import request from /utils/request export function login(data) { return request({ url: /api/auth/login, method: post, data }) } export function getDoctorList(params) { return request({ url: /api/doctor/list, method: get, params }) }页面里调用的时候const res await getDoctorList({ department: 中医科 }) this.doctorList res.data.rows后端返回的字段层级在前端有统一约定data 字段里放具体业务数据List 查询还会包含 total 总数返回给分页组件。这样不管是做页面还是做后续的接口联调双方都知道数据长什么样减少沟通成本。5.3 核心页面逻辑预约挂号页面实现预约挂号页面是前端交互的重点。页面把整个预约流程拆成三个步骤通过一个 stepper 组件引导用户逐步完成每一步对应一个独立的子组件。第一步选择科室。科室列表由后端接口返回页面用卡片式布局展示选中的卡片用高亮边框标识。第二步根据科室筛选医生这里要把医生卡片展示出来卡片上包含医生的头像、姓名、职称、简介和排班信息。排班信息尤其重要用户在选医生时就要看到未来 7 天哪个时段还能约绿色可约、灰色已满。第三步是选择日期时段、填写症状描述确认提交。第三步的后端交互有一个关键设计提交预约之前前端会先调一个查询剩余号源的接口如果发现已经被约满页面立刻给出提示并禁用提交按钮。这虽然不能替代后端的事务并发控制但对用户体验的提升非常明显——与其等用户填完表单提交后才被告知约满不如在交互过程中就拦住。医生端页面主要是查看预约列表和建档。预约列表按日期筛选展示当天患者预约信息医生点击“接诊”后系统弹出建档对话框填写诊断结果和医嘱完成后预约状态变更为已接诊。6. 部署实操本地到服务器全流程6.1 本地开发环境快速启动本地启动这套系统分为三步第一步MySQL 建库建表并把初始化数据导入第二步后端启动用 IDEA 打开 backend 项目等待 Maven 依赖下载完毕后运行 Application 主类第三步前端启动用 VSCode 打开 frontend 项目在终端执行 npm install然后执行 npm run serve浏览器访问本地地址即可。开发阶段需要处理跨域问题。Vue CLI 的 devServer 配置中设置 proxy 代理是最简单的方案// vue.config.js module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样配置后前端请求/api/auth/login会被开发服务器自动转发到http://localhost:8080/api/auth/login浏览器的同源策略不会被触发前端代码里也不用写完整的后端地址全部使用相对路径 /api 开头。6.2 生产环境部署步骤生产环境我建议用一台 2 核 4G 的 Linux 云服务器装好 Nginx、JDK 1.8、MySQL。部署流程如下第一后端打包。在项目根目录执行 Maven 打包命令mvn clean package -DskipTests打包完成后target 目录下会生成一个 jar 包大小大约 50-80MB。通过 FTP 或者命令行工具把 jar 包传到服务器然后运行启动命令nohup java -jar med-community-server.jar --spring.profiles.activeprod server.log 21 nohup 命令让 Java 进程在后台运行输出日志写入 server.log 文件这时候后端服务已经在服务器的 8080 端口待命。第二前端打包。在前端项目目录执行构建npm run build生成 dist 目录里面就是纯静态文件。把 dist 目录下的所有文件通过 FTP 上传到服务器 Nginx 的 html 目录比如/usr/local/nginx/html/med-community/。第三Nginx 配置。这是前后端分离部署的关键点配置文件参考server { listen 80; server_name your-domain.com; location / { root /usr/local/nginx/html/med-community; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这个配置里有三个要点。第一行的 location / 是静态资源服务告诉 Nginx 当访问根路径时去 html 目录找静态文件。第三行的 try_files 配置解决的是 Vue Router 用 history 模式时刷新页面 404 的问题它会把所有非文件路径的请求都回退到 index.html由前端路由接管。第二个 location /api/ 是把所有以 /api 开头的请求转发到后端的 8080 端口。要注意的是生产环境的跨域问题不需要前端代理来处理了因为 Nginx 反向代理让前后端变成了同源浏览器不会出现跨域校验错误。所以在生产打包时axios 的 baseURL 直接用/api相对路径和开发环境保持一致即可。6.3 常见部署问题与排查技巧部署过程一定会遇到问题这里列几个高频问题。第一个是数据库时区报错。启动后端时如果出现The server time zone value Öйú±ê׼ʱ¼ä这样的报错说明 MySQL 连接字符串里没有加时区参数。解决方法是在 JDBC URL 后面加上serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8。第二个是端口被占用。启动后端时如果报端口被占用可以用命令查看占用端口的进程然后杀掉netstat -tlnp | grep 8080 kill -9 进程号第三个是 Nginx 配置改完后没生效。改了 Nginx 配置后必须重启或者执行 reload 命令/usr/local/nginx/sbin/nginx -s reload不执行 reload 或者 restart 的话配置不会自动加载。另外很多第一次用 Nginx 的人会忽略一个细节——改了 html 目录里的前端静态文件后不需要重启 Nginx静态文件是实时读取的刷新浏览器即可看到效果。第四个是前端刷新 404 的问题。如果出现这种状况大概率是 Nginx 配置里少了 try_files 那一行加上并 reload 即可。6.4 服务器防火墙与安全配置服务器安全这块不能省尤其系统里有居民的健康数据属于敏感个人信息。我做的基础加固措施有服务器只开放 80 和 22 端口MySQL 的 3306 端口绝不对外开放只允许本机访问后端接口不使用明文 HTTP 传输生产环境有条件就上 HTTPS现在云平台都能免费申请 SSL 证书数据库账号权限最小化项目启动用的账号只授予需要用的几个库的增删改查权限不给 root 权限。后端代码层面也有几处安全细节登录接口加一个简单的验证码校验防止批量暴力破解密码通过拦截器限制接口的访问频率比如同一账号每分钟只能调用登录接口 10 次超了就临时锁定前端所有用户输入都做长度限制后端也同步做校验防止有人绕过前端直接调接口塞超长数据。7. 常见问题排查与实操心得7.1 联调阶段的核心问题实录这套系统在联调和测试阶段暴露出来的问题最有代表性的有两个。第一个是跨域配置出错导致登录请求发送不了排查方法是打开浏览器开发者工具看网络请求的报错信息如果提示 CORS 相关的字样就说明代理配置没生效或者后端跨域配置有误。常见原因是在 vue.config.js 里配置了代理但后端又同时开启了 CORS 跨域支持两套机制叠加后反而出现预检请求处理异常。解决的思路是开发环境用代理生产用 Nginx 反代后端不开启 CORS 跨域支持反而最稳定。第二个是 Vue 打包后白屏。排查这类问题要按顺序来先看浏览器控制台的报错信息如果提示接口 404那是 Nginx 的 /api 代理路径没配对如果提示静态资源 404那是打包后静态文件路径引用问题需要在 vue.config.js 中设置 publicPath 为相对路径./如果什么资源都不加载查看 Nginx error.log 和 dist 目录的文件权限大概率是上传文件时权限为 root 所有但 Nginx 运行用户是 nobody没有读权限chmod -R 755 解决。7.2 快照备份和回滚方案部署到生产之后每一次大的版本更新都有翻车风险所以养成了快照备份的习惯。在云平台上定期给服务器做快照尤其是更新之前强制手动快照一次。如果部署后系统报错直接回滚到上一个快照服务恢复时间不超过 5 分钟。数据库的话用 mysqldump 做逻辑备份mysqldump -u username -p med_community med_community_$(date %Y%m%d).sql加上 crontab 定时任务每天凌晨备份一次数据库保留最近 7 天重复数据占用空间也不大但关键时刻能救命。7.3 一套可复用的前后端分离开发流程做完这个项目之后我复盘了一下整个流程感觉这套组合拳对中小型管理系统通用性很高。第一步先把数据库表结构设计好这是整个项目的地基表关系理不清后面全是返工第二步后端按模块逐个开发和测试使用 Postman 或 Apifox 管理接口文档第三步前端并行开发根据接口文档模拟数据做页面等后端接口就绪后联调第四步前后端联调完成后打包部署第五步完善部署文档和项目 README。如果你要把这个项目作为独立作品或者毕设展示我强烈建议在部署完成后录制一个 5-10 分钟的功能演示视频把核心流程走一遍并且准备好回答几个关键问题数据库表怎么设计的、预约并发是怎么控制的、JWT 认证是怎么实现的、项目改进方向是什么。面试官或者评审老师问得最多的就是这几个提前梳理清楚很重要。7.4 关于扩展方向的一些建议如果后续想继续完善这套系统有几个扩展方向值得考虑接入在线支付把预约闭环走完整开发一个居民端小程序直接把预约、查档案的功能搬到手机上用 Redis 做缓存和分布式会话提升并发处理能力加上 WebSocket 实时通知医生确认接诊后能主动推送给居民用户。这些方向任何一个拎出来都能做成独立的模块也都能在简历上单独列成一条亮点。我的个人经验是一个项目最终的价值不取决于它用了多少新技术而在于它是不是把一条完整的业务链路走通了。这套社区医疗服务系统从登录注册到预约挂号从医生接诊到档案留存从数据统计到生产部署是一条完整的链路这才是这类项目最值钱的地方。照着上面的步骤和环境动手跑一遍你会对前后端分离开发、权限控制、并发处理、生产部署的整套流程形成一份完整的、属于自己的理解。