企业官网建设流程全解析

1. 项目概述与核心需求拆解

医院预约挂号小程序这类毕设题目，这几年的热度一直没降过。原因很简单：它不是一个纯"玩具项目"，而是真实存在的业务场景，后台管理系统、小程序端、数据库设计、接口开发都能串起来，覆盖面非常均衡，同时难度又完全控制在应届生能独立完成的范围内。相比"网上商城""图书管理系统"这种被写烂的题目，医院挂号系统有明显的业务复杂度——排班、号源、订单状态流转，这些概念天然就有细致的逻辑层次，拿来做毕设展示能力和拿来做简历项目，都说得过去。

先说清楚这套系统到底包含什么。从标题看，完整交付物是"前后端代码+说明文档+LW+调试"，我按实际项目拆解下来，核心是三端加一文档：用户用的小程序端、医院运营方用的后台管理端、提供接口和数据处理的后端服务，以及一本配合答辩用的说明文档（通常叫LW或毕设论文）。小程序端主要承担的是普通患者用户的操作入口——浏览科室和医生、查看排班、预约挂号、取消预约、个人订单管理；后端服务则承担核心业务逻辑——用户登录认证、医生排班管理、号源管理、预约下单、订单支付状态处理、后台数据统计等等。

很多同学看到"预约挂号"四个字就以为只在做一个"选医生点一下"的功能，这是最大的误解。真正的核心不在"挂号"那一下，而在"号源"。号源怎么生成、怎么扣减、怎么释放，患者取消预约后号源如何回补，一个医生一天放多少号，每个时间段放几个号，这些运营规则才是整个系统最有价值的部分。我见过不少初版系统把号源写死成固定数字，取消预约后剩余号数完全没变化，这在大作业里没问题，但在答辩上只要导师顺着追问两轮，就能发现业务逻辑的缺失。

从用户场景来看，整个流程是这样的：患者打开小程序，先完成微信授权登录，然后在首页按科室筛选（比如内科、外科、儿科等），进入科室后查看医生列表，医生页面展示职称、简介、擅长方向以及可预约的号源时段，患者选择时段后确认信息、提交预约，系统生成订单，支付（毕设环境下一般是模拟支付）后得到一个包含就诊序号和候诊时间的挂号凭证。就诊当天如果临时有事，用户可以在订单模块里取消预约，系统释放号源并退还费用。这套流程的闭环，就是系统演示和论文写作的主线。

适合参考这套内容的人群，我分成三类：第一类是想直接把这套系统作为毕业设计选题的同学，你可以照着下面的章节把项目跑起来并理解每个部分为什么要这么做；第二类是已经把系统跑起来、但不知道说明文档怎么下笔、怕答辩被问倒的同学，第6章会有详细的论文写作和答辩准备思路；第三类是自己接毕设定制来挣点零花钱的开发者，我把调试排错的那些高频坑都整理在在第5章，能帮你省下大量在微信开发者工具里来回折腾的时间。

2. 技术选型与系统设计拆解

2.1 为什么是springboot+小程序，而不是别的方案

后端选Spring Boot，几乎是当前Java技术栈毕设的默认答案。它的好处在于生态成熟、资料多、出问题容易搜到解决方式，而且Spring Boot 2.x/3.x自带嵌入式容器，本地跑起来只需要一个main方法，不需要额外配置Tomcat。在毕设答辩这个特殊场景里，"能稳定运行"比"技术先进"重要得多。你要是选个冷门框架，环境配置本身就能耗掉一半时间，调试时导师等着看演示，你还在处理依赖冲突，这体验太伤了。

小程序端选微信小程序而不是App或H5，主要考虑三点：一是微信小程序的开发工具和文档非常完善，测试号能直接顶上，不需要注册企业主体也能跑通大部分功能；二是小程序天然适配"预约挂号"这种低频刚需场景，用完即走，符合真实产品定位，作文答辩解释产品设计时也说得通；三是开发和演示的便利性无人能比——手机里打开微信就能扫码体验，比在电脑上启动一个网页效果直观得多。

