医院急诊系统这种项目在医疗信息化里算是最能检验开发团队功底的活儿。患者流量毫无规律极端情况下系统要同时扛住几十个急诊患者的挂号、分诊、开单、收药请求还要保证医生、护士、收费、检验、药房多个角色看到的数据实时一致。用Spring Boot Vue这套前后端分离技术栈来做可以说既是常规选择也是当前最稳妥的搭配。Spring Boot负责把后端的接口、事务、权限、并发这些底桩打得结结实实Vue则让前端看板、工作台、详情页的交互能跟上急诊场景那种快进快出的节奏。这篇文章我会从业务设计、后端落地、前端实现、部署加固到问题排查完整拆一遍这个系统的设计思路和实操过程。适合正在做医疗类系统、或者打算用Spring Boot Vue做中型管理系统的开发同学参考里面有不少代码之外的踩坑经验这些才是项目能稳定上线的关键。1. 先弄清急诊系统的业务底色1.1 急诊和门诊到底差在哪很多人第一次接触急诊系统会习惯性拿门诊那套逻辑去套这是最大的误区。急诊的核心流程是预检分诊—抢救/留观—处置—离院或收入院而不是门诊那种挂号—排队—看诊—取药。也就是说系统的第一入口不一定是挂号收费而是预检分诊台。患者到院护士先在分诊台快速评估病情在系统里录入主诉、生命体征血压、心率、血氧等、意识状态系统给出分级建议通常分Ⅰ级濒危、Ⅱ级危重、Ⅲ级急症、Ⅳ级非急症然后才决定是走绿色通道直接进抢救室还是正常排队就诊。这个顺序直接决定了表结构的设计。如果按照门诊系统的思路先建挂号单、再建就诊记录那个分诊环节就会变得无处安放后面做数据统计时也会发现候诊时长抢救室滞留时长这类急诊核心指标根本没有数据来源。所以设计急诊系统第一张核心表一定是预检分诊记录而不是挂号单。1.2 核心角色与功能模块映射做这类系统我习惯先把角色和功能画成一个矩阵再反过来推接口和页面。因为急诊涉及的终端特别多分诊台护士用PC端录入分诊信息抢救室医生用工作台开医嘱、查看检验结果输液区护士用平板确认执行收费处可能要快速补录费用大屏看板要实时滚动显示叫号信息甚至还有移动端供医生在科室之间查看危急值。每个角色看到的界面不同但底层数据是同一套。角色核心功能模块关键技术点预检分诊护士分诊登记、复评、候诊队列管理分诊级别算法、队列实时刷新急诊医生看诊、电子病历、医嘱开立、检验检查申请病历模板、医嘱嵌套、危急值提醒抢救室护士抢救记录、用药执行、体征采集高频数据录入、执行闭环收费/挂号人员挂号和补录费用绿色通道先诊疗后付费流程药房/检验科接收急诊医嘱、发药、回传结果队列优先、消息异步通知系统管理员字典配置、权限分配、大屏维护动态路由、按钮级权限每个角色的页面跳转路径也不同。比如分诊护士操作完一单下一个动作可能是叫号而不是回到列表页医生看完一个危重患者希望系统自动弹出他的留观床位信息和未完成的医嘱而不是手动搜索。这些交互细节在需求阶段如果不理清楚开发中就会反复改。1.3 表结构设计的两条核心原则急诊系统的数据量不像门诊那样每天稳定增长它的特点是突发高峰和数据实时性要求极高并存。设计表结构时我坚持两条原则第一患者主索引与就诊记录分离急诊患者可能无卡就诊、多次来院每次来急诊都生成独立的急诊就诊ID但通过患者ID关联起来这样既方便统计复诊率又不至于把一次抢救的数据五花大绑地塞进主档案里。第二状态字段必须冗余且可追溯比如一张留观床位的状态空闲、占用、预占、消毒中如果只靠当前是否有患者去反推遇到并发占用和转床操作就会乱套所以单独建床位状态表每次变更落一条变更记录。这两条原则在后面写代码时会节省大量时间。很多开发拿着需求就开建表做到一半才发现分诊环节没有归属、留观床位并发记录丢失再回头重构表结构那成本就大了。2. 后端Spring Boot骨架与关键模块落地2.1 项目初始化和依赖选型急诊系统后端我用的是Spring Boot 2.7.xJava 8。选2.7而不是3.x主要是考虑到医疗项目里经常要对接一些老旧的HIS接口兼容性和第三方依赖稳定性优先。用IDEA新建Spring Boot项目时核心依赖清单如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency这里有个细节MyBatis-Plus版本如果用的是3.5.x要注意它的分页插件配置方式和老版本不一样不再只是new一个PaginationInterceptor要换成MybatisPlusInterceptor并且按顺序注册多个拦截器。急诊系统的查询列表非常多候诊队列、留观列表、医嘱历史、收费明细官方插件能少写很多分页样板代码但在配置上踩坑的概率也高后面我会专门讲。启动类上记得加MapperScan注解扫Mapper接口不然启动时会报找不到bean的错误。另外建议在application.yml里配置spring.jackson.time-zone: GMT8这个能解决后端返回Date类型给前端时差8小时的问题急诊场景里时间错乱会引发医疗纠纷这个坑我见过不止一次。2.2 JWT认证与角色权限控制急诊系统是跨终端访问前端有PC工作台、大屏、平板、甚至微信公众号内嵌页。如果沿用传统的Session方案跨域和会话保持会很麻烦用JWT则天然适合这种多端场景后端无状态前端拿到Token后放到请求头Authorization: Bearer xxx即可。我的实现思路是自定义两个拦截器一个是AuthInterceptor负责校验Token合法性和有效期一个是PermissionInterceptor在Auth通过后根据当前用户角色校验接口权限。拦截器注册时要注意顺序先校验身份再校验权限。Token里我只放了userId、userName、roleCode和expire时间这几个字段不塞多余数据避免JWT体积膨胀。权限控制的粒度上急诊系统要比普通后台系统细。比如作废医嘱这个操作只有高年资医生或者科室主任有权限普通医生只能停嘱不能作废。所以接口级权限校验需要支持按钮级操作我的做法是在PermissionInterceptor里读取该用户所有权限码然后校验当前接口对应的权限码是否匹配。2.3 分诊评级规则与候诊队列处理预检分诊是整个系统里最有急诊特色的模块。护士录入患者的生命体征和主诉后系统要能根据规则给出分诊级别建议。我采用了比较务实的方案规则引擎和可配置参数结合。基础规则用代码判断比如体温大于39度且收缩压低于90mmHg直接给到Ⅱ级或以上界面上同时允许护士依据经验手动调整但调整必须填写理由并留痕方便后续质控。候诊队列是实时性要求最高的部分。急诊分诊后患者进入候诊队列大屏上显示当前叫号。因为多个护士、多个医生同时操作候诊队列的查询接口我并没有每次都去数据库countlist而是维护了一张triage_queue表状态字段只有待诊、叫号、就诊中、已完成、已过号五种每次状态变更都通过乐观锁version字段去更新避免重复叫号。查询时只查状态在待诊和叫号中的记录加索引后性能足够。2.4 绿色通道与先诊疗后付费流程急诊系统务必要支持先抢救后补费。患者送到抢救室时可能意识不清、身份不明这时候如果还走正常挂号缴费流程那是要出事的。我在设计里增加了绿色通道标记分诊台可一键创建临时就诊记录患者基础信息只填姓名甚至姓名都可以用无名氏时间戳临时替代然后系统给患者生成一个临时就诊ID所有医嘱、检验、用药都挂在这个ID下等到患者情况稳定后再去收费处补录身份信息和费用。这个问题如果不做上线后一定会被急诊科医生骂。因为现实中经常出现这样的情况抢救完成后患者家属去补费时发现系统里没有这笔就诊记录导致费用无法关联、药品追溯断裂。开发时一定要把绿色通道作为独立的状态机来设计不能简单地在挂号表上加一个是否加急字段糊弄过去。2.5 全局异常处理与统一返回结构急诊系统接口非常多如果不统一返回结构和异常处理前端联调时会被各种奇奇怪怪的报错搞崩溃。我习惯定义一个ResultT类包含code、message、data三个字段所有Controller都返回这个范型。然后加一个RestControllerAdvice的全局异常处理类集中处理业务异常、参数校验异常、权限异常和兜底的系统异常。这里强调一个经验参数校验不要只在Controller里手写if判断直接用Validated加NotNull、Size这类注解代码会干净很多消息提示也能统一。对于自定义业务异常我会定义一个BusinessException在service层抛出时带上错误码和给前端看的提示信息。这样前端拦截Axios响应时只需要判断code字段就能统一弹出错误提示而不是每个接口写一套错误解析。2.6 医嘱、用药与库存扣减的核心逻辑急诊医嘱有个特点开立快、执行快、类型杂长期医嘱、临时医嘱、抢救医嘱而且经常出现医生口头嘱托护士先执行事后医生补录的情况。所以医嘱表设计时我把状态拆成草稿、已开立、已审核、执行中、已执行、已作废这几个环节并且允许护士端在医生账号授权下代录但必须记录实际操作人。药品库存扣减这里要特别谨慎。急诊药房发药是高频操作一个抢救患者可能同时用多种药品如果每次发药都同步扣库存在高并发下很容易出现超卖。我的做法是发药时只锁定库存不立即扣减等到患者离院或留观结束时统一结算。锁定库存用UPDATE语句配合条件判断例如UPDATE drug_stock SET locked_count locked_count #{num} WHERE drug_id #{id} AND available_count #{num}利用数据库行锁天然保证并发安全。3. 前端Vue页面体系与交互细节3.1 环境准备与项目初始化前端技术栈我选择了Vue 3 Vite Element Plus Pinia Vue Router 4。Vue 3的组合式API在像急诊工作台这种需要大量状态共享的场景里写起来比Vue 2的选项式舒服很多。初始化项目时建议用npm create vitelatest emergency-front模板选Vue然后手动安装依赖npm install vue-router4 pinia element-plus axios sass dayjs这里有一个很多人会忽略的坑Element Plus的图标需要单独安装element-plus/icons-vue包而且要用到哪个图标就按需注册不要全局全量注册否则首屏加载体积会多出几百KB。急诊大屏和医生工作台都是内网访问但加载速度同样影响使用体验尤其是抢救室那种争分夺秒的地方一个按钮转圈转3秒护士可能就直接骂人了。Vue项目建好后我第一步就配好路径别名和跨域代理。Vite的vite.config.js里配置resolve.alias把指向src目录再配置server.proxy把/api前缀代理到后端地址。本地开发时通过代理访问后端可以完全规避开发环境的跨域问题生产环境则让Nginx处理转发。3.2 动态路由与权限守卫急诊系统的页面权限必须做到路由级别。最直接的原因是分诊护士和抢救医生看到的功能菜单完全不同如果前端把全部路由都注册进去虽然接口层面有权限拦截但用户通过URL直接跳转还是能打开无权限的页面体验和安全都不过关。我的做法是登录接口返回用户信息和权限码列表前端用Pinia存储然后在路由守卫router.beforeEach里动态生成该用户可访问的路由表用router.addRoute逐个注册。Vue Router 4里动态路由有个细节删除路由不能用简单的removeRoute遍历路由名称会残留建议在addRoute前先通过router.hasRoute判断或者服务端登录返回新路由表时统一重置。路由守卫的另一个职责是处理Token过期。我设置了响应拦截器当后端返回401时自动触发登出逻辑、清空用户状态并跳转登录页。这里推荐配置axios.interceptors.response统一处理而不是在每个页面里写判断。不然急诊系统几十个页面每个都判断一遍代码维护成本会高得吓人。3.3 核心页面拆解分诊台与医生工作台分诊台页面的核心是快。我把表单拆成了几个区块基础信息区、生命体征区、分诊级别区、备注区。默认只展示基础信息和生命体征分诊级别由系统根据体征自动计算并高亮显示护士录入完主诉后直接回车就能提交不需要用鼠标点来点去。分诊队列则用定时器每5秒刷新一次刷新时只请求当前状态下待诊、叫号中的记录用户无感知。医生工作台的重点是信息聚合。一个急诊医生同时看三四个患者很正常所以页面左侧是当前候诊/诊中患者列表中间是选中患者的病历和医嘱右侧是检验检查结果和留观状态。这种布局其实就是把一个急诊医生办公桌面的所有信息都搬到了系统里。信息聚合的核心是异步加载患者列表先渲染其余区块按需请求避免进入页面时一次性请求全部数据导致白屏。这里我用到了WebSocket做实时推送比如检验科把危急值结果发回来时医生工作台要弹窗提醒。WebSocket的连接要处理好重连机制因为内网环境的网络抖动比公网还频繁一旦连接断了没有重连危急值提醒就看不见了这是医疗事故级别的隐患。我封装了一个connectSocket方法监听onclose事件后延迟3秒自动重连并加上心跳包保活。3.4 Axios封装与请求竞态处理Axios封装这块除了常规的baseURL、超时时间、Token注入和响应拦截急诊系统还要额外注意请求竞态。比如分诊台的队列刷新接口是定时请求医生工作台的检验结果也是异步返回如果上一次请求还没返回用户又触发了一次新请求界面可能显示的是旧数据。我的处理方式是在Axios请求配置里加一个cancelToken切换患者或清空条件时取消上一个未完成的请求避免旧响应覆盖新数据。文件上传的场景也要提一下急诊系统要上传身份证照片、伤口照片等。后端有全局过滤器时如果处理不当上传PDF时可能会被XSS过滤规则误伤比如PDF二进制流里的某些字节被当成非法字符过滤掉。我建议上传接口单独放行不经过XSS过滤拦截器或者过滤器的实现只处理文本参数不处理二进制流。这个坑我是在联调时踩到的排了一下午才发现是过滤器在捣乱。3.5 大屏看板与叫号系统急诊大屏是弱交互、强视觉的页面主要给候诊区和走廊上的人看展示当前的叫号信息、医生出诊信息、候诊人数。技术方案上用vue-router的独立路由不需要任何权限校验但要注意大屏页面长时间运行的内存泄漏轮询定时器实例要在onBeforeUnmount里清理页面用keep-alive包裹时更要小心。叫号系统的状态同步是最典型的前后端交互场景。护士在分诊台点叫号按钮前端发请求改状态后端通过WebSocket广播叫号消息大屏页面收到消息后播放声音并高亮显示。这里要注意广播消息只推送给订阅了对应诊区队列的客户端。如果嫌WebSocket配置麻烦也可以用短期轮询作为保底方案但延迟会明显一点在急诊这种场景能上WebSocket就上WebSocket。4. 联调、部署与生产环境加固4.1 前后端联调的三个关键配置联调阶段我通常会做三件事第一后端开启Swagger或者用knife4j生成接口文档前端根据文档调试避免两边对着源码猜字段含义急诊系统几十张表、几百个字段没文档联调就是灾难。第二统一时间格式约定后端所有接口的日期时间字段都返回yyyy-MM-dd HH:mm:ss字符串前端不做二次格式化直接展示。第三明确分页参数格式页码、页大小从1开始还是从0开始一定要定死并写进文档不然分页列表会对不齐。还有一个联调小技巧是Spring Boot的devtools热重启。这个插件很容易被忽略但对联调效率的提升非常大。改完后端代码按CtrlF9自动重启比每次手动重启节省很多时间。虽然它确实支持但注意devtools不适合在生产环境启用所以依赖里要用scoperuntime/scope限制作用范围。4.2 Docker部署与Nginx反向代理生产环境我推荐用Docker部署。后端镜像基于openjdk:8-jre-alpine通过Dockerfile把spring-boot-maven-plugin打出来的jar包扔进去前端用nginx:alpine镜像构建时先执行npm run build把dist目录复制到镜像的/usr/share/nginx/html下。前端部署有个非常关键的Nginx配置VueRouter如果用了history模式刷新页面时Nginx会按URL去找对应的静态文件结果就是404。必须加一个try_files $uri $uri/ /index.html;规则把所有非静态资源的请求都回退到index.html由VueRouter接管路由。后端接口的转发配置要处理/api前缀。Nginx里把/api/的请求proxy_pass到后端服务容器同时配置proxy_set_header传递真实IP便于后端做操作日志审计。后端服务容器内部不需要暴露端口给宿主机只用Docker内部网络互通只有Nginx映射到宿主机80端口这样攻击面会小很多。4.3 数据安全与隐私保护医疗系统的数据安全怎么强调都不过分。急诊系统涉及患者主诉、诊断记录、用药信息这些都属于敏感个人信息。在开发层面要做的至少有三点第一登录密码必须用BCrypt加密存储不能用MD5第二所有接口的返回数据在序列化时排除敏感字段比如身份证号不能直接完整返回前端显示需要加掩码第三关键操作作废医嘱、修改分诊级别、补录费用必须记录操作日志包括操作人、操作时间、操作内容和原始值。上传的身份证照片等文件建议单独挂载存储目录Nginx配置访问控制不能允许匿名访问。如果条件允许直接把文件放在对象存储里数据库只存访问路径避免文件直接落在业务服务器上。4.4 性能优化与并发压测急诊系统的并发峰值通常出现在流感高发季或者交通事故等突发事件后此时短时间内会涌入大量患者。我在上线前做了一次简单的JMeter压测核心场景是同时100个分诊请求提交50个医嘱开立80个候诊队列刷新。压测暴露的问题主要有三个第一个是数据库连接池太小。Spring Boot默认的HikariCP连接池设为10压测时很快就打满了后来调整到maximum-pool-size: 50并且给连接空闲超时配了合理的值。第二个是分页查询慢。候诊队列的count(*)扫描在数据量大了后会变慢我给状态字段和就诊时间字段建了联合索引查询性能明显提升。第三个是医嘱开立接口里事务粒度过大导致药品库存表行锁等待时间增长后来把库存锁定操作单独拆成一个小事务其他逻辑不要包在同一个事务里。5. 排查实录与踩坑清单5.1 高频问题速查表做这个项目过程中我前前后后记录了不少问题有些是技术层面的有些是业务层面的。下面挑几个最容易复现的列成表方便大家直接用。现象原因解决方案后端日期返回给前端差8小时Jackson序列化时区未设置为GMT8application.yml配置spring.jackson.time-zone: GMT8前端刷新页面404Vue Router history模式缺少Nginx回退规则Nginx加try_files $uri $uri/ /index.html;MyBatis-Plus分页不生效没有正确配置分页拦截器使用MybatisPlusInterceptor并添加PaginationInnerInterceptor上传PDF被拦截或文件损坏全局XSS过滤器处理了二进制流上传接口单独放行或过滤器跳过二进制请求体分诊叫号出现重复并发更新队列状态乐观锁version字段更新时带上版本条件医生工作台WebSocket断线漏消息没有配置重连机制和心跳封装onclose重连定时发送心跳包药品库存超卖先查库存再更新并发下出现错误数据使用UPDATE ... WHERE available num原子扣减大屏长时间运行卡顿轮询定时器未清理组件卸载时clearInterval轮询回调里做存活判断5.2 反编译排查线上问题的经验还有一个比较实用的经验生产环境如果只保留了Spring Boot的jar包而项目源码没及时归档排查问题时可以先解压jar包看BOOT-INF/classes下的application.yml确认配置对不对。如果连配置文件都看不到可以借助反编译工具把class文件还原看逻辑虽然效率不高但关键时候能救命。我建议项目组在一开始就养成好习惯每一次发布前都把对应的源码tag和jar包一起归档这种成本极低但遇到需要快速定位线上问题时省下的时间是不可估量的。5.3 关于Vue调试与依赖安装的提醒前端调试时一定要装Vue DevTools插件。Vue 3项目对应的插件可以从应用商店直接安装装完后调试组件状态、路由跳转、Pinia数据变化会直观很多不用靠console.log猜来猜去。依赖安装时如果npm install很慢建议配上国内的npm镜像源临时切换命令是npm install --registryhttps://registry.npmmirror.com。另外提一句有些内网环境装不了外网依赖那就要提前做好依赖包的离线备份方案。6. 写在最后把Spring Boot Vue这套组合用在医院急诊系统上技术上没有太多花哨的东西真正的难点都在业务理解和边界情况处理上。比如分诊评级怎么给规则绿色通道怎么保证先抢救后补费库存怎么在并发下不超卖WebSocket断了怎么补消息这些才是决定一个系统能不能从能用变成好用的关键。我做完这个项目后最大的体会是医疗信息系统最忌讳开发自嗨。代码结构再漂亮、技术栈再新如果护士在分诊台录一个患者要等3秒医生看检验结果要点四下鼠标那这个系统在科室里就会被抵制使用。所以做这类系统一定要多去现场蹲一蹲看看他们真实的操作习惯把快和稳放在第一位而不是把精力全花在追逐框架新特性上。最后再分享一个小技巧急诊系统的所有接口设计阶段都要给自己留一个降级的余地。比如WebSocket实时推送挂了前端要能从轮询接口拿到同等级的数据大屏看板抽风了护士在分诊台还能通过传统列表页面查看队列。医疗场景里系统挂了还能干活比系统功能多重要得多。这套思路一直在帮我避坑做别的管理系统也同样适用。
