1. 这个选题为什么值得做先搞清楚它解决什么问题很多人在挑毕业设计题目的时候第一反应是往“高大上”的方向冲——图像识别、推荐算法、语音交互。结果呢算法原理讲不明白工程实现做不出来最后只能到处找现成代码硬糊答辩的时候被问两句就露馅。我在帮人改毕设的这几年里见过太多这种情况了。“医院挂号就诊系统”这个选题看起来不起眼但它是一个非常典型的全栈工程类项目对普通本科学生来说性价比其实很高。它不需要多高深的算法也不需要多复杂的数学基础但它把企业级开发里最常见的那套东西串起来了SpringBoot做后端接口、Vue做前端页面、MySQL存业务数据再加上登录鉴权、权限区分、表格分页、状态流转、部署上线这些真实项目中的高频场景。这个题目的核心价值在于它是一套完整闭环的业务系统。挂号、排班、医生接诊、患者就诊、收费、药品管理、后台看板每一个环节都有明确的数据流动和状态变化。你在做需求分析的时候能讲清楚“患者—医生—管理员”三个角色的边界在设计表结构的时候能讲明白“号源怎么锁、排班怎么排、订单怎么跟”在写接口的时候能练到“怎么写RESTful风格、怎么处理跨域、怎么统一返回结构体”。这些能力恰恰是毕业后找Java后端或者全栈开发岗时面试官最看重的。从项目完成度来说这个系统涉及到的代码量、数据表数量、页面数量都处在一个“半年内能做完”的合理范围内不会像一般的小工具一样三张表就结束也不会像大型商城项目那样拖到答辩前还收不了尾。对某个学院的信息管理与信息系统专业来说我见过至少三个人用它拿过不错的分数。那这个系统到底长什么样简单说患者端是一个面向公众的挂号平台能够按科室、按日期、按医生查排班、挂号、取消号、看候诊状态还附带个人中心里查历史挂号记录医生端是一个接诊工作台看到当天的候诊列表完成签到、开检查单、开处方、写诊断管理端是给院内管理人员用的负责科室管理、医生排班管理、号源池配置、用户管理、数据看板等。在整个技术栈里SpringBoot负责提供RESTful接口和数据访问层Vue负责把接口数据渲染成用户能点击、能填写、能实时反馈的页面MySQL负责持久化保存所有业务数据。前后端分离的架构也让代码的耦合度大幅降低——前端改样式不会碰坏后端逻辑后端改接口不影响前端页面打包分工明确非常贴近真正的工作场景。这篇文章我会从架构设计、数据库设计、核心功能拆解、部署落地、论文写作、答辩指引这几个角度完整地讲清楚这个项目里每个关键细节是怎么做的。文中的工程路径、命令、代码片段我都按实操来写标题里提到的“源码数据库论文部署文档”四件套我会穿插着说明它们在我日常开发中各自承担什么角色。2. 技术选型背后的权衡为什么是SpringBootVueMySQL2.1 后端选型SpringBoot带来的低门槛和生态红利先说后端。国内的SpringBoot能成为毕业生项目默认选项不是没有原因的它最核心的优点是极大降低了配置成本。传统Spring项目那一大堆XML配置是很多初学者的噩梦而SpringBoot的自动配置机制把这些常见的“组装过程”全垫好了你只需要在application.yml里写几行数据源信息它就帮你把内嵌Tomcat、MyBatis或MyBatis-Plus、拦截器、全局异常处理都准备好。以我比较常用的组合为例后端pom.xml里核心依赖大概是这些dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.2/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency这里我想特别说下为什么用MyBatis-Plus而不是Spring Data JPA。虽然两者都能实现数据库访问但MyBatis-Plus更贴近国内开发者的思维习惯SQL放在Mapper层写在XML文件里你可以清晰地看到每一条操作的数据库语句它的BaseMapper内置了insert、update、selectById这些基础方法代码比JPA的抽象风格更直白分页查询只要配一个拦截器再加一个Page对象就能搞定贼顺手。2.2 前端选型Vue为什么比JSP时代先进了一整个世代老一代的“课程设计系统”很多还是JSPServlet直接渲染页面那种做法最大的问题是前后端耦合死重——后端要操心页面逻辑前端要懂Java语法改一个按钮都要重启服务器。Vue的设计思路完全不一样它把“数据驱动视图”做到了极致你在script里定义一个数组页面上的表格会自动渲染出这些数据用户点一下按钮触发的是Vue实例里的方法方法再去调后端的接口接口返回了数据视图自动更新。对于医院挂号系统这个场景前后端分离还带来了一个隐形好处调试效率高。后端接口写完可以直接用Postman测出参入参不需要先写页面再来验证接口有没有通前端页面布局可以用本地Mock数据去调不用等后台开发完才能推进。学生做项目的节奏本来就紧前后端并行开发能省下大量排队等待的时间。前端部分的核心依赖配置我通常会放在package.json里{ dependencies: { axios: ^1.3.0, element-ui: ^2.15.13, vue: ^2.6.14, vue-router: ^3.5.2, vuex: ^3.6.2 } }组件库选Element-UI而不是Ant Design Vue原因很简单对新手友好。它的表单校验、表格分页组件、日期选择器、弹出框很多功能只要给标签加一个属性就能用对后端起家的人特别顺手。而且Element-UI的文档和示例非常多照着抄一抄就能出比较规整的界面。2.3 数据库选型MySQL为什么是这类项目的定海神针数据库没什么好纠结的MySQL几乎是这个量级项目的标准答案。它的InnoDB引擎支持事务和外键约束这对于挂号就诊系统的核心业务——挂号和退号、备药和扣库存、开单和收费——是非常关键的因为这些操作必须保证“要么全成功要么全回滚”。如果哪次操作中途失败了、部分数据却有残留后面业务流转就全乱套了。还有一点容易被忽视的是MySQL的运维成本几乎为零。装好一个MySQL服务导入一份SQL脚本设置好账号密码整个开发周期就不用再操心数据库这层。配合Navicat或DataGrip这种可视化工具建表、看数据、执行查询都很直观哪怕数据库接触不多的同学半天时间也能熟练起来。2.4 用户权限怎么设计三种角色背后的思路医院系统天然分角色这是该毕设的一个亮点。通常我们设置三种角色患者普通用户、医生、管理员。数据库里不一定非要建三张独立的用户表更常见的做法是一张用户表加一个role字段区分角色再根据需要建对应的医生信息扩展表和患者信息扩展表。登录后端的处理逻辑一般是前端把用户名密码交给/login接口后端查库做校验如果通过就返回一个token并把当前角色的基本信息一并回传。前端拿到token后存到本地或Vuex里后续每一次请求都带着这个token后端用一个拦截器或者过滤器去验token验过了才知道“这次请求是谁发来的、他有没有权限调这个接口”。这一整套的“无状态登录”模式也正是现在主流前后端分离项目的标准做法。3. 表结构设计是整个系统的地基别急着写代码我接触过不少急着写接口的同学上来就建表两张表就开干结果没过两天就开始加字段、删字段、重新造数据白白浪费掉很多时间还容易埋下一堆数据隐患。这个项目的表结构我真建议你先在本子上画一画再落到SQL里。3.1 核心表用户、科室、医生、排班、号源、挂号单一张完整的医院挂号就诊系统表结构至少应该覆盖这些核心表。我梳理一份实际工程中比较常见的建表清单表名职责说明关键字段sys_user系统用户表统一存放所有角色的登录账号id, username, password, role, real_name, phonedepartment科室表id, dept_name, description, sortdoctor_info医生信息表关联sys_user和departmentid, user_id, dept_id, title, intro, avatarschedule医生排班表id, doctor_id, work_date, time_slot, total_count, balance_countpatient_info患者信息扩展表id, user_id, id_card, medical_card_no, addressregistration_order挂号订单表id, patient_id, schedule_id, order_no, status, create_timediagnosis_record诊断记录表就诊记录id, order_id, doctor_id, symptom, diagnosis, adviceprescription处方表id, diagnosis_id, drug_id, dosage, usage, amountdrug_info药品信息表id, drug_name, specification, stock_count, pricepayment_record收费记录表id, order_id, pay_amount, pay_status, pay_time这十张表基本上就把这个系统的业务闭环串起来了。用户登录→选择科室→查看医生排班→锁定号源④创建挂号订单→医生查看候诊→填写诊断→开处方→患者缴费。每一步都有对应的表去承接数据任何一环的数据都“有迹可循”。3.2 号源设计是整个系统的灵魂账号越用越需要谨慎很多人第一次设计排班表的时候容易犯一个错误用“医生上班的一天”作为最小粒度建一条记录。比如医生周一全天出诊就在schedule表里建一条“周一 00:00-24:00”然后挂号数直接挂在医生上。这个设计在学生项目里看着能用但一到真实场景就露馅了——现实中医院是要分时段的早上的号、下午的号、甚至精确到半小时一个号源。我比较推荐的是用“时段排班”的思想一个医生一天可能有上午/下午两个时段甚至上午又被拆成8:00-9:00、9:00-10:00这样的时间片每个时段生成一条排班记录记录里带有该时段的总号数、剩余号数。患者挂号的时候选择了某一个具体时段对应号数的剩余量减1退号时再加回来。这样既好实现又方便在论文里讲“我对号源进行了细粒度管控”。CREATE TABLE schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doctor_id BIGINT NOT NULL COMMENT 医生ID, work_date DATE NOT NULL COMMENT 出诊日期, time_slot VARCHAR(50) NOT NULL COMMENT 时段如 MORNING / AFTERNOON 或具体时间片, total_count INT NOT NULL COMMENT 总号数, balance_count INT NOT NULL COMMENT 剩余号数, status TINYINT DEFAULT 1 COMMENT 0停诊 1正常, UNIQUE KEY uk_doctor_date_slot (doctor_id, work_date, time_slot) ) COMMENT 医生排班表;这个表中的唯一索引uk_doctor_date_slot是很有用的设计它能防止同一个医生在同一天同一时段生成重复排班。并且当患者发起挂号的时候不应该直接去UPDATE这个表而应该使用一个带条件的原子操作UPDATE schedule SET balance_count balance_count - 1 WHERE id #{scheduleId} AND balance_count 0;如果你做成“先查余额→判断0→再减一”那在高并发场景下一定会出现超挂。虽然毕设答辩不一定会问到并发但你能把这个“原子扣减”的原理讲出来那绝对是加分项。3.3 挂号单的状态流转逻辑别写得像一锅粥挂号单的状态是设计里最容易乱的地方。我建议用一张状态机图把流转画明白了再动手。我通常习惯用数字表示状态状态值含义说明0待就诊已挂号成功患者尚未就诊1就诊中医生开始接诊可能填写了部分诊断信息2已完成诊断记录、诊断报告已经填完3已取消患者主动退号或超时未就诊被系统取消4已完成待评价如果系统支持评价功能可增加该状态另一种常见设定是用字符串枚举比如“WAIT”、“DONE”、“CANCELED”看着直白但比较容易被写出一条飘在外面的非法数据。数字的好处是排序和分页查询更灵便坏处是可读性差。所以我们通常在实体类里写常量类去映射比如public class OrderStatus { public static final Integer WAIT 0; public static final Integer CONSULTING 1; public static final Integer FINISHED 2; public static final Integer CANCELED 3; }这样在代码里写order.setStatus(OrderStatus.CANCELED)别人读代码的时候不会看天书。4. 环境配置常常是最容易让人绝望的环节逐一击破4.1 本地开发环境的黄金版本我在帮别人排查毕业设计问题的时候发现大量报错根本不是代码问题而是环境版本不匹配。我列一个踩了多年坑后总结出来的稳定组合直接抄作业基本不会出什么幺蛾子组件版本选择说明JDK1.8 或 11选1.8更稳妥兼容性最好绝大多数教程基于此Maven3.6.x配合JDK8完美不要选太新的Maven避免插件不兼容MySQL5.7 或 8.0推荐8.0连接驱动用8.0注意url加时区和编码参数Node.js14.x 或 16.x对应前端工程太新的Node可能导致node-sass编译失败npm/yarnnpm 6 / yarn 1.x想省心用yarn安装依赖更稳定这里有一条非常常见的报错需要单拎出来说MySQL connection error。如果你用的MySQL是8.0那么application.yml里的url最好写成url: jdbc:mysql://localhost:3306/hospital?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueserverTimezone不写就很容易报时区错误allowPublicKeyRetrievaltrue是MySQL 8.0连接时的老坑不写的话IDEA里有时连不上。这一个配置值就能救回很多人的命。4.2 数据库导入的四步速成法标题里的“数据库”指的是数据库脚本文件一般是一个.sql文件。拿到手后要做的不是双击而是先建一个空库再导入。我用命令行说一下这个流程mysql -u root -p CREATE DATABASE hospital DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE hospital; SOURCE D:/path/to/hospital.sql; SHOW TABLES;如果你用的是Navicat直接“新建数据库”然后把字段命名改一改再“运行SQL文件”同样可以。导入后一定要SHOW TABLES确认表都进来了同时抽查一两张表的数据量不然空库跑起来页面白花花的什么都显示不出来到时候我还得从头排一次。4.3 前端Proxy跨域一个配置就能解决开发环境90%的接口不通前后端分离开发时有一个很常见的现象前端启动在8080端口后端启动在8081或8888端口你直接从浏览器访问前端页面让页面去请求后端的接口结果控制台报错Access to XMLHttpRequest at http://localhost:8081/api/login from origin http://localhost:8080 has been blocked by CORS policy很多人第一反应是“后端加CrossOrigin注解”确实能解决但那只是临时解决。更推荐的方式是在Vue前端工程里配置代理让前端页面先请求自己的同源接口然后由开发服务器把请求转发给后端服务器。这一层“中转”把所有跨域问题消化掉了。在Vue项目根目录创建vue.config.js或修改已有配置module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:8081, changeOrigin: true, pathRewrite: { ^/api: } } } } };这样前端请求/api/login会被开发服务器转发成http://localhost:8081/login。前端代码里所有接口路径保持/api/xxx前缀即可后端也无需到处加CrossOrigin注解。这个配置我要划重点很多毕设项目在演示时接口不通十有八九是没做这一步。配置好之后记得重启前端开发服务器不能只改文件不重启配置文件的生效依赖重启加载。5. 接口设计是怎么组织的从登录到就诊全链路拆解5.1 返回结构的统一是一切好接口的第一个标准接口好不好用首先要看返回数据结构是否统一。很多学生项目每个接口出的数据结构都随心所欲有的直接返回一个Map有的把数据包在一个json里有的成功失败共用同一个数据结构前端对接起来苦不堪言。合理的做法是定义一个统一返回对象public class ResultT { private Integer code; // 200成功500失败 private String message; // 提示信息 private T data; // 具体数据 }成功时这样写return Result.success(data)失败时写return Result.error(挂号的号源不足)。前端axios拦截器里统一判断response.data.code如果不是200就弹提示。这样一来后端的接口是统一的前端的处理逻辑也是统一的联调的时候思维负担非常小。5.2 患者端的核心接口清单拿患者端来举例这些接口基本就是系统的门面功能点接口路径方法说明登录注册/api/auth/loginPOST校验账号密码签发token注册账号/api/auth/registerPOST创建患者账号获取科室列表/api/department/listGET查询所有科室按科室查医生/api/doctor/listByDeptGET根据科室ID查医生查询排班表/api/schedule/listGET支持按日期、按医生过滤创建挂号单/api/order/createPOST锁定号源并创建订单取消挂号/api/order/cancelPOST释放号源并改状态查询我的挂号/api/order/myOrdersGET分页查询自己的挂号记录对于“创建挂号单”这个接口我会建议在Service层里加上Transactional事务注解方法内部先做“剩余号数小于等于0就抛异常”再执行“原子扣减”最后“插入挂号单”。一旦中间任何一步失败事务回滚不会产生“号源扣了但订单没建”这种脏数据。5.3 医生端的核心接口思路医生端最核心的接口是“接诊流程”。比较合理的做法是医生登录后先拉取当天本医生的候诊列表这个列表数据其实来源于挂号单表按日期和医生ID去查过滤掉已取消状态。点击某个患者“接诊”之后把状态改成“就诊中”然后就可以填写诊断记录、选择药品、生成处方。处方这块如果要做细可以让一个诊断记录对应多条处方项每条处方项关联一个药品和数量方便后端计算总价也方便前端展示明细。还需要注意一个细节药品库存扣减。医生开处方后合理的行为是同步扣减药品表的stock_count字段扣减逻辑同样要强调用带条件的UPDATE避免超卖。缴费环节可以做得轻量一些——简单记录一条缴费成功记录即可没有必要去接真的支付SDK这个复杂度对毕设来说不划算。5.4 管理端的核心接口思路管理端主要做资源配置和运营概览。科室的增删改查、医生信息维护、排班生成这些都属于标准CRUD重点可以放在排班生成的批量操作上管理员选择医生、选择一周的日期范围、选择时段和号源总数后端一次性生成多条排班记录。这个功能既体现你考虑到了“效率”又能成为答辩时的演示亮点。数据看板是管理端加分项。你可以用几个聚合查询统计比如今日挂号量、各科室挂号占比、最近7天挂号趋势、最受欢迎的医生Top5。前端再配一个图表库比如ECharts界面瞬间就有质感了而且这部分的实现难度不算高。6. 我把“模拟项目X”跑通之后遇到的三个经典Bug这部分我想写几个我实际调试过程中踩到的真实坑都是那种“百度搜不到一模一样、自己排查半天才发现”的问题。希望能帮你少走弯路。6.1 第一个坑日期传参格式不对后端死活收不到正确时间患者端查排班表一般会传一个日期比如“2025-06-15”。如果前端用的是axios默认会把JS对象序列化成JSON格式日期类型会被转成一长串时间戳或带T的ISO字符串比如2025-06-15T00:00:00.000Z。后端用LocalDate接收经常就解析失败或者解析成前一天。解决方案有两种。第一种便宜快捷前端在传参前手动格式化成字符串比如dayjs(date).format(YYYY-MM-DD)后端用RequestParam(date) String date接收再用LocalDate.parse(date)转成日期。第二种更稳健后端在接收日期时使用DateTimeFormat(pattern yyyy-MM-dd)标注GetMapping(/schedule/list) public ResultListScheduleVO list(RequestParam DateTimeFormat(pattern yyyy-MM-dd) LocalDate date) { // ... }这个坑不致命但隔三差五就会遇到值得提前防范。6.2 第二个坑MyBatis-Plus分页查询不生效很多人在用MyBatis-Plus的分页时发现selectPage返回的记录数是全量压根没分页。这个问题的根源基本是没有配置分页拦截器。MyBatis-Plus的分页功能不是开箱即用的需要在配置类里注册一个PaginationInnerInterceptorConfiguration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }没有这个拦截器分页参数会被静默忽略最要命的是它不报错你只会在某一个时刻突然发现数据量不对。所以建议大家在项目刚搭建的时候就先把这个配置写好别等出问题再补。6.3 第三个坑删除科室时外键关联报错被我用逻辑删除化掉科室和医生是一对多的关系。如果直接给department表设外键并开启数据库级约束删除一个还挂着医生的科室数据库会直接拒绝删除。这种交互方式对用户很不友好弹一个“外键约束失败”的英文异常体验非常糟糕。更符合工程习惯的做法有两个要么在删除前先检查是否关联了医生如果关联了在前端提示“该科室下还有医生不能删除”要么引入逻辑删除字段比如deleted默认0删除时只做UPDATE标记查询时统一过滤。逻辑删除的好处是数据不会物理消失还能随时恢复对答辩也更好解释“我考虑到了数据安全问题”。7. 论文框架该怎么写老带新带出来的实用结构标题里特意说了“论文”说明这套项目里论文写作也是重头戏。论文写得好不好直接决定你能不能把系统的设计优势讲出来。很多同学系统做完论文却拖到最后几天硬憋结果答辩时被评委连续追问几个“为什么”就只能尬在那里。我把自己相对满意的论文结构整理一下你可以直接做个参考7.1 第一章绪论定基调绪论部分不用展开太多三块说清楚就行研究背景与意义、国内外研究现状、主要研究内容与章节安排。背景部分可以讲医院排队挂号难、患者就医体验差、信息化的好处现状部分最好找几篇“医院信息系统”相关的文献简单综述一下点出“已有系统存在挂号流程繁琐、医生排班不透明、数据统计能力弱”等问题。这是最基础的写法对非学术大牛来说也足够用了。7.2 需求分析章别抄功能列表要画出用例需求分析是论文里最容易注水但也最容易出彩的部分。核心要做到三点画出系统角色图患者、医生、管理员三个actor写明每个角色的核心用例患者可以登录注册、浏览科室、查询排班、在线挂号、取消挂号医生可以查看候诊患者、填写病历、开处方管理员可以维护科室与排班。然后写功能需求记录表每个功能一行写明请求来源和处理结果。最后补一小节非功能需求把系统性能、安全性、易用性说几句论文的严谨程度一下就上来了。7.3 系统设计章结构图是重点系统总体架构图最常见的画法是把系统分成三层前端展示层Vue页面、后端接口层SpringBoot提供的Controller/Service/Mapper、数据存储层MySQL用箭头标注请求流向。再画一张功能模块图把系统分成“患者端模块、医生端模块、管理端模块、公共模块”四个大块每一块下面列二级功能点。数据库设计这一章用料最实。每个表的字段和说明列一张表更重要的是把表之间的关系用ER图画出来。不需要特别复杂的工具ProcessOn或者PowerDesigner都行。再挑一到两张关键表比如schedule和registration_order讲清楚字段含义和业务约束。7.4 系统实现章别贴整段代码讲关键逻辑系统实现章是很多学生最容易写砸的地方——他们把一整段Controller代码往论文一贴评委看着满页的注解和if-else头都大了。正确的做法是只挑两三段“有设计含量”的片段讲透比如登录时后端签发token的逻辑、创建挂号单时事务保证号源不超卖的逻辑、MyBatis-Plus分页查询的配置方式。每一段代码后面都要配上文字说明解释这段代码解决的问题和实现思路。7.5 系统测试章别光说“运行正常”要用测试用例表说话系统测试部分建议用大量的表把“测试了什么、预期结果是什么、实际结果是什么”记录清楚。比如测试“患者重复点击挂号按钮”预期结果是只能生成一个有效挂号单测试“医生停诊后患者再挂号”预期结果是系统提示该时段排班已停用。有了这种类型的用例论文的说服力会明显提升。8. 部署这事没你想得那么难一套流程反复跑标题里特意说有“部署文档”说明这个项目交付时需要考虑把系统跑在服务器上。部署本身不难但流程比较琐碎任何一个节点踩坑都会让人抓狂。我一般会建议按以下顺序逐步执行8.1 后端部署打jar包一条命令搞定SpringBoot项目最终打成可执行jar包这是最基本的技能。在项目根目录包含pom.xml的目录执行mvn clean package -DskipTests打包完成后target目录下会多出一个类似hospital-0.0.1-SNAPSHOT.jar的文件。传到服务器后直接用java -jar hospital-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod /var/log/hospital.log 21 这里有个比较常见的坑打包时如果pom.xml没配置finalNamejar包名有时会不同。建议自己在pom.xml里设一个固定名称比如build finalNamehospital-api/finalName /build这样每次打出来的都是hospital-api.jar脚本和部署文档里写起来更省事。如果你想让项目在那种行情一般的云服务器上持续运行可以考虑加个Systemd服务管理器但这属于锦上添花不是必须项。8.2 前端部署npm run build之后用Nginx静态托管前端Vue项目部署比很多人想象中简单因为它是纯静态资源。在工程根目录执行npm run build生成出一个dist目录里面是index.html、css、js这些静态文件。把这个目录传到Nginx配置的web根目录下再让Nginx把/路径指过去就行了。需要注意的反而是接口地址问题前端在本地开发时请求的是/api由vue.config.js的proxy转发部署到生产环境后没有这个代理了那前端打包时就要把接口地址改成后端的实际地址。所以我通常会在前端代码里留一个统一的环境变量文件比如.env.productionVUE_APP_BASE_URLhttp://your-server-ip:8081/api然后前端请求统一用axios配上这个baseURL。这一招能避免你把几十个接口路径写死在页面里打包的时候改一处地方就行。8.3 Nginx反向代理的反向思路把接口也一并代理既然有Nginx了如果后端还用的是8081这种直出端口显得没太大质感。更规整的做法是让Nginx统一收口所有访问流量比如监听80端口把带/api前缀的请求都转发给后端的8081端口其余请求都指向前端静态文件。一个非常经典的配置片段是这样server { listen 80; server_name _; root /var/www/hospital/dist; index index.html; location /api { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }这个配置会让“部署”的内涵变得不太一样它同时解决了前端路由history模式刷新404的问题try_files那条、接口跨域问题同域名同端口访问、以及端口暴露的安全问题。把这一套讲清楚足够在答辩时和面试官聊上一阵子。9. 排错手册遇到问题先对照这几条再动手我把日常帮人排查的频率最高的几类问题做成一张自查表。如果你跑项目跑不动先沉住气对照下面这个表格逐项检查能解决大部分基础问题。现象可能原因排查方式后端起不来提示端口被占用8081端口被其他进程占用netstat -ano | findstr 8081找到PID后结束进程前端访问接口跨域报错没配置vue.config.js的proxy或者没重启检查配置文件重启dev server数据库连接失败数据库服务没启动、账号密码错、url配置缺少时区先确保能用Navicat连上再检查application.yml前端页面白屏打包后路由模式问题或者资源引用的绝对路径问题如果是history路由加try_files兜底publicPath改成相对路径分页不生效缺少PaginationInnerInterceptor按上文添加配置类日期字段查不到数据时间格式参数转换失败用DateTimeFormat或前端格式化字符串这张表是我个人维护的“毕设急救清单”里的精华开头如果你遇到其他奇葩问题核心原则就一条一步一动分模块验证。后端单独用Postman调接口前端单独用Mock数据看渲染哪一层通了再和哪一层结合每一步都确认过了就知道问题停留在哪了。最后一个心得做毕设真的不是“拿到源码本地能跑通”就够了你得把每个模块的关键实现逻辑都梳理一遍能够用自己的话把代码讲明白。比如问到“号源怎么防止超卖”你能脱口而出“我用的是条件UPDATE加事务控制”问到“token怎么鉴权”你能解释“网关拦截器验证逻辑”。能讲出这些东西比你把源码背下来有用得多这才是做这个项目真正的收获。根据我个人的经验跑这个项目的过程大约会经历三个阶段第一个阶段是环境配置地狱各种依赖兼容性问题让人想摔电脑第二个阶段是联调大坑前后端数据对不上、状态不流转非常磨心态第三个阶段才是真正体会到“系统跑通”的快感。等你在浏览器里看到患者从挂号到就诊的完整流程流畅走通的那一刻之前所有的崩溃都会变成成就感。这套系统做完你逛三甲医院官网的时候心态都会不一样——你大概已经能猜到它背后大概是个什么样的表结构了。