这里要强调一点：有很多同学习惯性的去找"前后端分离的Vue后台管理系统"来做后台，这在小程序毕设里其实不是必须的。小程序端本身承担了用户操作界面，后台只需要提供管理功能，用Spring Boot自带的模板引擎或者直接做一个简化版的Vue管理页面都可以。千万不要为了堆技术栈把自己项目复杂度抬太高，毕设的核心是业务完整、逻辑自洽、能讲清楚，而不是框架数量多。

2.2 数据库设计：一张表都不能少的设计思路

预约挂号系统能不能经得住答辩追问，七成看数据库设计。你张口说出表结构的那一刻，导师心里基本就有数了。我先把我实践下来最稳的表清单列出来，然后挨个解释为什么需要它们。

这几张表就是整个系统的骨架。在这个基础上，如果你想让系统更有层次感，可以再加两张扩展表：一张是通知表（患者预约成功、取消预约时生成站内信），另一张是医生评价表（就诊后给医生打分、写评价）。这两张表不涉及复杂的关联逻辑，但对丰富系统功能完整性、给论文加篇幅，效果立竿见影。

在设计时容易出问题的是"排班"和"订单"的关系。很多新手会把号源数直接写在医生表里，觉得"这个医生每天放30个号"，那就错了。同一个医生周一可能全天出诊放60个号，周三只出上午放30个号，这就要求号源跟着排班走，每个排班记录独立管理自己的剩余号数。order表里保存的排班id（作为外键）才是正确的关联方式。患者预约某一天的号，就是在扣减当天那个排班记录的剩余号数。

还有一个高频遗漏点：就诊序号。每个订单在创建时应该根据当天已有人数自动生成"第16号""第45号"这种就诊序号，这个看似不起眼的字段，在演示时是非常有说服力的功能细节，说明你考虑到了医院的叫号场景。论文的"系统详细设计"章节里有它，内容也会充实不少。

2.3 用户认证方案：小程序登录的完整链路

小程序端不能像传统网页那样用账号密码登录，它是通过微信的code2Session机制换取用户身份。流程是：小程序端调用wx.login获取临时code，传给后端，后端拿这个code加上appid和secret请求微信接口，得到openid。openid就是用户的唯一标识，后端拿它去user表里查用户，查不到就自动注册一条新用户记录，查得到就正常放行登录。

这个机制里有一个实际开发中很容易踩的点：token的生成与存储。拿到openid后，后端一般用JWT生成一个token返回给小程序端，小程序端把token存到本地storage，后续每个请求都在header里带上这个token。后端用一个拦截器统一解析token、解析openid、把用户信息塞到请求上下文中。这个拦截器千万别省，没了它每个接口都要手动查用户，代码能丑到你自己都看不下去。

有个安全细节值得注意：access_token的过期时间建议设为2小时，小程序端每次启动时先检查本地token是否存在，不存在就重新走wx.login流程。不要用7200秒的微信那边access_token来混淆自己的业务token，这是两个完全不同的东西，我第一次做的时候就在这栽过跟头，排查了大半夜。

2.4 后端项目结构与分层逻辑

后端项目我推荐经典的三层架构：Controller层负责接收请求和参数校验，Service层处理业务逻辑，Mapper层（如果用MyBatis-Plus就直接用BaseMapper）做数据访问。模块上按业务边界分包：module-user、module-doctor、module-schedule、module-order、module-admin，每个包内部再自己拆controller/service/mapper。这种分包方式比按controller/service/mapper分包更符合现在的实践习惯，也好向导师解释"低耦合、高内聚"的软件工程思想。

configuration包里放跨域配置、拦截器注册、JWT工具类；common包里统一放返回结果封装（Result类）、异常处理（全局异常处理器）、分页参数封装。common包看起来不起眼，但它在论文里的重要性很高——统一返回格式意味着所有接口剖面对齐，论文截图时也整洁一致。全局异常处理器更是答辩时被问"怎么处理异常"的标准答案。

