每年毕业季我都要在实验室接待好几拨做毕设的学弟学妹问得最多的就是“SpringBootVue的项目代码能跑起来但是答辩不知道怎么说”“SQL脚本老是导入报错”“接口文档到底要写到什么程度”。今年这套社区医院信息平台的毕设项目被问得尤其频繁源码、SQL脚本、接口文档三件套都齐了照理说应该很省心但真拿到手能顺利跑通并讲清楚的人说实话不到一半。这倒不是项目质量有问题而是很多人习惯了“贴代码”没有从业务角度理解这套系统每一层在干什么。这篇文我就拿这个社区医院信息平台当例子把技术选型为什么是这个组合、数据库表为什么这么设计、接口文档怎么写才算合格、前端Vue页面怎么和后端对上话以及部署运行过程中你大概率会踩的坑全部摊开来捋一遍。不管你是拿来当毕设交差还是想借这个项目把SpringBoot和Vue的前后端分离开发流程真正吃透这篇内容都能帮你少走很多弯路。尤其适合那种对框架用法一知半解、但想通过一个完整项目学会“从零到上线”完整链路的人。1. 选题方向与整体思路拆解社区医院信息平台为什么适合当毕设1.1 这个平台到底在解决什么问题社区医院和三级医院最大的区别是规模小、科室精简、人员身兼数职但日常业务一样都不少患者建档、医生排班、挂号就诊、开药收费、病房管理。很多小诊所至今还在用Excel甚至纸质登记本数据零散不说查个历史记录能翻半天。社区医院信息平台的核心价值就是把“患者—医生—药品—收费—住院”这条主线串起来让医院工作人员在电脑前就能完成挂号、写病历、开处方、结算这些日常操作。毕设选这个题目有个天然优势业务场景真实且复杂度适中。你说它有难度它无非是几张表的增删改查加关联查询你说它太简单它又涉及到分页、模糊搜索、权限区分、状态流转、统计报表这些“有说头”的点。答辩的时候老师问“你解决了什么问题”你能从社区医院效率低、记录易丢失、统计困难这些实际痛点出发比那些泛泛的图书管理、在线商城要好讲得多。从项目结构看典型的社区医院信息平台至少包含这几个模块系统管理用户、角色、菜单、基础档案患者信息、医生信息、科室信息、业务流转排班、挂号、诊断、处方、收费、统计报表门诊量、科室收入、药品消耗。每一个模块都能单独展开讲组合在一起又构成一个完整的业务闭环这种“麻雀虽小五脏俱全”的特点正是评委老师最认可的。1.2 技术选型的真实考量SpringBootVue为什么是黄金组合现在Java Web方向的毕设十个里面有八个是SpringBootVue这已经是事实上的行业标配了。为什么是这个组合从后端来讲SpringBoot把Spring那套繁琐的XML配置全部干掉“约定优于配置”让你几行代码就能启动一个Web服务内置Tomcat打成jar包直接跑部署成本极低。从数据库访问层看配合MyBatis Plus这种增强工具单表CRUD几乎不用手写SQL开发效率直线上升这对时间紧张的毕设阶段来说太重要了。前端选择Vue核心理由是它的上手曲线相对平缓而且组件化的开发方式跟后端模块化的思路天然对齐。Vue的三板斧——数据绑定、指令系统、组件通信——掌握这三样配合Element UI这种现成的组件库就能组合出像模像样的管理系统界面。病人列表、挂号表格、统计图表这些在Element UI里都是现成的轮子你要做的只是把数据填进去。这个组合对毕设还有一个隐形的加分项前后端分离架构本身就是现代Web开发的主流形态。答辩时你可以理直气壮地说前端专门负责页面渲染和用户交互后端专门处理业务逻辑和数据持久化两边通过JSON格式的接口通信——这个思路直接对应当前企业级开发的真实场景。哪怕你实际项目里前后端是两个人各做各的只要配合接口文档能讲清楚交互过程老师不会刁难你。1.3 拿到项目源码后第一步应该干什么很多人下载了一个项目压缩包第一反应是点开application.yml改数据库密码然后直接启动报错了就去百度查了半天发现是依赖没下载完。这种“先跑起来再说”的方式不是不行但效率很低。我的建议是拿到整套源码之后先别急着启动按这个顺序来熟悉代码结构。第一步打开数据库脚本文件把所有建表语句过一遍搞清楚一共有多少张表、每张表是干什么的、表和表之间靠什么字段关联。第二步打开后端项目的目录树按controller、service、mapper、entity这些层次看一遍对应着找几个典型接口的实现链路。第三步打开前端项目的src目录看router配置和views目录下的页面了解大概有几个页面、每个页面调用了哪些接口。第四步再回到数据库脚本把初始化的数据管理员账号、测试科室、测试药品找出来这样启动之后你能用正确的账号登录也能看得懂页面上的数据是从哪张表来的。这个“从数据到后端再到前端”的路径本质上是把整个项目按照数据流向重新走了一遍比从代码文件开始看要直观得多。等你把这个流程走完后面再动手去改功能、加模块心里就有一张完整的地图了。2. 数据库设计SQL脚本里的每一张表都有它的业务使命2.1 从业务模块倒推表结构而不是先想着建表很多初学者建表有个坏习惯就是想到什么字段加什么字段最后表建得七零八落不说表之间的关联关系还乱七八糟。正确的做法是从业务流程倒推。以社区医院为例患者第一次来要先建档这就需要一张患者表建档之后要挂号找医生那就需要一张挂号表和医生表医生看病后要开药和写诊断结论这就牵出处方表和诊断记录表患者要去药房拿药药房要有药品库存和收费记录。经过这样一轮推演核心表基本就能定下来了。我给你整理一下这套项目里比较有代表性的表结构你可以对照自己手上的SQL脚本看是不是这个思路。表名业务含义核心字段关联关系sys_user系统用户医生/管理员id, username, password, role_id关联角色表patient患者档案id, name, id_card, phone, gender, birth_date唯一标识身份证号department科室id, dept_name, intro医生归属于科室doctor医生信息id, user_id, dept_id, title, introduction关联用户表和科室表schedule医生排班id, doctor_id, work_date, am_pm, max_count关联医生表registration挂号记录id, patient_id, doctor_id, reg_date, status核心业务表prescription处方id, reg_id, doctor_id, create_time, total_amount关联挂号drug药品id, drug_name, specification, unit, price, stock库存单独字段payment缴费记录id, reg_id, amount, pay_type, pay_time可扩展对账功能这里最重要的一个设计原则是把会重复出现的数据单独抽出来建表用外键逻辑关联而不是一堆冗余字段。比如医生和患者不放在同一张表里因为医生有关职称、所属科室患者有关身份证、既往病史属性差异太大耦合在一起只会让表变得臃肿。又比如排班信息单独建表是因为它跟医生基础信息在业务上是“一对多”的关系一个医生会在多个日期出诊不拆表就根本没法查。2.2 核心表的字段设计和状态管理细节表字段的设计水平很大程度上决定了代码写起来顺手不顺手。我给你举几个这套项目里非常典型的例子。先看用户表。密码字段不要存明文这是底线问题。哪怕是毕设项目也要用MD5或者BCrypt做一次加密否则答辩时老师翻到数据库看到admin/123456清清楚楚摆在那里印象分会掉一档。状态字段也别省一个status字段用来标记账号是否禁用做用户管理的时候才能“停用”而不是“删除”符合真实系统的操作习惯。挂号表是整个系统的业务枢纽它的状态字段设计很能体现设计思路。一个挂号记录从头到尾要经历这么几个状态待就诊、已就诊、已开处方、已缴费。常见的做法是用一个数字代表状态比如0表示待就诊、1表示已就诊、2表示已开处方、3表示已完成。代码里写判断的时候用常量或者枚举来定义这些数字而不是直接写魔法值这样后续修改状态名不会破坏代码。药品表有个细节值得注意价格字段尽量用decimal类型不要用float或者double。你可能觉得多存一位小数无所谓但涉及到金额累加的时候浮点数的精度问题会导致对不上账。虽然毕设数据量小不太容易触发这种bug但规范的字段设计本身就是评分点。排班表里max_count这个字段很多人不理解是干什么的——它是一个医生的半天最大接诊数量挂号的时候判断“这个时间段是否已满”就是靠这个字段。这就是我常说的“业务规则前置到数据层”的思路很多看似简单的设计其实是为了支撑后续的业务逻辑。2.3 SQL脚本的导入顺序和初始数据设计拿到SQL脚本之后第一步一定不要急着整个文件直接执行。虽然很多项目把建表和初始化数据放在同一个脚本文件里但你自己要清楚里面的执行逻辑。正确顺序是先建库再设字符集然后执行建表语句最后导入初始数据。字符集没设置对导入中文乱码的概率极高后面查数据全都是“???”排查大半天才发现是字符集的问题。这套项目的初始数据设计得也比较典型。一定有一个管理员账号通常是admin密码加密后存在库里还有几个测试科室比如全科、内科、外科、儿科对应地配几名测试医生药品表里至少有几种常用药比如感冒灵、布洛芬、阿莫西林。这些基础数据是系统跑起来之后能立刻演示的底气——你登录进去之后科室下拉框里有数据医生排班能排得出挂号的时候患者能找到整个流程才能走得通。关于初始数据的密码字段我要特别提醒一句。如果是通过MD5加密的你可以去网上找一个在线MD5工具把初始密码“123456”的MD5值算出来再放进去如果是BCrypt那每一条数据的加密结果都不一样那就直接用脚本里给的现成值不要自己再生成一次。很多时候登录不了不是因为代码写错了而是你不小心把初始化数据的加密给改坏了。3. 后端工程结构与接口文档实战从Controller到数据落库的完整链路3.1 后端分层架构与统一返回格式SpringBoot后端代码如果没有合理的分层写到最后就会变成一个巨大的Controller类什么业务都往里塞。社区医院信息平台这种正经项目基本都会遵循Controller-Service-Mapper三层结构。Controller只负责接收请求和返回响应不写业务逻辑Service层才是业务规则真正落地的位置比如挂号时要校验医生排班余量、状态流转是否合法Mapper层用MyBatis Plus的BaseMapper接口继承即可复杂的联表查询就手写XML。这个分层的好处是每一层的职责边界非常清晰。Controller层薄薄一层别人看接口文档就像在看目录Service层是项目核心能体现你的业务理解Mapper层负责数据访问。答辩的时候被问到某段业务逻辑你能快速说清楚它在哪一层老师就会觉得你的工程素养过关。除了分层统一返回格式也是后端代码是否规范的最直观体现。一个成熟的系统所有接口的返回结构应该是统一的一般是{code, message, data}三件套。code为200表示成功500表示业务异常401表示未登录。前端axios拦截器只需要判断code就能统一处理成功和失败的情况不需要每个接口单独做异常判断。我自己写这类项目还习惯加一个Result工具类里面有静态方法Result.success(data)和Result.error(msg)这样Controller里返回数据就是一行代码的事。前端拿到的是结构完全一致的JSON配合接口文档描述联调效率能提升好几倍。3.2 核心接口设计与接口文档编写规范接口文档是整套源码里容易被忽视但实际很拉分的一部分。很多同学交上去的接口文档就是把Controller代码复制了一遍我觉得这不算合格的文档。一份能让别人不看代码就能对接的接口文档至少要包含接口地址、请求方式、请求参数说明名称、类型、是否必填、含义、返回参数说明、示例。以这套项目最核心的挂号接口为例它的设计大概是这样的接口地址POST /api/registration请求参数patientIdLong必填患者IDdoctorIdLong必填医生IDscheduleIdLong必填排班IDregDateString必填挂号日期格式yyyy-MM-dd返回结果{code: 200, message: 挂号成功, data: {regId: 12}}你看如果每个对外的接口都按这个标准来写前端开发人员拿到文档之后不需要问你“这个接口传什么参数”直接对着文档就能把页面写完。接口文档的命名也有讲究尽量用名词复数加HTTP动词表达语义比如GET /api/patients表示获取患者列表POST /api/patients表示新增患者DELETE /api/patients/{id}表示删除。这种RESTful风格不仅看着正规答辩的时候提一句“我采用了RESTful API设计规范”档次直接不一样。分页查询的接口也要提前约定好参数名。一般是pageNum和pageSize返回结构是{total: 100, list: [...]}前端表格组件需要这两个字段来渲染分页条。如果前端用的是MyBatis Plus的Page对象序列化出来的字段可能带records和total为了跟前端约定对齐最好在返回前做一次转换只暴露前端需要的结构。3.3 身份认证与权限控制JWT方案在毕设里的合理运用这个系统有管理员和医生两种角色不同的角色能访问的功能不同。管理员可以维护科室、药品、排班信息医生主要是对患者进行诊断和开处方。如果不在后端做权限控制任何登录用户都能调接口那这套系统就只是个“演示壳子”答辩必被问住。毕设最常用的方案是JWTJSON Web Token。用户登录成功后后端生成一个token返回给前端前端把它存在localStorage里之后每次请求在请求头加Authorization: Bearer token后端通过拦截器解析token、获取用户身份。这样做的好处是服务端不需要在内存里保存session天然适配前后端分离和分布式部署。实现起来也不复杂。登录接口校验用户名密码通过后生成token返回写一个拦截器或者Spring Security的过滤器对需要权限的接口进行token解析token解析出的用户ID和角色信息可以放到ThreadLocal里Service层随时可以拿到当前操作人。这样整个链路就通了管理员登录后能操作所有管理模块医生登录后只能处理跟本人相关的业务。权限这块我建议你不要只做“能不能进页面”的前端判断后端接口也要做校验。理由是答辩的时候老师极有可能直接问你“我不通过前端直接拿Postman调你的后台接口是不是就能删数据了”这个问题你能答上来分数能提一个档次。4. 前端Vue工程化与页面交互实现从登录页到数据可视化4.1 前端工程结构与路由设计里的门道前端工程如果是从零搭的Vue项目src目录下面通常会有api、router、views、components、utils这几个核心文件夹。api目录集中管理所有后端接口请求每个模块对应一个js文件比如patient.js、registration.js里面按函数导出接口调用方法router目录配置前端路由views放页面组件utils放封装好的工具类。这种划分方式是Vue工程化的标准做法团队协作时谁负责哪个模块一目了然。路由设计上毕设项目难度不大用动态路由或静态路由都行关键在于两件事路由懒加载和导航守卫。路由懒加载就是component: () import(../views/Patient.vue)这种写法打包的时候每个页面单独成一个chunk首屏加载速度更快这也是个可以写在文档里的性能优化点。导航守卫则是在进入路由之前判断用户是否已登录——没登录就跳转到登录页。这个逻辑统一写在路由配置文件里比在每个页面里单独判断要优雅得多。4.2 axios封装、拦截器与接口对接的全流程前端跟后端做数据交互axios是绕不开的核心依赖。我这里说的封装不是简单的axios.create()而是要把请求拦截、响应拦截、错误处理都考虑进去。请求拦截器里统一添加tokenconfig.headers.Authorization Bearer getToken()。响应拦截器里统一处理业务码如果code是401直接跳转登录页并清除本地登录状态如果是500用element Message组件弹出后端返回的错误信息。实际联调的时候有几个点特别容易出问题。比如后端接口要求传JSON那请求体的Content-Type要设置为application/json如果传的是表单格式又要用application/x-www-form-urlencoded。再比如参数的格式后端RequestBody注解接收的是JSON对象RequestParam接收的是URL参数前端调用时传参方式截然不同。接口文档里如果写得够清楚这些问题都能提前规避。还有个跨域问题本地联调时会频繁遇到。后端跑在8080前端跑在8081直接请求是跨域的。解决办法有两个前端在vue.config.js里配置devServer的proxy把/api开头的请求代理到http://localhost:8080这种方案前端代码里直接写相对路径不用改代码后端配置CORS跨域资源共享允许跨域请求没有前端代理那么干净但也能用。我建议用前者的方案因为打包部署到服务器之后Nginx反向代理可以复用同一套配置逻辑前后端代码都不用改。4.3 高频页面的实现要点和组件化思路一个社区医院信息平台前端页面少说十几个但高频的核心页面就那么几个把这些做透基本就稳了。患者管理页面是最典型的CRUD页面列表用el-table加分页搜索区有姓名、身份证号等条件弹窗里放el-form做新增和编辑。这里有个实用技巧el-table的column宽度、是否需要格式化状态字段都要提前规划好。比如性别字段数据库存的是“0”和“1”页面里要显示“男”和“女”就要用formatter处理。这类格式化逻辑写在展示层不要在数据层就改掉原始值保持数据源的干净。挂号页是这个系统的核心业务页面流程稍微复杂一点先选科室科室联动出医生列表医生选完显示排班时间和剩余号源最后确认患者信息并提交。这里前端的核心挑战是“联动”用Vue的watch监听科室选择的变化然后请求对应医生列表接口再把排班信息填充到界面上。如果代码组织得清晰这个页面在答辩时是很好的讲解素材。统计报表页面用ECharts画柱状图和饼图比如近七天门诊量趋势、各科室挂号占比、药品销售额排行。这类页面的关键不是图表API怎么用而是后端的数据聚合接口怎么写。可以在Service层用LambdaQueryWrapper加groupBy条件做统计更复杂的就用SQL联表查询。数据拿到之后在前端整理成ECharts需要的格式注意x轴和y轴数据要对应。如果时间充裕还可以加一个导出Excel的功能答辩演示的时候用前端极限操作方式导出比后端POI代码要省不少事。5. 从零到可演示的完整部署运行流程照着做就能跑通5.1 本地环境清单与版本对齐这个项目要成功在本地跑起来环境的版本匹配很关键。后端基于SpringBoot建议用2.7.18这个版本它对JDK 8的支持最成熟也兼容大多数毕设环境。如果电脑上已经是JDK 17甚至更高版本那SpringBoot要用3.x的版本但3.x对JDK版本要求高配置方式也有些不同为了省心建议直接装JDK 8。MySQL用8.0版本安装时字符集要选utf8mb4否则写中文容易出问题。本地直接用root账号还是新建一个专用账号都行关键是配置文件里的用户名密码要跟实际环境一致。前端环境相对简单装一个Node.js 16左右版本就够了npm会随Node一起装上。Vue的脚手架如果用的是Vue CLI方式创建的项目npm install安装依赖时如果有网络问题可以配置一下淘宝镜像源大概率能解决下载慢或失败的问题。装好之后跑npm run serve默认起在8080端口。如果8080被后端的Tomcat占用了前端开发服务会找一个近似端口注意看命令行输出就好。5.2 后端启动与前后端联调的完整步骤后端的启动入口是带SpringBootApplication注解的main方法类在IDEA里右键直接运行就行。启动前你需要检查三个地方第一application.yml里的数据源配置包括数据库地址、账号、密码有没有写成你本地实际的地址第二配置文件中如果设置了端口比如server.port: 8080要确认端口没有被占用第三如果用了Redis做缓存要确认Redis服务和密码配置正确否则启动时会连不上。启动日志里出现了“Started Application in x seconds”就说明后端启动成功了。这时候可以在浏览器直接访问一个公开接口比如http://localhost:8080/api/patients/page?pageNum1pageSize10如果返回JSON格式的数据说明后端和数据访问链路都是通的。再启动前端在浏览器输入访问地址看到登录页就说明前端正常。前后端联调时最常遇到的问题就是跨域或者请求404。跨域的解决办法前面已经提过了走devServer的proxy配置。404一般是代理路径或controller的RequestMapping路径跟前端请求地址对不上这时候打开浏览器的开发者工具Network面板看具体的请求URL和后端Controller类上的注解路径仔细对照一遍就能排查出来。5.3 项目打包与线上部署思路如果毕设要求提供可部署的成品项目打包的思路也要提前掌握。后端在IDEA终端执行mvn clean package -DskipTests打包成功后target目录下会生成一个jar文件把这个jar文件用java -jar命令就能运行起来。前端执行npm run builddist目录会生成静态文件把dist目录整个扔到Nginx配置的html目录下就行。如果部署在同一台服务器上Nginx做两层配置静态文件直接返回/api开头的请求反向代理到后端的8080端口。这种部署方式不用改前后端代码也是线上项目最标准的部署姿势。数据库脚本在服务器MySQL里执行一遍把数据源配置改成生产环境的值jar包和dist文件准备好几分钟就能把系统跑起来。答辩演示的时候看你现场部署本身就是一块加分项。6. 毕设开发全流程中的高频踩坑实录与避坑技巧6.1 数据库操作相关典型问题问题1SQL脚本导入放到最后一步执行字符集不一致导致中文乱码。导入之前用文本编辑器把SQL文件打开确认文件头部有没有SET NAMES utf8mb4如果没有在命令行执行一遍SET NAMES utf8mb4再导入能解决绝大部分乱码问题。问题2外键关联导致删表时提示失败。很多建表脚本里写了外键约束删除父表数据时会被子表挡住。解剖的时候如果只想重置数据用TRUNCATE清空子表再处理父表或者先SET FOREIGN_KEY_CHECKS 0再批量删除。问题3身份证号或手机号字段用了int类型位数不够存不下。这类字段从一开始就要设计成varchar身份证甚至要考虑18位int连一半都存不下。改这种问题只需要把字段类型换成varchar重新导入数据即可。6.2 后端开发与启动阶段的疑难杂症问题1pom.xml里依赖明明写了但还是找不到类。大概率是Maven没有把依赖下载完整。解决办法是IDEA右侧Maven面板点击刷新按钮重新加载如果还不行把本地仓库的依赖文件夹删掉重新下载大多数情况能解决。问题2MyBatis Plus分页查询不生效返回的记录数不对。很多新人漏掉了分页插件的配置MyBatis Plus的分页插件必须在配置类里手动声明PaginationInnerInterceptor不配置的话分页查询实际上查的是全表数据。问题3接口返回给前端的日期格式是时间戳。直接序列化Date字段时前端拿到的是一串数字看起来很不友好。给日期字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解或者全局配置Jackson的日期格式就能统一解决。问题4跨域的请求放行了但请求响应里带不了token。这个问题是CORS配置里没暴露请求头字段导致的。如果你用了后端CORS方案allowedHeaders里要加上Authorization或者直接用allowedHeaders(*)省事。6.3 前端开发与页面联调的经典拦路虎问题1页面加载一片空白控制台报Cannot read properties of undefined。大都是接口返回的数据结构跟你页面里取值的路径不一致比如接口返回的是data.list页面里写的是data.records。先打印一下接口返回结果对着数据结构改页面代码别乱猜。问题2npm install的时候报错安装不了依赖。网络问题居多配置一下npm淘宝镜像源再试。如果是lock文件冲突导致的问题删掉package-lock.json重新生成即可。问题3修改了代码刷新页面还是老的页面。Vue项目运行过程中改代码热更新的终端输出如果出现编译错误但界面没变大概率是当前页面的某个组件语法有错导致热更新失败。看终端输出的错在哪里修好后就恢复了浏览器的自动刷新机制。问题4打包后刷新某个页面就404了。这是Vue路由的history模式下静态服务器不知道如何处理前端路由导致的。解决办法是改成hash模式路由或者在Nginx配置里加入try_files $uri $uri/ /index.html。前者改一行代码就能解决答辩部署时建议直接用hash模式省心。7. 针对毕设答辩的快速熟悉路线与差异化发挥思路拿到源码到上台答辩如果时间真的特别紧张也不用把每行代码都看懂。我的建议是抓住一条主线登录→挂号→诊断→开药→缴费。把这一条线涉及的几张大表sys_user、patient、doctor、registration、prescription和几个关键接口登录接口、挂号接口、处方保存接口彻底搞明白你就是这套系统最熟悉的人。老师追问的时候也多半会顺着这条主线问业务细节比如“挂号时同一个医生同时段号满了怎么办”“医生开处方之后库存怎么扣”这些细节你在前面的设计和实现里已经摸清了答起来就不会慌。想拿更高分的话可以挑选一两个有亮点的扩展点提前准备好。比如在日志里记录每次操作的用户操作日志或者在患者管理模块加一个批量导入Excel功能再或者给统计报表页面增加导出PDF的功能。扩展功能不用多一个就够了重点是能体现你“学以致用”的能力。还有一个容易被忽视的得分点是项目目录结构和命名规范。类名用驼峰、包名全小写、常量用大写字母加下划线、接口路径语义清晰、代码里没有大段注释掉的废弃逻辑这些细节虽小但评委第一眼看到的往往就是这些。整洁的代码本身就是你工程素养最直接的证明。8. 写在最后的一点实操建议这套社区医院信息平台的源码、SQL脚本和接口文档本质上已经给你搭好了一个完整的骨架你要做的不是重新发明轮子而是把这个骨架吃透然后基于自己的理解去打磨和扩展。我在实际指导过程中发现拿到项目后愿意花一整天时间把表结构画出来、把接口调用链路跟代码对一遍的同学最后对项目的理解和答辩表现要远好于急着把项目跑起来就万事大吉的人。这个项目真正教会你的不该只是几个框架的用法而是一种从业务需求出发去设计系统、按数据流向去组织代码的思维习惯这才是让你以后自己从零搭系统时最受益的东西。最后再分享一个小技巧拿到任何一个新项目源码先在项目根目录建一个Readme文档把数据库口令、启动步骤、端口号、有的默认账号加上去。这套社区医院项目你打算改业务做二次开发的时候这个Readme能让你少烧不少脑细胞也方便你放到答辩PPT里展示项目完成度一举两得。