简介一份基于Spring Boot框架的医院急诊系统完整源代码采用Java Vue MySQL技术栈适用于毕业设计、课程设计或希望学习前后端分离开发的Java工程师。项目已通过测试可正常运行重点覆盖急诊挂号、分诊、就诊记录等常见业务模块后端基于JDK1.8与Spring Boot构建前端使用Vue组件化开发数据库脚本与配置齐全。压缩包共含852个文件大小约17.7MB其中Java源码、Vue页面、HTML/CSS/JS等前端资源以及SQL脚本、说明文档和部署脚本合理分类便于直接导入Eclipse/IDEA与Navicat快速上手。附带的说明文档对环境要求、部署步骤与常见问题做了整理能大幅降低搭建门槛。目前已有68人学习下载对于需要快速获取一套可运行医疗管理系统参考实现的人来说是实用且完整的素材。1. 一套医院急诊系统能跑多远先说清楚这个项目到底是什么拿到这套基于 springboot 的医院急诊系统源码第一件事不是急着启动而是想清楚它解决的是什么问题。急诊的业务特点是时间敏感、角色多、状态变化频繁护士登记、分诊分级、医生接诊、开单、收费、留观转床每个动作都有严格先后顺序。SpringBoot 负责把后端服务快速组织起来Vue 负责在前端把这些流程和表单铺开MySQL 负责把每一次状态变更落库。这个组合适合毕设、中小医院信息化改造的起步点以及想完整走一遍 Java Vue 全栈开发的从业者。它不追求高并发重点是把急诊流程中的状态管理做扎实。这一点想明白后面看代码、改功能都会顺手很多。2. 技术选型为什么是这套组合SpringBoot、Vue、MySQL 各解决什么问题2.1 后端SpringBoot 解决的三个实际问题先讲一个容易忽略的事实急诊系统这类管理项目绝大多数后端代码都是“围绕一张主表的增删改查”真正的复杂度在于流程节点和状态约束。SpringBoot 被选中不是因为性能天花板高而是因为它能把这些约束快速落地、结构还清晰主要解决三个实际问题。第一是约定大于配置。以前做 SSHStruts Spring Hibernate或者原生 SpringMVC搭一个可用工程要配一堆 XML数据源、事务、映射文件各管一段新人接手上手成本很高。SpringBoot 把默认配置收敛到 application.yml打开就能看到端口、数据库连接、MyBatis 扫描路径改起来不靠玄学这对二开和交接非常友好。第二是内嵌 Tomcat部署成本低。医院内网环境经常没有独立的中间件运维SpringBoot 打出的可执行 jar 直接 java -jar 就能跑不需要单独装 Tomcat、改 server.xml。这个特点对中小医院信息科或者教学演示场景来说比任何微服务架构都实在。第三是 starter 生态成熟。mybatis-spring-boot-starter、spring-boot-starter-web、spring-boot-starter-security 这些依赖把常用能力打包好版本由 parent 统一管理省去手动对齐依赖版本的血泪经验。项目里常见还会引入 druid 连接池、lombok、hutool 这类工具都是围绕“少写重复代码”这个目标。需要提醒的是SpringBoot 2.x 和 3.x 差异很大看源码包里的 pom.xml 时先确认 spring-boot-starter-parent 版本再去配 JDK。否则会出现一大堆“类找不到”的翻车情况这个在第 5 章展开。2.2 前端Vue 组件化开发与开发环境代理Vue 在同类源码里出镜率极高的原因是它把急诊工作台这类“信息密集页”拆得很舒服。护士分诊台要展示候诊列表、患者详情、分诊级别选择医生工作台要同时关注在诊患者、历史病历、床位状态。如果用 JSP 做这类页面最后往往会变成一大坨服务端拼出来的 HTML改一处样式牵全身。用 Vue 可以把页面拆成组件患者列表表格一个组件分诊表单一个组件状态标签一个组件。每个组件只维护自己的数据和事件代码量不减少但维护边界清楚很多。需要先看 package.json 确定是 Vue 2 还是 Vue 3。老一点的急诊系统源码大量是 Vue 2 Element UI新一些的会直接上 Vue 3 Element Plus。这里补一个“不要盲目升级”的点如果源码本身是 Vue 2别为了赶新把它整体升到 Vue 3。Element UI 和 Element Plus 的组件 API 不兼容升级工作量不亚于重写前端。二次开发时版本跟着源码走不要跟着“最新网络热词”走。开发阶段还有个必配项是跨域代理。前后端分离时前端跑 8080 端口后端跑 8081 端口浏览器直接请求后端接口会被跨域拦掉。常见做法是在 vue.config.js 里配置 devServer.proxy// vue.config.js module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true, pathRewrite: { ^/api: } } } } }这段配置的意思是前端开发服务器把所有以 /api 开头的请求转发到 8081 端口的后端服务并把路径前缀去掉。比如前端请求 /api/login后端实际收到的是 /login。pathRewrite 参数必须和后端 Controller 的 RequestMapping 对上很多项目启动后接口 404就是这里前缀没对齐。2.3 数据库MySQL 为急诊业务预留的时间与状态约束MySQL 在这个项目里承担的是业务状态落库的核心角色。急诊系统表面上表不少但核心逻辑非常聚焦患者来诊后围绕一次“来诊记录”不断更新状态。所以建表时首先要有一张类似 emergency_visit 的主记录表而不是把状态散落到各个业务表里。这种设计的好处是把流程主线拎出来。看代码时优先看这张表的状态字段从 0 变到几、由哪个接口触发就能理解整个系统。MySQL 8.0 是目前这类源码的主流配置它支持窗口函数、支持更好的 utf8mb4 字符集。如果你做二开字符集一定在建库时就写成 utf8mb4不要用默认的 utf8才能保证患者姓名里的生僻字不乱码。急诊业务还有一个特点是时间字段特别多来诊时间、分诊时间、接诊时间、转归时间。这些字段不仅要存还要建索引因为分诊台最常见的查询就是“今天来了哪些人、按时间排序”没有索引数据量一上来就卡。另外夹一句Java 开发工程师面试题里经常问“数据库物理外键到底建不建”这类项目普遍选择逻辑外键也就是只在业务层做关联约束数据库层面不加 FOREIGN KEY。原因很简单急诊业务高频率更新一张主表物理外键在多表关联写入时容易造成额外的锁开销中小系统用逻辑外键更灵活。3. 把项目跑起来JDK、Maven、Node 与 MySQL 环境的组合配置3.1 版本搭配表JDK、SpringBoot、Node、MySQL 怎么配对这类源码最容易在环境环节翻车原因不是操作难而是版本组合不对。第一件事是打开 pom.xml 看 spring-boot-starter-parent 的版本再决定本地 JDK 和 Maven 版本顺序不能反过来。我用过的两套稳定组合整理如下成员组合 A老项目常见组合 B新项目常见JDK1.817 或 21SpringBoot2.7.x3.xMaven3.6.3 以上3.9.xMySQL5.7 或 8.08.0Node.js14 到 1618 以上VueVue 2.6 / 2.7Vue 3UI 库Element UIElement Plus我一般会建议先按组合 A 来跑老项目不要一上来就装 JDK 17 去打开一个 SpringBoot 2.x 项目。SpringBoot 2.7.x 在 JDK 17 上勉强能运行但某些版本反射报错很隐蔽你会在启动日志里看到一个完全看不懂的堆栈。反过来SpringBoot 3.x 强制要求 JDK 17用 JDK 8 直接启动失败。所以这个表不是随便列的是方向性问题。3.2 先用说明文档和 SQL 脚本把数据库建起来压缩包里通常有一个 sql 文件比如 hospital_emergency.sql以及一份说明文档。先把数据库建好再启动后端顺序可以避免后端一启动就因连不上库报红。打开命令行工具进入 sql 文件所在目录执行mysql -u root -p --default-character-setutf8登录后创建数据库并导入脚本CREATE DATABASE hospital_emergency DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hospital_emergency; SOURCE /你的绝对路径/hospital_emergency.sql;说明一下参数mysql 命令的 --default-character-setutf8 保证客户端向服务端发送 SQL 时按 UTF-8 编码传输防止中文表备注和初始数据乱码CREATE DATABASE 语句里显式指定 utf8mb4是防止 MySQL 8 默认字符集在部分服务器上仍是 latin1。导入完成后执行 SHOW TABLES;能看到十几张核心表说明脚本执行成功。接着修改后端的数据库配置。打开 src/main/resources/application.yml把数据源信息改成你刚创建的库spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hospital_emergency?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码url 里有三个参数很关键characterEncodingutf8 对应入库字符集useSSLfalse 能绕开 MySQL 8 默认 SSL 导致的握手报错serverTimezoneAsia/Shanghai 是为了解决 JDBC 连接时区差 8 小时的问题。这三个参数缺一个都有可能在后端日志里看到不同风格的报错属于最常见的坑位。3.3 后端与前端的最小启动命令环境配置好后启动项目是最简单的但也别直接双击 jar 完事。最好先在 IDEA 里打开后端工程让它自动通过 Maven 拉取依赖。IDEA 的配置注意两点Maven 的 settings.xml 指向你自己的本地仓库JDK 版本和 pom 对齐两个都对了再点启动。后端完整启动命令就一条在项目根目录下执行mvn spring-boot:run如果只想部署运行可以先打包再启动mvn clean package -DskipTests java -jar target/hospital-emergency-0.0.1-SNAPSHOT.jarmvn spring-boot:run 的好处是开发时改了代码可以直接热重启缺点是终端日志会被断点调试干扰。java -jar 适合确认打包产物能跑。这里注意 -DskipTests 只是跳过测试执行不会跳过测试代码编译如果测试类本身有语法问题还是会失败。前端启动稍微麻烦一点因为要先安装 npm 依赖npm install npm run devnpm install 如果网络不稳定可以把 registry 临时切到国内镜像npm install --registryhttps://registry.npmmirror.com这里不建议直接永久改全局 registry因为公开仓库和某些私有源混用时版本解析会出现意想不到的“无法找到依赖”问题属于不必要的冒险。npm run dev 执行后终端会打印一个本地访问地址一般是 http://localhost:8080浏览器打开看到登录页环境配置这一步就过关了。4. 看懂核心代码急诊接诊流程的状态流转与接口分层4.1 emergency_visit 表时间、分诊级别与状态字段怎么设计想快速摸清一套源码的骨架不要从 Controller 看起先从核心表开始。急诊系统核心表通常是 emergency_visit表结构长这样CREATE TABLE emergency_visit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL COMMENT 患者ID, arrival_time DATETIME NOT NULL COMMENT 来诊时间, triage_level VARCHAR(10) DEFAULT NULL COMMENT 分诊级别I/II/III/IV, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0登记 1分诊完成 2待就诊 3就诊中 4留观 5离院, doctor_id BIGINT DEFAULT NULL COMMENT 接诊医生ID, department_id BIGINT DEFAULT NULL COMMENT 就诊科室ID, bed_no VARCHAR(32) DEFAULT NULL COMMENT 留观床位号, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, version INT DEFAULT 0 COMMENT 乐观锁版本号, KEY idx_arrival_time (arrival_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT急诊来诊记录表;这张表最有价值的设计是三字段组合arrival_time 用于分诊台按时间排序triage_level 记录病情分级status 记录流程当前走到哪一步。status 用 TINYINT 而不是 VARCHAR因为在 Java 里可以用枚举或常量类映射避免“已离院”和“已出院”这种在数据库里写两套的脏数据问题。version 字段是给乐观锁用的下面一节会讲到。另外分诊级别 I 到 IV 不是随便写的。I 级是濒危患者必须立即抢救II 级是危重III 级是急症IV 级是非急症。这套分级标准在急诊科是基本功代码里 triage_level 字典也会按这个设计二开时不要改它的含义否则分诊台页面和护理记录会对不上。4.2 后端 Service 的状态流转校验与事务处理很多增删改查项目的问题不是代码不会写而是状态流转没约束。比如一条已经“离院”的记录又被某个接口改回了“就诊中”这在急诊系统里是医疗记录事故。所以核心 Service 里通常会有一个状态流转校验逻辑。我一般会这样写public static final int STATUS_REGISTERED 0; public static final int STATUS_TRIAGED 1; public static final int STATUS_WAITING 2; public static final int STATUS_IN_CONSULT 3; public static final int STATUS_OBSERVATION 4; public static final int STATUS_DISCHARGED 5; private static final MapInteger, SetInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(STATUS_REGISTERED, Set.of(STATUS_TRIAGED)); TRANSITIONS.put(STATUS_TRIAGED, Set.of(STATUS_WAITING)); TRANSITIONS.put(STATUS_WAITING, Set.of(STATUS_IN_CONSULT)); TRANSITIONS.put(STATUS_IN_CONSULT, Set.of(STATUS_OBSERVATION, STATUS_DISCHARGED)); TRANSITIONS.put(STATUS_OBSERVATION, Set.of(STATUS_DISCHARGED)); } Transactional(rollbackFor Exception.class) public boolean updateStatus(Long visitId, int targetStatus, Long operatorId) { EmergencyVisit visit visitMapper.selectById(visitId); if (visit null) { throw new BusinessException(来诊记录不存在); } SetInteger allowed TRANSITIONS.get(visit.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BusinessException(不允许从当前状态流转到目标状态: visit.getStatus() - targetStatus); } int updated visitMapper.optimisticUpdateStatus(visitId, visit.getVersion(), targetStatus); if (updated 0) { throw new BusinessException(数据已被其他人修改请刷新后重试); } return true; }这段代码在绝大多数同类源码里都会以类似的形态出现。TRANSITIONS 这个 Map 本质是一张状态机表它把允许的流转路径集中管理而不是散落在各个 Service 方法里。Transactional 保证了状态更新和后续的日志记录在同一个事务里一旦失败整体回滚。optimisticUpdateStatus 是乐观锁更新执行时会在 SQL 里带上 version 条件UPDATE emergency_visit SET status #{targetStatus}, version version 1 WHERE id #{visitId} AND version #{visitVersion}这里有一个容易翻车的点如果不做乐观锁两个护士同时在分诊台操作同一条记录后提交的人会把前一个人的状态覆盖掉。加了 version 条件后后提交的人更新行数为 0系统提示“数据已被其他人修改”这就是避免数据错乱的关键防线。4.3 前端路由与 axios 拦截把页面和接口接起来前端部分先看 router 配置再看接口请求封装。老一点的项目用的是 vue-router 的路由表新项目可能会改成动态路由。这个源码的常见形态是静态路由 登录后根据角色控制按钮级权限而不是后端动态下发路由。看路由文件能快速知道系统有哪些页面登录页、分诊台、医生工作台、收费管理、床位管理、系统管理。axios 的封装一般集中在 request.js 里核心是请求拦截器和响应拦截器// request.js import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service注意 baseURL 写的是 /api这和 2.2 节里 vue.config.js 的代理前缀是配套的。开发环境通过 devServer 转发到后端生产环境则需要后端接口本身就带 /api 前缀或者再把请求路径处理一下。这是前后端分离项目最容易对不上的地方。Authorization 携带 token 是一种主流方式后端用拦截器或 Spring Security 验证这个 header。响应拦截器里统一判断 code 字段遇到 401 就清掉本地 token 并跳回登录页。这个设计保证后端接口返回未登录状态时前端不会停留在半死不活的白屏页面上。5. 急诊系统最常见的 5 个坑从启动失败到数据错乱5.1 MySQL 8 连不上SSL 握手失败与 allowPublicKeyRetrieval现象后端启动控制台报 Communications link failure或者提示 Public Key Retrieval is not allowed有些版本直接抛 SSLConnectionError。原因MySQL 8 默认使用 caching_sha2_password 认证插件客户端第一次连接时需要从服务端获取 RSA 公钥而 JDBC 驱动默认不允许这个行为同时 MySQL 8 默认开启了 SSL 连接本地开发环境经常没有配置证书两件事叠加就成了启动报错。解决在 JDBC 连接串上显式关闭 SSL 并允许公钥检索修改 application.yml 的 urljdbc:mysql://localhost:3306/hospital_emergency?useSSLfalseallowPublicKeyRetrievaltruecharacterEncodingutf8serverTimezoneAsia/Shanghai其中 allowPublicKeyRetrievaltrue 适用于内网开发环境生产环境安全性要求高时可以改用服务器上的 CA 证书或者确认网络加密方式后再关掉。这个参数属于“开发环境后悔药”别随意搬到公网环境。5.2 SpringBoot 版本太高javax 被替换成 jakarta 后的连锁报错现象项目在别人电脑上好好的自己本地从 SpringBoot 官网模板新建工程然后把源码的代码复制进来启动直接报符号找不到 javax.servlet.Filter或者大量红色 import 报错。原因SpringBoot 3.x 把 Java EE 的包命名从 javax.* 迁移到了 jakarta.*Servlet API、持久化 API 都换了根包名。网上很多旧教程和旧代码还是 javax 开头版本一对不上就翻车。解决不升级。打开 pom.xml看 spring-boot-starter-parent 里的版本号如果是 2.x本地 JDK 用 1.8并把 IDE 里项目的 Language Level 调成 8。如果确实要用 SpringBoot 3.x把项目里所有 javax.servlet、javax.persistence 之类的 import 全改成 jakarta.servlet、jakarta.persistence同时检查 druid 等中间件版本是否支持 SpringBoot 3。没有金刚钻别揽这个瓷器活。5.3 Vue 路由白屏打包进 static 后刷新就 404 的原因现象前端开发模式一切正常npm run build 之后把 dist 目录扔进 SpringBoot 的 static 目录后端启动浏览器打开首页是空白的或者直接报 404。原因vue-router 默认使用 history 模式路由路径会变成真实的 URL 路径比如 /workbench。SpringBoot 对静态资源的处理是“按文件查找”它找不到 /workbench 这个物理文件就回落到 404而不是自动返回 index.html。开发模式下刷新没事是因为 devServer 做了 historyApiFallback生产环境没有这层处理。解决最省事的方式是把 vue-router 切回 hash 模式URL 变成 /#/workbench所有内容都在 index.html 内部解析不经过后端的路径匹配。改一行const router new VueRouter({ mode: hash, routes })如果非要保留 history 模式需要在后端加一个转发配置让所有非静态资源路径都进 index.html。这里给出一种常规写法Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController(/{path:[^\\.]*}).setViewName(forward:/index.html); } }这段配置的意思是所有不带文件扩展名的路径请求都直接转发到 index.html由前端路由接管。需要注意这个写法会影响后端接口路径吗不会因为 controller 的映射优先于 view controller 匹配。但如果你把前后端接口也放在同一域名下建议接口统一加 /api 前缀避免转发规则误伤接口。5.4 Navicat 导入 SQL 乱码字符集在连接层就被带偏了现象用 Navicat 打开 SQL 文件并执行建表成功但表注释、初始数据里的中文全是问号或者报错 Incorrect string value。原因Navicat 新建查询时连接的字符集默认可能不是 utf8mb4而 SQL 文件本身是 UTF-8 编码。执行时连接层把字节按照错误的字符集解释写入到表里就成了乱码。更隐蔽的是Windows 记事本另存为 UTF-8 时可能带 BOM 头BOM 会让第一条 SQL 语句报语法错误。解决不要双击运行 SQL 文件。先在 Navicat 里右键数据库连接选择“编辑连接”在高级设置里把编码改为 utf8mb4然后新建数据库时也明确选择字符集 utf8mb4最后手动打开 SQL 文件全选执行。如果 SQL 文件是 GBK 编码的先转成 UTF-8 无 BOM 再导入不要偷懒。命令行导入时一定要带 --default-character-setutf8这个参数在前面第 3 章也强调过它是乱码场景的第一道防线。5.5 数据源配置没生效多环境 profile 与配置优先级现象明明在 application.yml 里把端口改成了 8081启动日志却还是 8080或者数据库连接的库名和配置里不一样像是被“黑匣子”盖住了。原因SpringBoot 支持多环境 profile项目里可能同时存在 application-dev.yml、application-prod.yml其中 application-dev.yml 里的配置覆盖了主配置。IDEA 启动时也可能自动激活了 dev profile而你又没看启动日志里的这条提示“The following profiles are active: dev”。解决遇到配置不生效先看启动日志最前面几行有没有打印激活的 profile再检查 resources 目录下是否存在其他 application-*.yml 文件。如果是 IDEA 里多了一个 active profile 参数把启动配置里的 VM options 和 Environment variables 检查清楚。强制指定环境可以在启动时加参数java -jar hospital-emergency.jar --spring.profiles.activeprod另外要记住 SpringBoot 配置优先级外部命令行参数大于外部配置文件大于 jar 包内的配置文件。很多人改了 jar 包里的 yml 不生效是因为部署目录下多了一个 application.yml那个文件优先级更高。这个规则不复杂但确实能解释很多“改了没反应”的诡异现象。6. 一个让部署更顺的技巧把 Vue 构建产物收进 SpringBoot 做单端口发布6.1 dist 目录的复制与静态资源映射很多项目开发时跑两个端口部署时又加一台 Nginx 做转发成本不高但维护面变大。对于医院急诊系统这种并发不高、要快速交付的场景我更推荐单端口方案Vue 打包成静态文件扔进 SpringBoot 的 src/main/resources/static后端打包成一个 jar。这样运维只需要关心一个进程、一个端口。正式操作分三步。第一步前端执行 npm run build生成 dist 目录里面是 index.html 和一堆带哈希的 js、css 文件。第二步把 dist 目录里的所有内容复制到后端项目 src/main/resources/static 下。第三步重新打包后端并启动mvn clean package -DskipTests java -jar target/hospital-emergency-0.0.1-SNAPSHOT.jar启动后浏览器访问 http://IP:8080/ 就能看到登录页。这个方案的关键前提是前端路由必须使用 hash 模式原因在第 5.3 节已经说过history 模式在单 jar 部署下会频繁 404。复制后还要检查 index.html 里引用的 css 和 js 路径是不是相对路径如果打包时配置了绝对路径 /assets/访问时也会找不到。如果前端请求的是 /api 前缀后端接口也最好保持 /api 前缀这样静态资源和接口在同一域名下不冲突。我一般会在后端 application.yml 里增加一个全局前缀或者直接在 Controller 的 RequestMapping 上统一写 /api。这个细节决定了部署后前端请求会不会被静态资源转发规则误伤属于吃过亏才记得住的操作。6.2 同源部署后的验证顺序部署完成后不要直接点登录。按下面顺序过一遍能提前发现大多数隐藏问题步骤操作预期结果1浏览器强制刷新访问根路径能看到登录页控制台无 4042打开 Network 面板看登录接口请求路径是 /api/login返回 JSON3登录后刷新页面停留在当前页面不跳回登录页4操作一次分诊流转数据库状态字段按预期变化5打开一个新的无痕窗口未登录访问被拦截跳转登录页第 3 步最容易暴露路由问题登录后正常跳转一刷新就白屏或 404这几乎可以断定是 history 路由模式没有切换属于第 5.3 节的坑位。第 5 步验证的是后端拦截器对未登录请求的处理很多项目登录页能出但 token 失效后不会跳转卡在一个报错页面上。做这类项目我的一个习惯是拿到源码后先不急着改业务先用最小配置把前后端跑通再对核心表画一张状态流转图然后才动手改代码。状态流转图可以帮助你在改接口时看清边界避免把后端的规则写死在前端页面上。希望这个思路能帮你在接手这套医院急诊系统时少走一些我当年走过的弯路。本文还有配套的精品资源点击获取 SpringBoot+Vue+MySQL医院急诊系统：状态流转设计与全栈部署实践
简介一份基于Spring Boot框架的医院急诊系统完整源代码采用Java Vue MySQL技术栈适用于毕业设计、课程设计或希望学习前后端分离开发的Java工程师。项目已通过测试可正常运行重点覆盖急诊挂号、分诊、就诊记录等常见业务模块后端基于JDK1.8与Spring Boot构建前端使用Vue组件化开发数据库脚本与配置齐全。压缩包共含852个文件大小约17.7MB其中Java源码、Vue页面、HTML/CSS/JS等前端资源以及SQL脚本、说明文档和部署脚本合理分类便于直接导入Eclipse/IDEA与Navicat快速上手。附带的说明文档对环境要求、部署步骤与常见问题做了整理能大幅降低搭建门槛。目前已有68人学习下载对于需要快速获取一套可运行医疗管理系统参考实现的人来说是实用且完整的素材。1. 一套医院急诊系统能跑多远先说清楚这个项目到底是什么拿到这套基于 springboot 的医院急诊系统源码第一件事不是急着启动而是想清楚它解决的是什么问题。急诊的业务特点是时间敏感、角色多、状态变化频繁护士登记、分诊分级、医生接诊、开单、收费、留观转床每个动作都有严格先后顺序。SpringBoot 负责把后端服务快速组织起来Vue 负责在前端把这些流程和表单铺开MySQL 负责把每一次状态变更落库。这个组合适合毕设、中小医院信息化改造的起步点以及想完整走一遍 Java Vue 全栈开发的从业者。它不追求高并发重点是把急诊流程中的状态管理做扎实。这一点想明白后面看代码、改功能都会顺手很多。2. 技术选型为什么是这套组合SpringBoot、Vue、MySQL 各解决什么问题2.1 后端SpringBoot 解决的三个实际问题先讲一个容易忽略的事实急诊系统这类管理项目绝大多数后端代码都是“围绕一张主表的增删改查”真正的复杂度在于流程节点和状态约束。SpringBoot 被选中不是因为性能天花板高而是因为它能把这些约束快速落地、结构还清晰主要解决三个实际问题。第一是约定大于配置。以前做 SSHStruts Spring Hibernate或者原生 SpringMVC搭一个可用工程要配一堆 XML数据源、事务、映射文件各管一段新人接手上手成本很高。SpringBoot 把默认配置收敛到 application.yml打开就能看到端口、数据库连接、MyBatis 扫描路径改起来不靠玄学这对二开和交接非常友好。第二是内嵌 Tomcat部署成本低。医院内网环境经常没有独立的中间件运维SpringBoot 打出的可执行 jar 直接 java -jar 就能跑不需要单独装 Tomcat、改 server.xml。这个特点对中小医院信息科或者教学演示场景来说比任何微服务架构都实在。第三是 starter 生态成熟。mybatis-spring-boot-starter、spring-boot-starter-web、spring-boot-starter-security 这些依赖把常用能力打包好版本由 parent 统一管理省去手动对齐依赖版本的血泪经验。项目里常见还会引入 druid 连接池、lombok、hutool 这类工具都是围绕“少写重复代码”这个目标。需要提醒的是SpringBoot 2.x 和 3.x 差异很大看源码包里的 pom.xml 时先确认 spring-boot-starter-parent 版本再去配 JDK。否则会出现一大堆“类找不到”的翻车情况这个在第 5 章展开。2.2 前端Vue 组件化开发与开发环境代理Vue 在同类源码里出镜率极高的原因是它把急诊工作台这类“信息密集页”拆得很舒服。护士分诊台要展示候诊列表、患者详情、分诊级别选择医生工作台要同时关注在诊患者、历史病历、床位状态。如果用 JSP 做这类页面最后往往会变成一大坨服务端拼出来的 HTML改一处样式牵全身。用 Vue 可以把页面拆成组件患者列表表格一个组件分诊表单一个组件状态标签一个组件。每个组件只维护自己的数据和事件代码量不减少但维护边界清楚很多。需要先看 package.json 确定是 Vue 2 还是 Vue 3。老一点的急诊系统源码大量是 Vue 2 Element UI新一些的会直接上 Vue 3 Element Plus。这里补一个“不要盲目升级”的点如果源码本身是 Vue 2别为了赶新把它整体升到 Vue 3。Element UI 和 Element Plus 的组件 API 不兼容升级工作量不亚于重写前端。二次开发时版本跟着源码走不要跟着“最新网络热词”走。开发阶段还有个必配项是跨域代理。前后端分离时前端跑 8080 端口后端跑 8081 端口浏览器直接请求后端接口会被跨域拦掉。常见做法是在 vue.config.js 里配置 devServer.proxy// vue.config.js module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true, pathRewrite: { ^/api: } } } } }这段配置的意思是前端开发服务器把所有以 /api 开头的请求转发到 8081 端口的后端服务并把路径前缀去掉。比如前端请求 /api/login后端实际收到的是 /login。pathRewrite 参数必须和后端 Controller 的 RequestMapping 对上很多项目启动后接口 404就是这里前缀没对齐。2.3 数据库MySQL 为急诊业务预留的时间与状态约束MySQL 在这个项目里承担的是业务状态落库的核心角色。急诊系统表面上表不少但核心逻辑非常聚焦患者来诊后围绕一次“来诊记录”不断更新状态。所以建表时首先要有一张类似 emergency_visit 的主记录表而不是把状态散落到各个业务表里。这种设计的好处是把流程主线拎出来。看代码时优先看这张表的状态字段从 0 变到几、由哪个接口触发就能理解整个系统。MySQL 8.0 是目前这类源码的主流配置它支持窗口函数、支持更好的 utf8mb4 字符集。如果你做二开字符集一定在建库时就写成 utf8mb4不要用默认的 utf8才能保证患者姓名里的生僻字不乱码。急诊业务还有一个特点是时间字段特别多来诊时间、分诊时间、接诊时间、转归时间。这些字段不仅要存还要建索引因为分诊台最常见的查询就是“今天来了哪些人、按时间排序”没有索引数据量一上来就卡。另外夹一句Java 开发工程师面试题里经常问“数据库物理外键到底建不建”这类项目普遍选择逻辑外键也就是只在业务层做关联约束数据库层面不加 FOREIGN KEY。原因很简单急诊业务高频率更新一张主表物理外键在多表关联写入时容易造成额外的锁开销中小系统用逻辑外键更灵活。3. 把项目跑起来JDK、Maven、Node 与 MySQL 环境的组合配置3.1 版本搭配表JDK、SpringBoot、Node、MySQL 怎么配对这类源码最容易在环境环节翻车原因不是操作难而是版本组合不对。第一件事是打开 pom.xml 看 spring-boot-starter-parent 的版本再决定本地 JDK 和 Maven 版本顺序不能反过来。我用过的两套稳定组合整理如下成员组合 A老项目常见组合 B新项目常见JDK1.817 或 21SpringBoot2.7.x3.xMaven3.6.3 以上3.9.xMySQL5.7 或 8.08.0Node.js14 到 1618 以上VueVue 2.6 / 2.7Vue 3UI 库Element UIElement Plus我一般会建议先按组合 A 来跑老项目不要一上来就装 JDK 17 去打开一个 SpringBoot 2.x 项目。SpringBoot 2.7.x 在 JDK 17 上勉强能运行但某些版本反射报错很隐蔽你会在启动日志里看到一个完全看不懂的堆栈。反过来SpringBoot 3.x 强制要求 JDK 17用 JDK 8 直接启动失败。所以这个表不是随便列的是方向性问题。3.2 先用说明文档和 SQL 脚本把数据库建起来压缩包里通常有一个 sql 文件比如 hospital_emergency.sql以及一份说明文档。先把数据库建好再启动后端顺序可以避免后端一启动就因连不上库报红。打开命令行工具进入 sql 文件所在目录执行mysql -u root -p --default-character-setutf8登录后创建数据库并导入脚本CREATE DATABASE hospital_emergency DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hospital_emergency; SOURCE /你的绝对路径/hospital_emergency.sql;说明一下参数mysql 命令的 --default-character-setutf8 保证客户端向服务端发送 SQL 时按 UTF-8 编码传输防止中文表备注和初始数据乱码CREATE DATABASE 语句里显式指定 utf8mb4是防止 MySQL 8 默认字符集在部分服务器上仍是 latin1。导入完成后执行 SHOW TABLES;能看到十几张核心表说明脚本执行成功。接着修改后端的数据库配置。打开 src/main/resources/application.yml把数据源信息改成你刚创建的库spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hospital_emergency?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码url 里有三个参数很关键characterEncodingutf8 对应入库字符集useSSLfalse 能绕开 MySQL 8 默认 SSL 导致的握手报错serverTimezoneAsia/Shanghai 是为了解决 JDBC 连接时区差 8 小时的问题。这三个参数缺一个都有可能在后端日志里看到不同风格的报错属于最常见的坑位。3.3 后端与前端的最小启动命令环境配置好后启动项目是最简单的但也别直接双击 jar 完事。最好先在 IDEA 里打开后端工程让它自动通过 Maven 拉取依赖。IDEA 的配置注意两点Maven 的 settings.xml 指向你自己的本地仓库JDK 版本和 pom 对齐两个都对了再点启动。后端完整启动命令就一条在项目根目录下执行mvn spring-boot:run如果只想部署运行可以先打包再启动mvn clean package -DskipTests java -jar target/hospital-emergency-0.0.1-SNAPSHOT.jarmvn spring-boot:run 的好处是开发时改了代码可以直接热重启缺点是终端日志会被断点调试干扰。java -jar 适合确认打包产物能跑。这里注意 -DskipTests 只是跳过测试执行不会跳过测试代码编译如果测试类本身有语法问题还是会失败。前端启动稍微麻烦一点因为要先安装 npm 依赖npm install npm run devnpm install 如果网络不稳定可以把 registry 临时切到国内镜像npm install --registryhttps://registry.npmmirror.com这里不建议直接永久改全局 registry因为公开仓库和某些私有源混用时版本解析会出现意想不到的“无法找到依赖”问题属于不必要的冒险。npm run dev 执行后终端会打印一个本地访问地址一般是 http://localhost:8080浏览器打开看到登录页环境配置这一步就过关了。4. 看懂核心代码急诊接诊流程的状态流转与接口分层4.1 emergency_visit 表时间、分诊级别与状态字段怎么设计想快速摸清一套源码的骨架不要从 Controller 看起先从核心表开始。急诊系统核心表通常是 emergency_visit表结构长这样CREATE TABLE emergency_visit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL COMMENT 患者ID, arrival_time DATETIME NOT NULL COMMENT 来诊时间, triage_level VARCHAR(10) DEFAULT NULL COMMENT 分诊级别I/II/III/IV, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0登记 1分诊完成 2待就诊 3就诊中 4留观 5离院, doctor_id BIGINT DEFAULT NULL COMMENT 接诊医生ID, department_id BIGINT DEFAULT NULL COMMENT 就诊科室ID, bed_no VARCHAR(32) DEFAULT NULL COMMENT 留观床位号, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, version INT DEFAULT 0 COMMENT 乐观锁版本号, KEY idx_arrival_time (arrival_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT急诊来诊记录表;这张表最有价值的设计是三字段组合arrival_time 用于分诊台按时间排序triage_level 记录病情分级status 记录流程当前走到哪一步。status 用 TINYINT 而不是 VARCHAR因为在 Java 里可以用枚举或常量类映射避免“已离院”和“已出院”这种在数据库里写两套的脏数据问题。version 字段是给乐观锁用的下面一节会讲到。另外分诊级别 I 到 IV 不是随便写的。I 级是濒危患者必须立即抢救II 级是危重III 级是急症IV 级是非急症。这套分级标准在急诊科是基本功代码里 triage_level 字典也会按这个设计二开时不要改它的含义否则分诊台页面和护理记录会对不上。4.2 后端 Service 的状态流转校验与事务处理很多增删改查项目的问题不是代码不会写而是状态流转没约束。比如一条已经“离院”的记录又被某个接口改回了“就诊中”这在急诊系统里是医疗记录事故。所以核心 Service 里通常会有一个状态流转校验逻辑。我一般会这样写public static final int STATUS_REGISTERED 0; public static final int STATUS_TRIAGED 1; public static final int STATUS_WAITING 2; public static final int STATUS_IN_CONSULT 3; public static final int STATUS_OBSERVATION 4; public static final int STATUS_DISCHARGED 5; private static final MapInteger, SetInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(STATUS_REGISTERED, Set.of(STATUS_TRIAGED)); TRANSITIONS.put(STATUS_TRIAGED, Set.of(STATUS_WAITING)); TRANSITIONS.put(STATUS_WAITING, Set.of(STATUS_IN_CONSULT)); TRANSITIONS.put(STATUS_IN_CONSULT, Set.of(STATUS_OBSERVATION, STATUS_DISCHARGED)); TRANSITIONS.put(STATUS_OBSERVATION, Set.of(STATUS_DISCHARGED)); } Transactional(rollbackFor Exception.class) public boolean updateStatus(Long visitId, int targetStatus, Long operatorId) { EmergencyVisit visit visitMapper.selectById(visitId); if (visit null) { throw new BusinessException(来诊记录不存在); } SetInteger allowed TRANSITIONS.get(visit.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BusinessException(不允许从当前状态流转到目标状态: visit.getStatus() - targetStatus); } int updated visitMapper.optimisticUpdateStatus(visitId, visit.getVersion(), targetStatus); if (updated 0) { throw new BusinessException(数据已被其他人修改请刷新后重试); } return true; }这段代码在绝大多数同类源码里都会以类似的形态出现。TRANSITIONS 这个 Map 本质是一张状态机表它把允许的流转路径集中管理而不是散落在各个 Service 方法里。Transactional 保证了状态更新和后续的日志记录在同一个事务里一旦失败整体回滚。optimisticUpdateStatus 是乐观锁更新执行时会在 SQL 里带上 version 条件UPDATE emergency_visit SET status #{targetStatus}, version version 1 WHERE id #{visitId} AND version #{visitVersion}这里有一个容易翻车的点如果不做乐观锁两个护士同时在分诊台操作同一条记录后提交的人会把前一个人的状态覆盖掉。加了 version 条件后后提交的人更新行数为 0系统提示“数据已被其他人修改”这就是避免数据错乱的关键防线。4.3 前端路由与 axios 拦截把页面和接口接起来前端部分先看 router 配置再看接口请求封装。老一点的项目用的是 vue-router 的路由表新项目可能会改成动态路由。这个源码的常见形态是静态路由 登录后根据角色控制按钮级权限而不是后端动态下发路由。看路由文件能快速知道系统有哪些页面登录页、分诊台、医生工作台、收费管理、床位管理、系统管理。axios 的封装一般集中在 request.js 里核心是请求拦截器和响应拦截器// request.js import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push(/login) } Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service注意 baseURL 写的是 /api这和 2.2 节里 vue.config.js 的代理前缀是配套的。开发环境通过 devServer 转发到后端生产环境则需要后端接口本身就带 /api 前缀或者再把请求路径处理一下。这是前后端分离项目最容易对不上的地方。Authorization 携带 token 是一种主流方式后端用拦截器或 Spring Security 验证这个 header。响应拦截器里统一判断 code 字段遇到 401 就清掉本地 token 并跳回登录页。这个设计保证后端接口返回未登录状态时前端不会停留在半死不活的白屏页面上。5. 急诊系统最常见的 5 个坑从启动失败到数据错乱5.1 MySQL 8 连不上SSL 握手失败与 allowPublicKeyRetrieval现象后端启动控制台报 Communications link failure或者提示 Public Key Retrieval is not allowed有些版本直接抛 SSLConnectionError。原因MySQL 8 默认使用 caching_sha2_password 认证插件客户端第一次连接时需要从服务端获取 RSA 公钥而 JDBC 驱动默认不允许这个行为同时 MySQL 8 默认开启了 SSL 连接本地开发环境经常没有配置证书两件事叠加就成了启动报错。解决在 JDBC 连接串上显式关闭 SSL 并允许公钥检索修改 application.yml 的 urljdbc:mysql://localhost:3306/hospital_emergency?useSSLfalseallowPublicKeyRetrievaltruecharacterEncodingutf8serverTimezoneAsia/Shanghai其中 allowPublicKeyRetrievaltrue 适用于内网开发环境生产环境安全性要求高时可以改用服务器上的 CA 证书或者确认网络加密方式后再关掉。这个参数属于“开发环境后悔药”别随意搬到公网环境。5.2 SpringBoot 版本太高javax 被替换成 jakarta 后的连锁报错现象项目在别人电脑上好好的自己本地从 SpringBoot 官网模板新建工程然后把源码的代码复制进来启动直接报符号找不到 javax.servlet.Filter或者大量红色 import 报错。原因SpringBoot 3.x 把 Java EE 的包命名从 javax.* 迁移到了 jakarta.*Servlet API、持久化 API 都换了根包名。网上很多旧教程和旧代码还是 javax 开头版本一对不上就翻车。解决不升级。打开 pom.xml看 spring-boot-starter-parent 里的版本号如果是 2.x本地 JDK 用 1.8并把 IDE 里项目的 Language Level 调成 8。如果确实要用 SpringBoot 3.x把项目里所有 javax.servlet、javax.persistence 之类的 import 全改成 jakarta.servlet、jakarta.persistence同时检查 druid 等中间件版本是否支持 SpringBoot 3。没有金刚钻别揽这个瓷器活。5.3 Vue 路由白屏打包进 static 后刷新就 404 的原因现象前端开发模式一切正常npm run build 之后把 dist 目录扔进 SpringBoot 的 static 目录后端启动浏览器打开首页是空白的或者直接报 404。原因vue-router 默认使用 history 模式路由路径会变成真实的 URL 路径比如 /workbench。SpringBoot 对静态资源的处理是“按文件查找”它找不到 /workbench 这个物理文件就回落到 404而不是自动返回 index.html。开发模式下刷新没事是因为 devServer 做了 historyApiFallback生产环境没有这层处理。解决最省事的方式是把 vue-router 切回 hash 模式URL 变成 /#/workbench所有内容都在 index.html 内部解析不经过后端的路径匹配。改一行const router new VueRouter({ mode: hash, routes })如果非要保留 history 模式需要在后端加一个转发配置让所有非静态资源路径都进 index.html。这里给出一种常规写法Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController(/{path:[^\\.]*}).setViewName(forward:/index.html); } }这段配置的意思是所有不带文件扩展名的路径请求都直接转发到 index.html由前端路由接管。需要注意这个写法会影响后端接口路径吗不会因为 controller 的映射优先于 view controller 匹配。但如果你把前后端接口也放在同一域名下建议接口统一加 /api 前缀避免转发规则误伤接口。5.4 Navicat 导入 SQL 乱码字符集在连接层就被带偏了现象用 Navicat 打开 SQL 文件并执行建表成功但表注释、初始数据里的中文全是问号或者报错 Incorrect string value。原因Navicat 新建查询时连接的字符集默认可能不是 utf8mb4而 SQL 文件本身是 UTF-8 编码。执行时连接层把字节按照错误的字符集解释写入到表里就成了乱码。更隐蔽的是Windows 记事本另存为 UTF-8 时可能带 BOM 头BOM 会让第一条 SQL 语句报语法错误。解决不要双击运行 SQL 文件。先在 Navicat 里右键数据库连接选择“编辑连接”在高级设置里把编码改为 utf8mb4然后新建数据库时也明确选择字符集 utf8mb4最后手动打开 SQL 文件全选执行。如果 SQL 文件是 GBK 编码的先转成 UTF-8 无 BOM 再导入不要偷懒。命令行导入时一定要带 --default-character-setutf8这个参数在前面第 3 章也强调过它是乱码场景的第一道防线。5.5 数据源配置没生效多环境 profile 与配置优先级现象明明在 application.yml 里把端口改成了 8081启动日志却还是 8080或者数据库连接的库名和配置里不一样像是被“黑匣子”盖住了。原因SpringBoot 支持多环境 profile项目里可能同时存在 application-dev.yml、application-prod.yml其中 application-dev.yml 里的配置覆盖了主配置。IDEA 启动时也可能自动激活了 dev profile而你又没看启动日志里的这条提示“The following profiles are active: dev”。解决遇到配置不生效先看启动日志最前面几行有没有打印激活的 profile再检查 resources 目录下是否存在其他 application-*.yml 文件。如果是 IDEA 里多了一个 active profile 参数把启动配置里的 VM options 和 Environment variables 检查清楚。强制指定环境可以在启动时加参数java -jar hospital-emergency.jar --spring.profiles.activeprod另外要记住 SpringBoot 配置优先级外部命令行参数大于外部配置文件大于 jar 包内的配置文件。很多人改了 jar 包里的 yml 不生效是因为部署目录下多了一个 application.yml那个文件优先级更高。这个规则不复杂但确实能解释很多“改了没反应”的诡异现象。6. 一个让部署更顺的技巧把 Vue 构建产物收进 SpringBoot 做单端口发布6.1 dist 目录的复制与静态资源映射很多项目开发时跑两个端口部署时又加一台 Nginx 做转发成本不高但维护面变大。对于医院急诊系统这种并发不高、要快速交付的场景我更推荐单端口方案Vue 打包成静态文件扔进 SpringBoot 的 src/main/resources/static后端打包成一个 jar。这样运维只需要关心一个进程、一个端口。正式操作分三步。第一步前端执行 npm run build生成 dist 目录里面是 index.html 和一堆带哈希的 js、css 文件。第二步把 dist 目录里的所有内容复制到后端项目 src/main/resources/static 下。第三步重新打包后端并启动mvn clean package -DskipTests java -jar target/hospital-emergency-0.0.1-SNAPSHOT.jar启动后浏览器访问 http://IP:8080/ 就能看到登录页。这个方案的关键前提是前端路由必须使用 hash 模式原因在第 5.3 节已经说过history 模式在单 jar 部署下会频繁 404。复制后还要检查 index.html 里引用的 css 和 js 路径是不是相对路径如果打包时配置了绝对路径 /assets/访问时也会找不到。如果前端请求的是 /api 前缀后端接口也最好保持 /api 前缀这样静态资源和接口在同一域名下不冲突。我一般会在后端 application.yml 里增加一个全局前缀或者直接在 Controller 的 RequestMapping 上统一写 /api。这个细节决定了部署后前端请求会不会被静态资源转发规则误伤属于吃过亏才记得住的操作。6.2 同源部署后的验证顺序部署完成后不要直接点登录。按下面顺序过一遍能提前发现大多数隐藏问题步骤操作预期结果1浏览器强制刷新访问根路径能看到登录页控制台无 4042打开 Network 面板看登录接口请求路径是 /api/login返回 JSON3登录后刷新页面停留在当前页面不跳回登录页4操作一次分诊流转数据库状态字段按预期变化5打开一个新的无痕窗口未登录访问被拦截跳转登录页第 3 步最容易暴露路由问题登录后正常跳转一刷新就白屏或 404这几乎可以断定是 history 路由模式没有切换属于第 5.3 节的坑位。第 5 步验证的是后端拦截器对未登录请求的处理很多项目登录页能出但 token 失效后不会跳转卡在一个报错页面上。做这类项目我的一个习惯是拿到源码后先不急着改业务先用最小配置把前后端跑通再对核心表画一张状态流转图然后才动手改代码。状态流转图可以帮助你在改接口时看清边界避免把后端的规则写死在前端页面上。希望这个思路能帮你在接手这套医院急诊系统时少走一些我当年走过的弯路。本文还有配套的精品资源点击获取