3. 核心功能实现与关键代码逻辑

3.1 小程序端页面组织与跳转关系

小程序端的目录结构我建议按tabBar来划分，用四个主菜单：首页、科室、订单、我的。这里面"科室"和"首页"功能上会有一定重叠，设计时可以把首页做成推荐信息流（轮播图、热门科室入口、公告通知），科室页做成完整的分类列表。这样既避免两个tab长得太像，也显得产品设计有层次感。

页面间的跳转关系大致是：首页或科室页 -> 科室详情页（那是一个科室下的医生列表） -> 医生详情页（医生简介+擅长方向+排班列表） -> 确认预约页（选择日期时段、查看费用、提交订单） -> 预约成功页（展示挂号凭证信息）。订单tab下面挂两个子页面：订单列表页（按状态筛选）和订单详情页（查看凭证、取消预约入口）。个人中心里放用户头像昵称、我的收藏、关于系统、意见反馈等非核心但撑门面的功能。

有一个实战上的建议：小程序页面不要一个页面堆一大堆功能，每个页面只干一件事。比如"确认预约页"就不要同时塞"医生介绍""医院公告"这些内容，用户操作路径越长，代码越难维护，后面出bug也越难排查。一个页面只解决一个核心问题，这句话可以写进论文的设计思想里。

3.2 排班与号源管理的后端实现

排班是医生在某个日期、某个时段（上午/下午）的出诊安排。我建议直接用最朴素的方式存储：schedule表里存doctor_id、work_date、period（上午/下午）、total_count（号源总数）、remain_count（剩余号数）。后端提供两个接口：添加排班接口（管理员用）和按医生+日期查询排班接口（小程序端用）。

添加排班的信息来源很关键：毕设环境下没有真实医院HIS系统对接，所以数据要提前准备。实践中的做法是写一个SQL脚本或基于一个排班规则自动生成——比如循环给每个医生生成未来一周的排班数据，每天上下午各放20个号。自动生成排班用Java定时任务或者启动时初始化都可以，我更推荐启动时初始化，因为毕设演示时评审导师可能会看数据库数据，一条条排班记录能看出你确实设计了完整的数据。

号源扣减是最容易出并发问题的点。两个患者同时抢最后一个号，如果代码是"先查剩余号，判断大于0，再更新剩余号"，当两人都查到剩余1，就会同时扣减成0，就出现了超卖——一个号被预约了两次。解决方式有几种：

• 最简单：预约接口里用一条UPDATE语句做原子扣减，update schedule set remain_count = remain_count - 1 where id = ? and remain_count > 0，通过受影响行数判断是否扣减成功，行数为0说明没号了。
• 进阶：在schedule表加version字段做乐观锁，更新时校验version。
• 讲清楚方案层面：用Redis扣减号源库存，同时配合数据库兜底。

毕设阶段我推荐第一种方式，代码简单、逻辑清楚、答辩能讲明白。Redis方案虽然看起来更"高级"，但要在论文里解释缓存一致性、过期策略等问题，如果你本身对Redis不熟，很容易被追问到答不上来。

3.3 预约下单的事务处理与状态流转

预约下单是整个系统的核心操作，它的整个过程涉及多张表的更新：创建订单记录、扣减排班剩余号、生成就诊序号。这三个操作必须保证一致性，要么全部成功，要么全部失败。用@Transactional注解，把方法包在一个事务里，任何一个环节抛异常就整体回滚。

就诊序号的生成规则建议这样设计：每种班次（一个医生一个上午/下午）下面，按时段内的当前已预约人数计算。具体来说，预约接口在事务内先锁住排班记录（SELECT ... FOR UPDATE），拿到当前剩余号数，就按总号源减去剩余号加一算出来。初始20个号，剩余18个，那新预约就是第3号。

