★ FEATURED ARTICLE SpringBootVueMySQL这套组合做社区医院管理系统我太熟了。每年到毕设选题的时候总有人来问“学长有没有合适的管理系统项目”十个里面至少六七个最后都落在这类“XX管理系统”上——技术栈经典、业务场景常见、工作量可控用来做毕业设计或课程设计刚好合适。Java后端配MySQL数据库是很多高校课程教的那个路线SpringBoot负责接口和业务逻辑Vue负责页面和交互两个人各司其职前后端分离的架构也正好踩中目前企业开发的主流模式。这篇博文我就以“社区医院管理系统”这个具体项目为例从需求拆解、技术选型、数据库设计到核心业务实现、本地运行与部署把整套东西掰开了讲清楚顺带把答辩时老师爱问的那些问题也给你理一遍。这个系统的业务主线其实不难理解患者建档挂号医生按号接诊、写病历、开处方收费员收费药房发药扣库存管理员维护用户、科室、药品等基础数据最后再用几张统计图表把数据串起来。整个流程是一个完整闭环从业务上讲得通从技术上又不会复杂到做不完非常适合拿来当毕设或者课设。适合的人群也很明确想用Java全栈完成一个像样项目的在校学生、准备转行Java开发需要简历项目的新手、以及帮学生选题或带项目的人。下面直接上干货。1. 为什么社区医院这个选题适合做毕设/课设1.1 业务规模不大不小拿来练手刚刚好很多人一开始喜欢挑“三甲医院管理系统”“智慧医疗平台”这种名字听着很高级的题目三甲医院那个业务复杂程度光一个医保结算就能让人研究两三个月再算上预约挂号、分诊叫号、住院管理、检查检验、手术排期做出来基本就是一个半成品。社区医院的定位就聪明多了麻雀虽小五脏俱全。它有三甲医院一样的核心流程——挂号、看诊、开药、收费、发药但没有医保对接、没有复杂住院管理、没有大型设备对接业务边界非常清晰。我说得直白一点毕设项目的核心目标不是“做出一个上市产品”而是“证明你掌握了一整套软件开发流程”。社区医院管理系统恰好能覆盖这个目标需求分析、数据库建模、后端接口开发、前端页面开发、前后端联调、部署演示每个环节都能在项目里体现。我见过太多人做一个“XX管理系统”结果只有两个页面三个接口那种项目答辩时一眼就会被看穿。社区医院这个场景天然逼迫你设计出七八张业务表、十几个接口工作量正好卡在“能独立完成”和“有含金量”之间。1.2 角色和功能模块怎么拆才合理社区医院相比大医院用户角色也比较简单。我给项目定了四种核心角色角色职责范围常用功能管理员维护系统基础数据、管理账号用户管理、科室管理、药品管理、数据统计医生处理患者就诊业务查看排班、接诊患者、写病历、开处方收费员处理收费业务挂号收费、处方收费、收费记录查询药房管理员管理药品和发药药品库存管理、发药登记、库存预警模块划分上我个人建议做成下面这样一个清单照着这个清单做需求文档和功能拆分就很顺系统管理模块登录认证、用户管理、角色管理、密码修改基础档案模块患者档案管理、科室维护、药品目录维护门诊业务模块医生排班、预约挂号、就诊接诊、病历录入、处方开立收费药房模块挂号收费、处方收费、发药出库、库存查询与预警统计展示模块挂号量统计、科室营收统计、药品消耗排行这样做有一个很大的好处每个模块都有明确的页面和接口归属分工清楚写代码的时候不容易乱。而且无论论文里的“系统功能结构图”还是答辩演示都能直接按照这个框架来讲逻辑感很强。2. 技术栈选型SpringBoot Vue MySQL这套组合好在哪2.1 后端为什么用SpringBoot而不是SpringMVC或SSH很多人纠结后端框架怎么选我的态度很直接现在做毕设还去手写SSHStrutsSpringHibernate属于给自己找罪受SpringBoot几乎已经是企业级Java开发的事实标准。它最大的价值就是把Spring的繁琐配置全部自动化了以前要写一堆XML的地方现在一个注解就搞定。内嵌Tomcat的机制也让部署变得简单打包成jar文件服务器上有JDK就能跑不需要单独装Tomcat。版本方面我推荐SpringBoot 2.7.x搭配JDK 1.8这是目前兼容性最稳的组合。SpringBoot 3.x虽然已经发布很久了但它强制要求JDK17及以上很多学校的教学环境和实验室电脑还在用JDK8而且网上搜到的教程、遇到问题时能搜到的解决方案绝大多数还是围绕2.x的。课设、毕设求的就是一个稳没必要在这上面冒险。至于持久层选型MyBatis Plus是现在的绝对主流比原生MyBatis少写大量XML比Spring Data JPA更容易理解和排查问题。BaseMapper直接提供单表的增删改查分页插件一条配置就能用代码生成器还能帮我们把实体类、Mapper、Service全部生成出来。这些能力对于快速完成毕设简直是降维打击。我带过很多学生用MyBatis Plus写CRUD基本就是抄模板比手写JDBC爽太多。2.2 前端为什么选Vue Element UI前端的技术选型比后端更讲究“投入产出比”。Vue作为渐进式框架学习曲线相对平缓一个新手花两三天理解组件、路由、状态管理这些概念基本就能上手写管理后台。Element UI组件库又专门为后台管理系统优化过表格、表单、弹窗、分页都是现成的拖上去就能用。对整个项目来说前端的开发效率直接决定你能不能在两周内把页面部分写完。Vue2还是Vue3我建议大多数做毕设的人选Vue2。别急着喷这不是说Vue3不好而是Vue2 Element UI这套生态已经成熟到了“网上随便一搜全是案例”的程度。你前端遇到任何问题搜一下基本都有答案。Vue3 Element Plus当然也可以但如果你对组合式API不熟练边学边写可能会拖慢进度。如果你本身对Vue3比较熟那直接用Vue3也没问题项目本身不挑版本业务设计都是一样的。2.3 前后端分开部署靠什么连起来这个项目的前后端分离结构需要一套清晰的数据交互方案。后端统一返回一个Result对象结构长这样{ code: 200, message: 操作成功, data: {} }前端所有请求都经过Axios封装请求拦截器自动带上JWT token响应拦截器统一处理后端返回的数据。这里有几个关键设计点登录接口成功后后端返回一个token字符串前端存进localStorage每次请求前端在Header里带上Authorization: token值后端用一个拦截器拦截需要登录的接口校验token的有效性如果token失效后端返回401前端跳到登录页重新登录写后端接口的时候还要给自己定一个规范路径统一以/api开头业务接口按模块分组。比如/api/register是挂号相关/api/prescription是处方相关/api/drug是药品相关。前端开发的时候通过代理把/api转发到后端的8080端口这样本地联调完全不会遇到跨域问题。这个规范我在后面第5章还会细说。3. 数据库设计关键表和字段一次讲清楚3.1 用户、医生、患者三类基础档案表数据库设计是毕设答辩时老师一定会深挖的部分一个个字段问你“为什么这么设计”都有可能。我按业务模块把表分成几组咱们一组一组说。第一组是用户和权限相关的表至少要有sys_user用户表和sys_role角色表。sys_user的核心字段要包含id主键自增username登录账号唯一password密码存BCrypt加密后的密文real_name真实姓名phone手机号role_code角色标识比如ADMIN、DOCTOR、CASHIER、PHARMACISTstatus状态0禁用1启用create_time创建时间这里要提醒一句不要把数据库表和业务表混在一个表里。我们用一个role_code字段区分角色就够了不需要真的把用户、医生、收费员拆成三张表否则登录认证会写得非常别扭。医生表单独建一张doctor表存医生的专业职称主任医师、主治医师之类、所属科室、擅长领域、个人简介用user_id和用户表关联。这样做的核心价值是账号信息关注“能不能登录”业务信息关注“这个医生擅长什么”两者职责分离。第二组是患者档案表。patient表重点字段id_card身份证号设置唯一约束gender性别birth_date出生日期phone联系电话address联系地址allergy_history过敏史这个字段很重要医生开药时一定会看remark备注患者不直接关联用户表因为患者通常是前台登记建档的不需要登录系统。这个设计在答辩时容易被问到提前想好怎么解释患者是业务对象用户是系统账号两者维度不同。3.2 业务核心表排班、挂号、处方、药品、收费第一张核心业务表是schedule排班表记录医生在某一天某个时段是否出诊。字段包括doctor_id、dept_id科室、schedule_date日期、time_slot上午/下午、total_count总号数、remaining_count剩余号数、fee挂号费。这里必须要有remaining_count因为挂号业务的实质就是“消耗号源”后续在代码里要用乐观锁的方式保证不超卖。第二张是registration挂号表字段包括patient_id、doctor_id、schedule_id、reg_date、time_slot、serial_no序号、status挂号状态、fee、create_time。挂号表的状态设计是整个门诊流程的关键1 待就诊2 就诊中3 已完成0 已取消第三组是处方和药品。prescription处方主表记录doctor_id、patient_id、total_amount、status1未收费2已收费待发药3已发药4已取消prescription_item处方明细表记录drug_id、quantity、price、amount、usage_notes用法用量比如“一日两次一次一粒”drug药品表记录name、specification规格、manufacturer生产厂家、unit单位、price零售价、stock库存、warning_stock库存预警线、category药品分类。第四组是收费记录表charge_record字段包括charge_type收费类型挂号费/处方费、biz_id关联的业务单号挂号ID或处方ID、amount金额、pay_method支付方式现金/微信/支付宝、operator_id操作人、create_time。数据库设计里还有一个通用原则必须强调所有金额字段一律用decimal(10,2)严禁用float或double二进制浮点数存金额会有精度误差做结算时一分钱对不上就是个大事故。状态字段建议用tinyint加注释不要用字符串既省空间又直观。3.3 几张表之间的关系怎么梳理表和表之间其实就是业务关系。抽掉业务外壳来看医生和排班是一对多一个医生有多条排班记录排班和挂号是一对多一个排班对应多个挂号的患者患者和挂号是一对多一个患者可以多次挂号患者和处方是一对多一次就诊可开一个处方处方和处方明细是一对多一个处方包含多个药品条目药品和处方明细是多对多一个药品出现在多个处方里一个处方包含多个药品我建议在写代码的时候使用“逻辑外键”也就是只维护关联字段不一定要在数据库层面建物理外键约束。MyBatis Plus的关联查询本来就是靠代码控制的物理外键反而会给初始化数据和测试带来麻烦。但要记得给常用查询字段加索引比如registration表的patient_id、schedule_idprescription表的patient_iddrug表的name。数据量小的时候感觉不到索引的价值答辩时能说出来“我在高频查询字段上建了索引”本身就是加分项。4. 核心业务链路怎么实现挂号、开方、发药全流程4.1 登录认证与权限控制JWT 拦截器足够用很多人在登录模块纠结要不要用Spring Security。我直接给结论不用。Spring Security那套过滤器链和配置对于毕设来说太沉重了理解成本高调试也麻烦。用JWT加一个HandlerInterceptor就能实现全部需求而且逻辑清晰答辩时也好讲。登录接口的核心逻辑其实只有三步查用户、验密码、发token。代码写出来大概是这个意思PostMapping(/login) public Result login(RequestBody LoginDTO dto) { User user userMapper.findByUsername(dto.getUsername()); if (user null) { return Result.error(用户名不存在); } if (!passwordEncoder.matches(dto.getPassword(), user.getPassword())) { return Result.error(密码错误); } if (user.getStatus() 0) { return Result.error(账号已被禁用); } String token JwtUtil.createToken(user.getId(), user.getRoleCode()); return Result.success(token); }注意这里的passwordEncoder.matches()密码不是明文比对。注册或初始化账号时用BCryptPasswordEncoder对密码加密入库登录时把用户输入的明文和数据库里的密文做匹配。BCrypt每次加密都会生成不同的密文所以哪怕两个用户密码一样密文也不一样这能防止彩虹表攻击。这个点答辩时被问到的概率极高一定要能解释清楚。JWT的token里只放必要信息用户ID和角色不放密码等敏感信息。后端拦截器在请求进入Controller之前校验tokenpublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); if (token null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 解析出用户ID放入request后续业务直接取 Integer userId JwtUtil.getUserId(token); request.setAttribute(userId, userId); return true; }前端配合在Axios请求拦截器里自动带上tokenaxios.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization token } return config })再配合Vue Router的路由守卫没登录就跳登录页登录了但访问无权限页面就提示这一套下来权限控制就算完整了。4.2 挂号扣号用事务和乐观锁解决并发超卖挂号业务是整个项目里最有“技术含量”的一个点也是答辩时最容易被追问的部分。很多人都能写出“先查询剩余号数大于0就插入挂号记录”但这里有个隐藏问题如果两个人同时挂号都查到了剩余号数是1然后同时插入记录结果就变成两个人都挂上了号源成了负数。正确的做法是让“扣减号源”这一个操作成为不可拆分的原子操作。我用一个带条件的更新语句来实现Transactional public Registration createRegistration(RegisterDTO dto) { // 1. 乐观锁扣减号源 int rows scheduleMapper.decreaseRemaining(dto.getScheduleId()); if (rows 0) { throw new BizException(该时段号源已满请选择其他时段); } // 2. 生成挂号记录 Registration reg new Registration(); reg.setPatientId(dto.getPatientId()); reg.setScheduleId(dto.getScheduleId()); reg.setDoctorId(dto.getDoctorId()); reg.setStatus(1); reg.setCreateTime(new Date()); registrationMapper.insert(reg); return reg; }对应的SQL是UPDATE schedule SET remaining_count remaining_count - 1 WHERE id #{scheduleId} AND remaining_count 0这个语句最关键的地方在AND remaining_count 0。数据库会锁住这一行保证同时只有一个请求能成功把remaining_count扣到非负数。affected rows如果返回0就说明号源已经没了直接提示用户就行。别看这只是一行SQL它其实就是乐观锁思想在库存业务里的落地。为什么这个方法要加Transactional因为“扣号源”和“插入挂号记录”是两个操作要么都成功要么都失败。如果扣了号源但插入挂号记录失败用户会莫名其妙丢一个号如果插入了记录但没扣号源下一个用户就会被超卖影响。事务保证了数据一致性。这个思维模式非常重要后面所有涉及多表写入的接口都要沿用。4.3 医生开方与药房发药状态机让数据流转清晰医生接诊的逻辑是确认患者挂号记录状态从“待就诊”变为“就诊中”然后写病历可以选择单独建一张medical_record表也可以简化成在挂号记录里加一个诊断字段再选药品生成处方。提交处方时主表和明细表在一个事务里写入Transactional public void createPrescription(PrescriptionDTO dto) { // 1. 插入处方主表状态默认为“未收费” Prescription presc new Prescription(); presc.setPatientId(dto.getPatientId()); presc.setDoctorId(dto.getDoctorId()); presc.setTotalAmount(dto.getTotalAmount()); presc.setStatus(1); prescriptionMapper.insert(presc); // 2. 循环插入明细 for (PrescriptionItemDTO item : dto.getItems()) { PrescriptionItem detail new PrescriptionItem(); detail.setPrescriptionId(presc.getId()); detail.setDrugId(item.getDrugId()); detail.setQuantity(item.getQuantity()); detail.setPrice(item.getPrice()); detail.setAmount(item.getPrice() * item.getQuantity()); detail.setUsageNotes(item.getUsageNotes()); prescriptionItemMapper.insert(detail); } }处方状态的设计我前面已经列过1未收费 → 2已收费待发药 → 3已发药。为什么要加“收费后待发药”这个中间状态因为收费和发药很可能是两个人在不同时间操作的。收费是确认“患者付了钱”发药是确认“药已给出”状态区分开哪个环节出了问题都能一眼定位。发药扣库存有个关键顺序问题必须在收费成功之后扣库存不能在医生开方时就扣。原因是患者可能开了药但不来缴费如果你在开方时就扣库存会造成大量库存被无效冻结。收费成功后再扣患者是确定要买这批药的库存扣除才有意义。扣库存的接口同样要用“库存充足才更新”的条件UPDATE和挂号扣号源是同一个套路。5. 本地环境搭建与前后端联调实操5.1 先搭好开发环境版本搭配决定后续是否踩坑环境版本这件事我见过太多人栽跟头。打开IDEA、安装MySQL、拉取代码、npm install、启动每一步都可能有版本问题。我直接把推荐版本整理成表格组件推荐版本备注JDK1.8与SpringBoot 2.x兼容最好Maven3.6管理后端依赖MySQL5.7或8.0本教程针对8.05.7注意驱动差异SpringBoot2.7.x稳定教程多Node.js14-16太新的Node版本可能导致Vue CLI编译报错Vue CLI4.x或5.x对应Vue2项目IDEA任意较新版本Ultimate版自带SpringBoot插件如果用的是MySQL 8.0JDBC驱动要选com.mysql.cj.jdbc.Driver连接URL里建议带上参数useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue。前两个参数保证中文不乱码serverTimezone解决时差8小时问题allowPublicKeyRetrievaltrue解决MySQL 8的认证失败问题。这些不是可有可无的配置少了真的会报错。5.2 后端项目从导入到跑通完整步骤拿到一份SpringBoot源码后启动流程其实很固定用IDEA以Maven项目方式导入等待依赖下载完成在MySQL中新建数据库比如community_hospital导入项目里自带的sql脚本修改application.yml里的数据库连接信息URL、用户名、密码直接运行主类CommunityHospitalApplication观察控制台日志看到“Tomcat started on port(s): 8080”就说明启动成功一个很容易踩的坑是数据库字符集。建库的时候记得指定字符集CREATE DATABASE community_hospital DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;utf8mb4比utf8多了对emoji和更多特殊字符的支持也能存正常的生僻字。如果已经是utf8也没什么大问题但新建库还是建议直接用utf8mb4。启动后建议给自己配一个接口文档工具。如果项目里已经集成了knife4j或Swagger直接访问对应地址就能看到所有接口的文档前端联调时对照文档开发非常高效。即便项目没集成临时加一个也很简单一个依赖加一个注解配置的事值得花这个时间。5.3 前端项目启动与联调配置前端拿到代码后目录下打开终端执行npm install npm run servenpm install如果特别慢或者报错大概率是镜像源的问题。国内环境下先切换镜像再装npm config set registry https://registry.npmmirror.com前端启动起来后默认会在http://localhost:8081或其它端口。注意前后端端口不要撞成同一个。后端的application.yml里如果配了server.port8080前端开发服务器就用8081。同时前端项目的vue.config.js里配置代理把所有/api开头的请求转发到后端module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这个配置的价值在于前端代码里请求路径写作/api/login浏览器访问的是http://localhost:8081/api/login开发服务器收到后自动转发给http://localhost:8080/api/login。因为浏览器看到的请求始终是同源的所以根本不会触发CORS跨域问题。很多同学在本地联调时被跨域折磨到崩溃就是因为没用代理而直接在前端写死http://localhost:8080。5.4 部署到服务器把项目真正“交出去”毕设如果能现场演示部署到服务器上的版本观感会提升很多而且这本身也是答辩加分项。后端打包很简单mvn clean package -DskipTests生成的target目录下会有community-hospital-0.0.1.jar文件在服务器上执行nohup java -jar community-hospital-0.0.1.jar app.log 21 前端打包生成静态文件npm run builddist目录下的文件上传到服务器的Nginx静态目录再配置一下反向代理server { listen 80; server_name your-domain.com; location / { root /var/www/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里try_files $uri $uri/ /index.html这行非常关键。Vue用history路由时用户访问/register其实没有真实文件Nginx默认会返回404加上这行配置就能让所有路径都回退到index.html由前端路由接管。数据库也要迁移本地MySQL导出sql文件服务器上导入。这里提醒一句生产环境不要再把数据库密码裸写在application.yml里至少要用环境变量去引用这是我一直强调的习惯。6. 毕设/课设专属问题排查清单和答辩高能问答6.1 本地运行时最常见的几个报错与解法我做这个项目过程中帮人排查过上百次启动问题整理出一张高频报错速查表遇到问题时直接对号入座报错现象根本原因解决方案前端请求/api/login报404Vue代理没配或后端context-path不一致核对vue.config.js代理路径确认后端接口前缀前端请求报CORS error前端直接访问了后端地址用代理方式访问或后端加CORS配置连接数据库报Public Key Retrieval is not allowedMySQL 8的认证机制问题URL加allowPublicKeyRetrievaltrue报错Access denied for user rootlocalhost数据库账号密码配置错误核对application.yml里的username/password前端启动后页面白屏Vue编译报错或入口文件路径问题打开浏览器控制台看报错检查main.jsnpm install报Node版本过高错误Node版本与Vue CLI不兼容用Node 14或16版本重装依赖刷新页面404history路由没有fallback改用hash模式或配置Nginx try_files接口返回401token没传到后端或token过期检查Axios拦截器确认请求头带了Authorization时间字段差8小时MySQL连接时区未设置URL加serverTimezoneAsia/Shanghai前端调用接口后一直弹登录页响应拦截器把业务错误当成未登录检查拦截器判断逻辑只看HTTP 401状态码排查问题的思路也很重要先看浏览器Network面板里请求是否发出、返回什么状态码和响应体再看后端控制台有没有报错堆栈。大多数前后端联调问题都能在这一步定位。不要在没确认问题出在前端还是后端的情况下瞎改配置越改越乱。6.2 演示的时候按什么顺序讲才显得逻辑清晰答辩演示不是把所有功能点一遍而是要有叙事逻辑。我强烈建议你按业务闭环来演示让评委跟着业务走而不是跟着功能菜单走。推荐的演示顺序登录系统展示三种不同角色进入系统后的不同菜单证明权限控制生效管理员进入基础数据维护展示添加患者档案、维护药品目录证明基础功能完整医生排班创建一个明天的出诊排班对应schedule表模拟患者挂号此时能看到号源减一演示核心业务医生账号接诊打开待就诊列表写诊断、开处方演示处方生成收费员账号收费处方状态从“未收费”变为“待发药”演示状态流转药房账号发药药品库存减少演示库存联动最后打开统计报表展示刚才的业务数据出现在图表里演示数据综合这样一套下来评委能很直观地看到数据在系统里流转每一步操作都有上一步做铺垫。演示过程中最好准备一套完整的测试数据几个患者、几种药品、几个医生、几条挂号记录不要让评委看到一个空荡荡的系统。我见过太多人现场临时录入“测试用户”“测试药品”体验很差。6.3 答辩高频问题和加分点提前准备结合我带项目的经验评委最爱问的问题基本围绕四个方面为什么选这个技术、业务怎么实现的、数据库为什么这么设计、项目有什么不足。下面这些问题提前准备好回答思路问为什么用SpringBoot而不用SSH答SpringBoot简化配置、内嵌Tomcat、生态好、上手快是当下企业主流选择能证明我接触的是目前行业主流的开发方式。问JWT和Session有什么区别为什么选JWT答Session存储在服务器内存需要维护会话状态JWT是自包含的无状态token适合前后端分离和横向扩展。JWT的缺点是无法主动失效所以到期时间不能设置太长。问密码是怎么存储的答BCrypt加盐哈希存储就算数据库泄露也不能直接拿到明文密码。问挂号并发超卖怎么解决答用带条件UPDATE扣减号源remaining_count 0保证不超卖配合事务保证扣号和插入记录的一致性。问如果客户反馈系统很慢你会怎么优化答先从SQL和索引入手查询频繁的表加索引引入Redis缓存热点数据静态资源走Nginx缓存接口层面做限流。这个问题能答出这几点就说明有工程思维了。问你觉得项目最不满意的地方是什么答比如当前没有使用Redis存储验证码、药品库存扣减没有用消息队列削峰后面可以优化。重点不是真的贬低自己而是展示你对技术边界有认知。除了上述问题还可以主动加一些亮点代码全局异常处理器统一处理业务异常、参数校验用Valid注解、逻辑删除代替物理删除、操作日志通过AOP切面记录。这些点每加一个都能让代码“看起来”更像企业级项目答辩时主动介绍评委印象分直接拉高。最后再说几句实在话这个项目我带过不少同学完整跑通我自己最大的体会是代码量其实不是最值钱的部分值钱的是你能把每个设计决策背后的“为什么”讲清楚。很多人下载源码跑通后就去答辩结果老师问一句“你这个排班扣号怎么做的”就哑了那等于白做。所以拿到源码之后强烈建议自己手动把核心代码敲一遍哪怕一边抄一边理解也比直接复制粘贴然后装作会了强得多。最后分享一个实用小技巧正式答辩之前把数据库清空重新初始化一遍按我上面说的演示顺序完整走两遍流程确保数据和页面状态都是干净的。中途如果发现哪一步操作报错提前修掉别把修复问题的过程留到答辩现场直播。答辩现场演示项目的流畅程度很多时候比项目本身的功能复杂度更影响成绩。祝各位都能顺利过关。按着这套思路去跑通一个SpringBoot Vue MySQL的社区医院管理系统并不难难的是过程中真的把每一张表、每一个接口、每一次状态流转琢磨明白。项目本身只是一个载体你从里面带走的那套“怎么分析业务、怎么设计系统、怎么排查问题”的能力才是真正值钱的东西。
阅读完成 · 觉得有帮助？
