刚拿到“基于VUE的唐山市友谊里社区医院住院管理系统”这个毕业设计题目时我第一反应不是打开开发工具而是先把一家社区医院住院部每天会发生的事拆开看了一遍。这类项目最容易踩的坑是把前端页面做得花团锦簇业务数据却经不起追问。一个住院管理系统真正值钱的地方是它能把一张病床、一位病人、一组医嘱、一串费用之间的状态变化固定下来。这篇文章我会按照从需求梳理、Vue前端工程搭建、后端接口配合到最终整理源码和LW文档的完整节奏把每一步的思路和坑都讲清楚。项目源码和目录结构可以直接当模板参考但业务表结构建议你按自己熟悉的医院流程再过一遍。1. 为什么社区医院住院管理要选Vue——需求与选型1.1 从流程痛点反推前端框架社区医院的住院管理和三级综合医院的大型HIS系统是两码事。HIS系统讲究全院级的数据协同、医保结算、药房联动而社区医院住院部的痛点更具体患者数量不算巨大但入院登记、床位分配、医嘱执行、费用记录这些事过去大量依赖纸质台账和护士交接班的口头说明。拿最典型的“床位状态”来说传统方式靠一块白板护士在上面写床号、患者名和护理等级。换床、转科、出院都得手动擦改稍不留神就会出现“床位上写着有人实际上已经空出来”或者“患者已经出院费用单还在继续累加”的情况。我当时给自己定的需求边界很简单住院全流程信息化、床位状态实时可查、医嘱和费用记录可追溯、操作权限按角色区分。这个边界确定后前端用什么框架其实已经没那么多悬念了——要快速开发、要交互频繁、要能适应小团队维护Vue几乎是最顺手的选项。1.2 Vue作为前端方案的底层逻辑选Vue不是因为它流行而是因为住院管理系统这类典型的管理信息系统MIS对前端的需求非常固定大量表单、表格、状态切换、弹窗确认、权限菜单控制。Vue最匹配的点有三个。第一响应式数据绑定。填写入院登记表单时根据“入院科室”联动显示“可入床位”再根据“护理等级”默认带出“预交金建议金额”这是传统DOM操作写起来特别繁琐、但Vue的双向绑定天然擅长的事。第二组件化复用。床位一览、医嘱列表、费用明细在几个不同页面里都要出现抽象成独立组件后一份代码多处引用后期修改统一改一处就行。这对开发时间有限的毕业设计来说太关键了。第三生态成熟度。社区医院管理系统涉及路由跳转、状态共享、HTTP请求、UI表格Vue全家桶和Element Plus这一类组件库已经把这些场景覆盖得很完整不需要从零造轮子。关于Vue版本我给个直接建议如果导师给了旧的Vue 2项目模板沿用也没问题但如果是自己从零开始直接上Vue 3加组合式API再加Vite作为构建工具。Vue 2如今已经进入维护尾声新项目没有必要再迁就旧语法。组合式API对组件内逻辑复用帮助很大比如“床位状态轮询刷新”这段逻辑可以单独抽成useBedStatus函数在床位页和护士工作台共用这在选项式API里写起来会别扭很多。1.3 一个“源码文档”项目到底交付什么标题里“源码LW文档”并不是一个口号它代表毕业设计的两个交付物可运行的前后端工程以及说明设计过程的配套文档。很多人把源码写完才开始写文档结果文档变成了对代码的机械复述。我的做法是反过来先把文档目录规划好再按文档目录去推进开发。文档里需求分析和数据库设计章节直接决定了代码里业务逻辑怎么组织。前者不清晰后者写出来也必然是糊涂的。源码部分是核心包括Vue前端工程、后端接口工程和数据库初始化脚本。LW文档部分则配合着说明选题背景、可行性分析、需求分析、系统设计、数据库设计、接口设计和测试报告。后续我会在第6部分详细展开交付结构和答辩经验。2. 先把业务梳理清楚住院系统的模块地图与数据流2.1 从入院到出院的一次完整路径开发之前我把业务闭环画了一遍门诊医生开具住院建议住院部护士办理入院登记为患者安排床位责任医生录入医嘱护士按医嘱执行并记录费用系统按医嘱和药品项目自动累计费用患者预交金不足时提醒补缴出院时护士站进行费用结算并释放床位。这条路径看起来顺理成章但每个环节都藏着业务细节。办理入院登记时患者是初次住院还是二次复诊信息存在差别。床位分配时是护士手动选床还是系统按科室自动分配空床换床时是直接修改床号还是保留一条“转床记录”医嘱执行时长期医嘱和临时医嘱分别怎么对待出院结算前已经执行但未计费的医嘱要不要锁住这些不是技术问题而是业务规则。在“基于VUE”这个前置条件下业务规则才是你区别于另一个只会搭页面的人的关键。前端只是呈现层业务规则不清前端和后端都会反复返工。我自己整理下来的核心模块是六大块入院登记管理患者基本信息、联系人、入院科室、初步诊断、护理等级、预交金录入。床位管理床位总览、分配床位、转床、释放床位对应床位状态变化。医嘱管理长期医嘱、临时医嘱医嘱内容、开立医生、执行护士、执行时间、停止标记。费用管理每日费用记录、药品费用、检查费用、床位费用、预交金抵扣、催缴提醒。出院结算管理费用汇总、发票打印、多退少补、出院登记。系统管理用户登录、角色权限、科室信息、基础数据维护。2.2 角色视角决定功能边界住院系统的使用者不是一个人而是医生、护士、住院收费员、系统管理员四种角色。我在做需求分析时没有直接画用例图而是先切换到每个角色的日常操作场景里。护士最关心的是今日待办哪个患者今天要做几项治疗哪些临时医嘱还没执行哪张床今天要入出院。所以她进入系统后默认应该看到护士工作台而不是一张静态的统计图表。医生更关心患者的病程当前诊断、最近一次医嘱记录、检查结果、费用进展。所以医生端应以患者维度展示住院详情而不是以流水账方式展示操作记录。收费员关心的是费用准确预交金余额多少哪些费用未结算退费申请是否被审核过。收费端最重要的是数字精确和流水可追溯。管理员则负责基础配置和账号布置权限菜单可以全部开放但更常用的是日志和字典维护。做权限菜单时我并没有把路由写死而是采用后端返回菜单树、前端动态生成路由的方式。这部分技术细节在第3部分展开但它背后的业务驱动正是“不同角色打开系统看到的菜单不一样”。2.3 几个必须先想清楚的状态机这类系统最怕的就是状态随意变前端改了状态后端不知道后端改了数据前端缓存没有同步。开发前我把关键状态机固定下来数据库字段也会按这套逻辑设计。床位状态空闲 → 已分配 → 住院中 →转床后新旧床位状态联动→ 消毒整理 → 空闲。出院或者转科时释放床位后要进入“待整理”状态而不是直接回到“空闲”。否则下一名患者刚入院就被分配进一张还没清扫的床一投诉一个准。医嘱状态待执行 → 已执行 → 已停止临时医嘱只用一次执行后立即变成“已完成”长期医嘱可以被医生开立“停止”停止后当前时间之后不再自动产生费用。费用流水状态待确认 → 已计费 → 已退费预交金状态正常 → 欠费 → 已补交。这几个状态机的值前端用常量枚举统一存放后端用数字或英文编码表示绝不在页面里裸写“inHospital”“outHospital”这种随机值。后面做接口联调时这个统一枚举帮了大忙。3. Vue前端工程结构我实际用到的设计与实现3.1 目录结构照这个搭基本不会乱前端工程我采用的目录结构如下完全按功能模块切分而不是按“页面”切分frontend/ ├── public/ ├── src/ │ ├── api/ # 后端接口模块 │ │ ├── request.js # Axios封装 │ │ ├── patient.js # 患者相关接口 │ │ ├── bed.js # 床位相关接口 │ │ ├── order.js # 医嘱相关接口 │ │ ├── cost.js # 费用相关接口 │ │ └── settlement.js # 结算相关接口 │ ├── router/ │ │ ├── index.js # 路由实例 │ │ └── staticRoutes.js # 无需权限的静态路由 │ ├── store/ # Pinia状态仓库 │ │ ├── index.js │ │ ├── user.js # 登录用户信息与权限菜单 │ │ └── bed.js # 床位全局状态 │ ├── views/ │ │ ├── admission/ # 入院登记 │ │ ├── ward/ # 床位与护士工作台 │ │ ├── doctor/ # 医嘱模块 │ │ ├── finance/ # 费用与结算 │ │ └── system/ # 系统管理 │ ├── components/ │ │ ├── HospitalTable/ # 通用表格组件 │ │ ├── HospitalForm/ # 通用表单组件 │ │ ├── BedPlan.vue # 床位图组件 │ │ └── StatusTag.vue # 状态标签 │ ├── directives/ │ │ └── permission.js # 按钮权限指令 │ ├── styles/ │ └── utils/ │ ├── format.js # 日期金额格式化 │ └── enum.js # 全局状态枚举 ├── .env.development ├── .env.production └── vite.config.jsapi目录单独拆出来是我最不后悔的决定。页面组件里不允许直接出现Axios调用只允许调用api/patient.js里暴露的getPatientList这类函数。后面前端页面越来越多时后端接口一旦调整路径或参数只需要改一个api/patient.js不用满项目找axios.post。3.2 动态路由与侧边栏联动不是简单隐藏菜单动态路由几乎是Vue权限系统的必考题但很多人做成了“表面功夫”。因为后端已经返回了菜单树就简单地用v-if判断角色把某些菜单隐藏了。这种做法最大的问题在于路由仍然真实存在用户直接在浏览器输入/ward/bed路径一样能打开床位管理页面后端又没有做权限校验那权限控制就失效了。我的实现思路分三层。第一层登录成功后后端返回菜单树每一级菜单节点携带组件路径和路由名称。前端根据这个树结构动态注册路由未授权菜单根本不会被注册成可访问路由。这样直接输入URL找不到匹配路由会落到404页面。第二层侧边栏菜单遍历同一份menuTree生成保证菜单显示和路由注册用的是同一数据源。因为动态路由注册是异步过程需要用router.addRoute在登录后集中执行并把路由状态存进Pinia避免刷新页面后侧边栏闪一下白屏。第三层后端接口使用Spring Security或Shiro之类的框架做真正的鉴权。后端校验永远不能省略前端动态路由只是体验层面的手段后端接口鉴权才是真正的安全边界。这一点我会在第5部分继续强调。3.3 状态管理做“轻”一点医院住院系统的状态比购物车这类场景要复杂一些但也没复杂到必须把上百个状态全放到Pinia里。我原则上只把三类数据放进全局状态用户登录信息、权限菜单树、当前选中的患者上下文。患者上下文是一个容易被忽视的点。医生操作患者详情的多个子页面时如果每个子页面都重新请求一次“当前患者信息”不仅慢还会出现某个子页面拿到的患者ID和另一个子页面不一致的问题。在患者列表页点击某位患者后我把患者ID、姓名、科室、入院时间统一写入Pinia的currentPatient之后医嘱页、费用页、病历页都从这份数据读取患者ID。切换患者时再重新赋值。像床位实时状态这种数据我没有放进全局而是由床位组件自己轮询刷新。因为这段状态只服务于护士工作台放进全局反而会让其他页面因为不相关数据变化而触发不必要的重渲染。3.4 把表格和表单组件化省掉一半重复代码住院系统里出现频率最高的是表格而表格的流程高度相似进入页面请求列表、展示加载状态、支持查询条件、分页、行内操作、空数据提示。所以我封装了一个HospitalTable通用组件把重复逻辑都收进内部template hospital-table :columnscolumns :fetchfetchAdmissionList row-keyid template v-slot:status{ row } el-tag :typerow.status 住院中 ? success : info {{ row.status }} /el-tag /template /hospital-table /templatefetch属性是获取列表数据的函数组件内部统一处理loading、分页参数、错误提示。这样页面里不需要写el-table的loading逻辑更不需要在每个页面复制一份分页代码。使用插槽渲染特殊列比把所有配置全部塞进columns数组更灵活。状态列的标签、操作列的按钮都通过插槽放进去通用表格组件永远不会因为某个特殊列而被迫改代码。表单组件同理。入院登记、医嘱开立、费用登记这几个表单结构差别很大但表单布局、校验规则、提交状态这些行为是一致的。我把表单的校验方式和提交逻辑抽到HospitalForm里外部传rules和form数据对象。这样几个复杂的表单页面每个页面只需要维护自己的字段配置骨架代码几乎一样。4. 后端接口与数据库协作的关键约定4.1 接口返回格式先统一后面联调才不痛苦前后端联调最烦的事情是后端返回结构一天一个样一会儿{code: 200, data: []}一会儿{success: true, result: []}。开发开始前我必须先和后端约定一套固定返回结构{ code: 0, message: success, data: {} }其中code0表示成功非0表示出错前端Axios拦截器统一判断code出错时统一弹出消息条。前端项目里的api/request.js就是为处理这套约定而存在的。拦截器内部做三件事追加Token到请求头、统一处理HTTP错误和业务错误、在响应里统一剥离data字段。这样做的收益非常直接——页面组件里的API调用始终拿到的是业务数据本身不需要每个页面写一遍if (res.code ! 0) { ... }。4.2 核心表设计字段宁多勿少状态别拆太散住院管理系统最核心的表大概五张我用一个表概括表名用途关键字段说明patient患者基本信息id、name、id_card、phone、medical_record_no首次入院时创建复诊只更新关键信息admission住院记录id、patient_id、department_id、admission_time、discharge_time、status一次住院对应一条记录一个患者可有多条bed床位信息id、bed_no、ward_id、status、current_admission_idstatus包括空闲、占用、停用、待清洁bed_history床位使用历史id、admission_id、bed_id、start_time、end_time每发生一次分配、转床、释放都写一条doctor_order医嘱id、admission_id、order_type、content、status、create_doctor_id、execute_nurse_id长期医嘱与临时医嘱用order_type区分这里我要专门讲讲bed_history这张表。刚开始我的床位设计只在bed表里放一个status字段换床时直接把bed.status改掉旧床恢复空闲。这看起来没有问题但一旦要追溯“这位患者在5月3日到5月5日之间住的到底是几床”就完全查不到了。医疗场景特别需要“事件可追溯”所以床位状态不能只存当前状态必须保留每个患者与床位的绑定历史。换床不是改一条记录而是把旧床位的bed_history记录关闭写入end_time在新的床位上新增一条使用记录。这类设计思想在答辩时尤其加分。医嘱表同样不能只存当前是否有效。长期医嘱今天开立五天之后医生下了“停止”指令那这五天的医嘱都应当在记录里保留。停止时不是删除而是修改status和stop_time费用结算也能根据时间段精确汇总。4.3 先用Mock数据跑通前端再等后端接口实际开发中我和后端同事是并行的前端不能干等接口。为了让开发不互相阻塞我用Vite的vite.config.js内置代理配置解决跨域问题同时在前端工程里放了一套Mock数据把API模块里的函数临时指向本地静态数据。等后端接口就绪后只需要把API模块里的调用地址从Mock切换到真实后端URL页面代码因为都走api/xxx.js几乎不用改动。这个习惯至少帮我避开了两类麻烦一是前端写页面时不会因为没有接口而临时编造数据结构二是联调时后端接口字段名有不一致的地方能在API模块这个集中位置快速处理。实践中我也犯过一类错误Mock数据里字段用的admission_time后端接口返回用admissionTime字段风格不一致导致页面一直拿到undefined。所以建议在开发第一天就把字段命名的骆驼峰还是下划线风格定下来。我这里是后端返回驼峰格式前端不需要转换省去一把格式化代码。4.4 接口文档和自测不要拖到最后毕业设计答辩前一周临时联调接口是最痛苦的体验。我的习惯是后端每个接口完成后立刻在Swagger里把参数和返回示例写完前端拿到接口文档后先用Apifox这类工具做冒烟测试确认能返回预期结构再开始联调页面。接口文档不只是写给别人看的更是给自己对需求用的。写完一个接口的返回示例时往往会发现自己漏了某个业务字段比如结算时需要出院时间、预交金余额、退款金额三个字段而后端只设计好了出院时间。5. 六个最容易让项目翻车的实战坑5.1 床位并发分配一张床同时给两个患者这是住院系统最容易出事故的地方。护士工作台同时打开在多个终端两名护士几乎同时点中了同一张空闲床如果不加控制就会出现一张床被分配给两名患者。我的处理办法分两层后端在分配床位的SQL语句里加上条件更新UPDATE bed SET status占用, current_admission_id#{id} WHERE id#{bedId} AND status空闲如果更新行数为0说明床位已经被别人占用分配失败。前端收到失败提示后立刻刷新床位图把状态同步回来。前端也给了一个优化体验的操作护士点击床位后前端立即把这张床标记为“选中待分配”同时向后端发送一个短暂占用确认请求。这样其他人看到的就是已被选中的状态减少后端点解的冲突概率。5.2 费用金额的精度问题千万别用JavaScript小数住院费用计算里最经典的坑是0.1 0.2不等于0.3。医院费用直接涉及钱前端组件里如果用JavaScript的浮点数做费用累加某些组合下会算出一个无限小数让结算金额出现几分钱的差异这在医院场景里是没法接受的。我的固定做法是前端所有金额字段都使用字符串展示所有费用计算只发生在后端。后端使用Java的BigDecimal计算金额数据库金额字段使用DECIMAL(10, 2)类型。前端拿到金额后只做格式化展示。即使给患者展示“床位费单价×天数总金额”这个乘法也由后端接口返回前端不自己做算术。退一步说就算前端要做价格试算也必须先引入专门的高精度计算库而不是直接使用原生数字类型。医院一天产生几十条费用流水误差一多结算阶段就会出现“总费用和各明细费用加总后不相等”的尴尬局面。5.3 按钮权限菜单隐藏不等于权限控制前面提过动态路由只能控制页面访问按钮级别的权限还得单独处理。比如普通护士可以执行医嘱但不可以开立医嘱护士长可以退费但不可以修改收费标准。菜单权限管不到这种细粒度操作。我做了一个v-permission自定义指令在按钮标签上直接声明需要的权限el-button v-permissionnurse:order:create clickopenOrderDialog 新增临时医嘱 /el-button指令内部读取当前用户权限集合没有对应权限的按钮直接移除DOM。同时后端接口在PreAuthorize(hasAuthority(nurse:order:create))里再次校验前端过滤只是交互层面的保护。按钮权限和后端权限两套合并一起写进文档里答辩时被问“前端控制权限可不可靠”时就能给出完整答案。5.4 工程压缩包体积和路径问题毕业设计最终要提交源码压缩包很多人直接把node_modules文件夹一起压缩进去几万个依赖文件不仅压缩耗时发给老师解压时还因为路径过长报错。正确做法是删除node_modules只保留package.json和package-lock.json并写一个简单的README说明依赖安装命令。安装依赖时加--registry指向国内镜像下载速度会快很多。这个看似细小的点每年都能拦住不少人在最后交付阶段折腾半天。5.5 开发环境跨域和线上路径不一致前后端分离开发时跨域问题必须提前处理。我把vite.config.js里的代理配好前端请求/api时由Vite开发服务器代理转发到后端http://localhost:8080避免后端每天被浏览器跨域报错折腾。生产环境部署时则用Nginx把/api前缀转发到后端服务。部署时还要注意把前端构建产物放进Nginx的静态目录后入口路径要用相对路径还是绝对路径这会影响资源加载是否正常。我踩过的版本不是构建配置而是部署后刷新某个子页面出现404。这是因为动态路由在刷新时找不到对应的服务器路径需要在Nginx配置里把路由请求全部回退到index.html。5.6 演示数据一定要“演”得起来毕业设计演示时最大的翻车场景是现场临时录数据。输入患者身份证号时打错、下拉框里选不到对应科室、费用计算结果超出预算这些状况在演示环境里发生一次就很尴尬。我提前在数据库里准备了两种数据一套是数量充足、状态各异的静态演示数据覆盖入院中、住院中、待结算、已出院各种状态一套是专门为现场演示准备的“活数据”包括一个正在住院的患者有完整的医嘱、执行记录和费用明细。现场演示从“给这位患者开一条临时医嘱”开始再切换到医护人员视角看这条医嘱执行后费用如何变化整个流程顺畅且真实。6. 源码、LW文档和答辩让毕业设计看起来真的“做过”6.1 交付物结构怎么组织最清晰标题里提到的“源码LW文档”我的理解是把毕业后交付拆成源代码和设计文档两部分。源码部分要保证“拿到就能跑”文档部分要保证“看完就知道你的设计过程”。我的交付物结构是这样组织的hospital-inpatient-management/ ├──源码/ │ ├── frontend/ # Vue前端工程 │ ├── backend/ # Spring Boot后端工程 │ ├── database/ # SQL初始化脚本 │ └── README.md # 启动部署说明 ├──文档/ │ ├── 01-需求分析说明书.docx │ ├── 02-系统设计说明书.docx │ ├── 03-数据库设计说明书.docx │ ├── 04-接口设计说明.docx │ ├── 05-测试用例与结果.docx │ └── 06-部署手册.docx └── 演示/ └── 演示视频.mp4如果学校要求格式就把文档章节换成学校模板如果没有强制模板至少包括需求分析、系统设计、数据库设计三章。文档每一章都要对应源码里的实际模块。数据库设计文档里每张表都写明“这张表解决什么业务问题、核心字段含义、常见查询场景”比单纯贴建表SQL再丢一堆截图有用得多。6.2 答辩演示的脚本设计答辩时间通常只有五分钟到十五分钟我不建议按功能模块逐个念。我用的策略是讲一条完整的业务线住院患者从入院登记开始护士分配到床位医生录入医嘱护士执行费用自动累计最后出院结算。一条线走完所有模块都覆盖到了。具体脚本我会提前写下来并反复练习第一步登录系统。强调两个角色账号切换护士登录后看到护士工作台切换医生账号后发现菜单不同证明动态权限生效。第二步入院登记。选择一名演示患者录入基础信息保存后自动进入床位分配页面。第三步床位分配。床位图上能看到空闲床和占用床的颜色区分点选空床后状态变化。第四步医嘱开立。医生录入一条临时医嘱执行护士在待办列表里看到点击执行。切换回费用页面这条医嘱对应的金额已经计入当前住院费用。第五步出院结算。展示费用汇总、预交金抵扣、退款金额确认后床位释放回空闲状态。这套演示路径最大的好处是既能演示技术实现又让没有医疗背景的老师听懂业务逻辑。6.3 高频答辩问题提前准备有几个问题几乎必问提前在文档里准备好答案可以少很多紧张情绪。第一个为什么选Vue不选React这个问题的核心不是框架优劣而是你的选型和项目是否匹配。我从组件复用、动态路由、生态成熟、团队熟练度几个角度答再补充一句“项目数据量大页面状态切换频繁Vue的响应式机制能减少大量手动DOM操作”。第二个床位状态是怎么保证一致性的我会介绍数据库条件更新、状态机枚举、前端轮询刷新三个层面这一段能展示你对业务并发场景的思考。第三个你的系统有什么不足如果继续做你打算加什么这种问题考察的是自我认知。我会如实说目前没有接入医保结算接口没有药品库存联动没有更多统计分析图表。下一步可以增加按科室维度的床位周转率统计、出院患者随访提醒甚至用移动端消息推送给护士发送待执行医嘱提醒。6.4 时间分配与最后的个人建议如果从头独立开发一个完整的社区医院住院管理系统按每天投入四到六小时计算我的时间分配建议是需求梳理三天数据库设计两天后端接口一周前端页面两周前后端联调三天文档整理三天答辩准备两天。前端页面占的时间最多因为表格式页面看起来简单实际做下来各种表单校验、空状态、加载状态都会消耗时间。后端接口如果按照前面说的统一返回结构写速度反而比前端稳。这个项目里我个人最想提醒你的一点是不要把“会写Vue页面”当作“会做管理系统”的全部。Vue解决的是交互层的问题业务完整性才是你能和面试官或答辩老师深入对话的资本。住院管理系统里真正花心思的地方几乎都在数据关系、状态流转和权限边界上。把这些想清楚页面用Vue还是其他框架都只是顺手的事。最后分享一个小技巧源码里坚持写好每个模块的注释和接口文档到了整理LW文档时你只需要把注释按模块汇总文档的一半内容就已经写完了。