订单状态我用一个整数字段来管理，0待支付、1已支付、2已取消、3已完成。待支付状态下用户可以取消订单，已支付状态下也可以申请取消并退款（毕设里就是模拟改状态），已完成表示就诊结束。取消预约时要回补号源吗？要的。但这里有个细节：只有已支付和待支付状态下的取消才需要回补remain_count，已完成状态下不应该再有取消入口，前端也要对应隐藏按钮。这些状态之间的流转条件，论文的"系统设计-状态图"部分直接照这个画就行。

模拟支付的实现：下单时直接传一个待支付状态的订单，小程序端点击"确认支付"按钮后，调用后端的模拟支付接口，后端接收到参数后，直接把订单状态改成已支付，同时往payment表插一条支付流水。注意这里不要真的发货支付凭证，这是毕设的安全边界。如果需要做得更像真实系统，可以加一个"支付倒计时"逻辑：超过15分钟未支付的订单自动失效并释放号源。

3.4 后台管理端：支撑运营的数据入口

后台管理端是整个系统容易被忽视的部分。很多同学觉得把患者小程序做出来就万事大吉了，但答辩时导师一定会问："科室数据、医生数据是通过什么方式录进去的？总不能直接改数据库吧。"后台管理端就是回答这个问题的关键。

后台管理的核心功能划分如下：科室管理（新增、编辑、删除科室）、医生管理（录入医生信息、分配所属科室、上传头像）、排班管理（按医生添加排班、查看号源消耗情况）、订单管理（查看所有预约订单、处理退款）、数据统计（预约量TOP5医生、每日预约趋势、科室预约占比）。数据统计功能对论文非常有价值，可以大幅提升系统完成度的观感。

后台界面可以选择用Vue写一个独立的管理页面，也可以选择用Spring Boot内置的模板引擎做一个极简的管理页面。我更推荐后者，因为独立前后端分离意味着要多维护一套CORS配置、多考虑一份跨域问题，这对毕设来说性价比不高。如果个人能力偏前端方向，那就选Vue，只要能稳定运行不出岔子都是好方案。

4. 项目部署与运行调试

4.1 本地环境准备清单

在我调试过的项目中，环境版本不统一是小白遇到的最高频问题。先列一套稳的组合：JDK 8或JDK 11（JDK 17配Spring Boot 2.x容易遇到兼容问题，配3.x才匹配，建议直接JDK 8起步最稳）、Maven 3.6+、MySQL 5.7或8.0（8.0要留意驱动配置com.mysql.cj.jdbc.Driver，5.7用org.gjt.mm.mysql.Driver）、IDEA版本随意只要是2019之后的、微信开发者工具最新稳定版即可。如果你用的是别人的项目源码，第一件事是去看pom.xml里面Spring Boot的版本，再去查对应JDK的兼容范围，这个顺序反了会出现各种奇奇怪怪的依赖报错。

数据库准备好之后要执行的步骤是：创建数据库，编码选utf8mb4（不然微信昵称里的emoji根本存不进去），然后导入项目自带的SQL脚本。很多同学卡在"导入后表是空的"，因为没有看清是不是有专门的初始化数据脚本。正常项目会分为建表脚本和初始数据脚本两个文件，前者创建结构，后者插入管理员账号、科室、医生等测试数据。如果你接手的时候只有建表脚本，初始数据就自己写，手工INSERT几个科室和医生，不用多，每个科室配2个医生，未来7天排班生成上，演示就够用了。

4.2 后端启动步骤与配置项逐项说明

修改application.yml是启动后端的第一步，重点配置项如下：spring.datasource.url里的数据库地址、用户名密码；服务启动端口，默认8080就行；如果涉及文件上传（医生头像），需要配置一下上传大小限制。数据源的url建议写成jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，注意serverTimezone不能漏，否则启动会报时区错误，这种报错新手最容易懵。

在application.yml里还要配一个自定义业务参数：微信小程序的appid和secret。即使用的是测试号，这两个值也要真实填进去。启动时Spring容器会读取这个配置注入到常量类中，后面登录接口会用到。

后端启动成功的判断标准有两个：控制台出现"Started Application in x.xxx seconds"没有异常堆栈；浏览器访问http://localhost:8080/api/health或某个测试接口能返回数据。我习惯在项目里放一个简单的/health接口返回当前时间，这个是自测用的，只花五分钟，但能帮你确认网络链路通不通。

4.3 小程序前端导入与调试配置

打开微信开发者工具，选择"导入项目"，目录选到小程序端所在文件夹，AppID处如果没注册就用"测试号"。这里有一个关键设置：在详情 -> 本地设置中勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"。因为开发阶段所有API请求都是http://localhost:8080，不勾选这个，真机预览时小程序会拒绝所有请求。

小程序端有几个文件需要核对调整：app.js里的globalData中，baseUrl字段要修改成你电脑局域网IP加后端端口，比如http://192.168.1.101:8080。注意不要改成localhost或127.0.0.1，因为真机调试时手机访问的是你电脑的局域网地址，localhost指向的是手机自己。如果需要用开发者工具的模拟器而非真机调试，localhost也能凑合用，但真机场景必须改成局域网IP。另外，如果后端没配跨域，这里也要配合后端的CORS设置一起处理。

4.4 常见报错速查：按现象定位原因

我整理了调试这套系统时最常见的几个报错，按现象排好：

表名问题的处理要特别说一下。order是MySQL的保留字，如果你把预约订单表命名为order，写SQL时每次查表都要加反引号嵌套处理，代码里写起来特别容易出错。我的建议是表名直接改成appointment或t_order，一劳永逸地避坑。

5. 常见问题与避坑实录

5.1 小程序端开发中容易踩的坑

第一个高频坑是图片资源访问问题。医生头像如果在后台管理系统里上传到本机磁盘，然后直接通过后端路径访问，小程序端会出现两种问题：本地调试时http的图片在小程序里能被加载，但真机预览时会出现"图片域名不在白名单"的提示。解决方式有两种：一种是开发阶段就使用本地图片路径，所有头像统一放前端images目录，完全绕开网络图片的合规限制；另一种是下载图片时直接转成base64塞进数据库，虽然简单粗暴，但确实能彻底规避域名问题。毕设场景我更推荐第一种方案，最省事。

第二个坑是token过期导致接口报401，但业务代码里没有统一的失效处理。表现就是用户明明在正常操作，突然所有请求都失败了，但没有弹窗提示，也不好排查。处理方式是在小程序的request封装里统一拦截401状态码，然后跳转重新登录流程，同时做Toast提示"登录已过期，请重新进入"。这一行逻辑虽然小，但用户体感差别巨大，建议有此需求的直接补上。

第三个坑是前端数据缓存策略。科室列表、医生列表这种数据基本不变化，每次进小程序都从后端拉取很浪费流量。就实际体验而言，在首次拉取后把JSON数据存入storage，下次进入时先读缓存、再静默更新，体验会好很多。但要注意：排班数据绝对不能做前端缓存，它变化极其频繁，患者看到过期的号源信息可能会直接误解误操作。

5.2 后端与数据库层面的常见坑

数据精度问题常出现在支付金额上。很多同学图方便用double类型，但double在Java里涉及金额运算时会产生0.009999999这种精度问题。金额字段在数据库里必须用decimal(10,2)类型，Java代码里用BigDecimal来接收和运算，这是一个没办法将就的硬规则。挂号和订单金额只是个标价时还好，一旦设计到退款计算，精度问题就会被放大。

还有一个很隐蔽的坑：自动生成排班的日期边界。如果生成排班数据时用"当前日期加7天"，那么项目跑到第8天时，医生们就全都没有排班了，演示的时候打开小程序看不到号源，当时场景会非常尴尬。解决方法是每次启动项目时，检查未来7天是否已有排班数据，没有就自动补齐。这个逻辑加在项目启动初始化方法里，二十五行代码，价值巨大。

密码加密是另一个必须考虑的点。后台管理员的登录密码不能明文存库，用MD5加盐或BCrypt加密后存储。这里有一个配套细节：初始化管理员数据时，SQL脚本里放的是加密后的密文还是明文？如果是明文，那说明你设计的时候加密策略只做了一半。正确的做法是：脚本里存储密文，密码默认admin123，在论文里写明"初始密码是admin123，登录后请修改"。这个小细节被我们很多同学忽视，但如果导师真的打开数据库看数据，一眼就能辨出水平。

5.3 毕设项目演示前的自测顺路

项目做完、论文写完，正式演示之前，我建议按下面这个顺序把系统完整走一遍，发现问题立刻修复：

1. 后端启动后，先用接口文档或Swagger把所有核心接口都调一遍，确认全部返回成功；
2. 小程序在开发者工具模拟器里完整走一遍：登录 -> 选科室 -> 选医生 -> 看排班 -> 预约 -> 模拟支付 -> 查看订单；
3. 测试取消预约功能，取消后再查看号源剩余数是否回补；
4. 去后台管理系统，新增一个医生和一段排班，然后在小程序端确认新数据能正常展示；
5. 最后换测试账号（另一个微信号）登录，验证多用户场景下，号源扣减互不影响。

这个流程里最容易翻车的是第三步——取消回补。很多同学写完取消接口根本没测试，正式演示时导师随手点了个取消，号源数没变，那就直接暴露了业务逻辑的裂缝。其余几个步骤只要代码里做成稳定流程一般都能过，但这个环节请务必自测。

5.4 关于调试定制的一些实用经验

接手别人的项目做调试时，我给出的执行顺序是这样的：先不要急着跑，先看pom.xml确认依赖版本、看application.yml确认数据库配置、看SQL脚本确认表结构和数据。这三类文件看完，项目能不能跑起来，心里基本就有数了。最怕那种上来就敲mvn spring-boot:run的人，报错后看到一堆不认识的异常，其实大多数问题都出在配置而非代码。

如果客户要求定制功能，比如增加"多院区选择"或"医生排班冲突检测"，先评估改动范围，再报时间。加一个院区字段要先扒掉所有涉及医院信息的页面和接口，看有没有硬编码的地方，这个工作量往往比预期大。直面沟通时，宁可多估半天时间，也不要承诺一个完不成的期限。

6. 说明文档内容规划与答辩准备实操

6.1 毕设论文/LW的高效章节结构

说明文档（LW）通常就是毕业设计说明书或论文主体，建议按下面这个结构来组织，既符合学校模板惯例，也覆盖了系统设计的每个层面：

1. 绪论：课题背景、国内外研究现状、研究内容与意义；
2. 相关技术介绍：Spring Boot框架、微信小程序开发框架、MyBatis-Plus、MySQL数据库、JWT认证等；
3. 系统分析：需求分析、功能需求列表、非功能需求、用例图与用例描述；
4. 系统总体设计：架构图、功能模块划分、技术架构选型理由；
5. 数据库设计：概念结构设计（ER图）、逻辑结构设计（表结构描述）；
6. 系统详细设计与实现：分模块写清每个功能的设计思路、核心代码、截图；
7. 系统测试：测试环境、测试用例、测试结果与分析；
8. 总结与展望：完成的工作、存在的不足、后续改进方向。

很多同学习惯性把论文当成"代码说明书"，大量粘贴代码，这是误区。论文评委关注的是你的分析和设计思路，代码是论证材料，不是主体。每个功能模块先写"设计思路"，再贴关键代码（不要贴整类），加两三行解释，最后配运行截图，这个节奏就对了。

6.2 图表工具与规范细节

论文配图建议统一样式，整体质感会提升很多。用图标准制架构图、流程图、用例图，导出png时把缩放比例调清晰一点。时序图画预约流程的交互过程，答辩时配合演示，效果非常好。ER图画数据库实体关系，注意实体名和字段名要与数据库脚本中完全一致，否则答辩时导师拿库一比就会发现破绽。

论文中的图表其实不用多，但要精。核心的几张必须有：系统架构图、功能模块图、预约业务流程图、预约时序图、数据库ER图、核心表结构说明表。这几张图就足以支撑起整个论文的了，其他的图表按需补充即可。

6.3 答辩前的功能演示脚本

答辩演示建议提前设计脚本，不要现场发挥。一个输出完整的演示动线设计如下：

1. 进入小程序首页，介绍整体界面布局；
2. 登录注册演示：展示微信授权登录过程；
3. 浏览科室与医生列表，讲解数据来源和展示逻辑；
4. 选择排班、发起预约、模拟支付，重点讲解号源扣减逻辑；
5. 进入订单列表，演示取消预约，再回排班页展示号源回补；
6. 切换到后台管理端：添加一个医生和排班，再回到小程序端刷新展示新增数据；
7. 数据统计模块：展示预约量排名和按日趋势统计。

这个动线重点包含了二次数据联动的演示，比干巴巴只跑了小程序前后效果好很多。准备时可以先录一遍视频，看看每个环节切换是否顺畅，哪里有卡顿就优化哪里。演示中如果接口报错，不要慌，先看console和后端日志。因为无论你怎么准备，任何临时状况都有可能发生，主要原因多半是环境问题而不是逻辑问题。保持一个"刚才数据被清理了，我重新操作一次"的镇定状态，比什么都重要。

6.4 答辩常见提问预备

有些问题导师几乎每年都会问，提前把答案备好能提升明显信心：

• 为什么选这个课题？答：预约挂号痛点现实存在，解决真实问题，毕业后也具备完整的产品思路；
• 系统有哪些安全隐患？答：JWT令牌过期、全局异常处理、密码加密、SQL注入防护（MyBatis-Plus预编译机制）；
• 如果并发量大怎么优化？答：Redis缓存热点数据、Redis扣减号源、MQ异步处理支付回调（哪怕还没做，也能讲出思路）；
• 为什么用MyBatis-Plus而不是MyBatis？答：代码量少、内置CRUD方法、分页插件好用，提高开发效率；
• 测试用例覆盖了哪些异常场景？答：并发抢号、重复预约、取消回补、超时未支付。

这里有一个重要提醒：论文里写了什么技术，你就要能回答对应的原理问题。如果论文里写了Redis，就要清楚Redis缓存和数据库一致性怎么处理；如果写了RabbitMQ，就要能解释为什么用消息队列、消息丢失怎么处理。不熟悉的技术宁可只提名字，不要深入写进系统设计，否则被追问到说不清，反而是减分项。

7. 从经验中提炼的几点心得

做了不少类似的毕设项目和调试，有一点体会想分享给大家：预约挂号系统这种题目的上限空间其实很大，但在毕设这个阶段，大部分人都只做到了"能跑"这个层面。如果你愿意多做一步，比如把号源管理做成真正可配置的、给管理后台加一个简单的数据可视化大屏效果，很可能就会呈现出完全不同的效果。哪怕只是多写一个"预约趋势折线图"，在论文里的分量都会明显不一样。

另外一个很实用的建议：整个开发过程中，每次调试成功后，立刻在文档里记录你改了什么、为什么改。这些碎片记录最后整理成论文的"系统测试"和"常见问题"章节，完全不用再回忆。许多同学卡在写论文这一步，并不是因为没做东西，而是没有痕迹可以回顾——边开发边记录，后面的工作量会小很多。这也是我后来每次接类似项目都坚持执行的习惯。

最后给所有准备用这套系统的朋友一句经验话：代码出错不可怕，怕的是不懂排查思路。从一开始就养成看日志的习惯，后端报错优先看最后几行Caused by，小程序报错优先看NetWork面板里的请求状态。按这个思路走，你会发现自己独立解决问题的能力在两周内就会上一个大台阶。挂号系统的业务闭环一旦通顺，写起论文来也就只是时间问题了。