SpringBoot医疗就诊平台从0到1：表设计、并发控制与踩坑清单

简介：面向计算机专业毕业生的医疗就诊平台毕业设计论文，以SpringBoot+Java+MySQL实现，内容覆盖系统需求分析、功能设计、数据库设计及实现细节，适用于毕业设计选题、论文撰写参考和项目开发学习。压缩包内仅含1个docx文档，大小约3.62MB，文件类型为完整的毕业论文Word版，包含中英文摘要、目录、正文及参考文献，可直接阅读、编辑和打印。目前已有61人浏览学习，资源整体结构清晰，从平台可行性分析、用例分析到功能模块如患者信息、医生信息、挂号管理、药品管理、就诊管理等均有详细阐述，还涉及数据安全与隐私保护、系统可扩展性等内容，适合需要完成类似课题的本科生借鉴。读者可通过该文档掌握医疗就诊平台的整体设计思路、SpringBoot框架的使用方式、MySQL数据库表设计方法以及论文写作规范，为自身毕业设计提供具体参考。

1. 为什么毕业设计选 SpringBoot 医疗就诊平台：从文档标题到完整交付

你手上的「毕业设计论文SpringBoot医疗就诊平台.docx」，表面是一份论文文档，实际上是整个毕设项目的成果索引：系统设计、核心代码、测试记录都要沉淀进去。医疗就诊平台这个选题对学生很友好，但友好的点不在表面——挂号、就诊、处方、药品四个环节自带「并发、状态机、事务」三个答辩高频追问的硬话题，同时业务量级又不用上分布式架构，正好卡在大学所学能力能覆盖的范围。

选 SpringBoot 是因为生态成熟、启动效率高：MyBatis-Plus 管 CRUD、Spring Security 管登录、Swagger 管接口文档，第三方资料多到不需要闭门造车。系统做出来能解决的实际问题是：患者线上预约挂号、查看医生排班；医生接诊后书写病历、开立处方；管理员维护科室、医生和号源数据。三个角色各有一条清晰的操作链路，论文里的用例图、时序图、类图全都有真实业务可画。

所以这个选题适合两类人：一类是时间紧、想在一个月内把系统跑通并写出完整论文的应届生；另一类是已经会写 CRUD、想通过一个带业务深度的 Java 后端项目补上并发与事务功底的开发者。全文会照着「模块划分→数据表→核心接口→踩坑→验收」的顺序走，你可以边读边建表边写代码。

2. 把医疗平台拆成能被论文写透的三个闭环：模块边界与十张核心表

2.1 从论文第三章反推功能边界：哪些功能值得进系统

写论文时第三章「系统设计」必须给出用例图、时序图和 E-R 图，所以功能边界不能拍脑袋，要反过来推：凡是画不出图、建不出表、讲不清状态流转的功能，都不该进系统。常见做法是把平台按业务拆成三个闭环——患者侧的预约挂号闭环、医生侧的就诊处方闭环、管理侧的基础数据与统计闭环，每个闭环对应一组用例和一张核心表。

三个闭环落到角色上就是三条线：患者端做「查科室→查医生→预约挂号→查看就诊记录」，医生端做「看排班→接诊→写病历→开处方」，管理端做「维护科室与医生→设置号源→看统计」。这三条线刚好对应论文里的三个用例图，每个用例图都能延伸出两到三张时序图，第四章的实现章节自然就不会空。

我一般会建议把「在线支付」从功能清单里划掉。支付涉及第三方沙箱、回调验签，答辩时评委顺着问一句「你的对账怎么做」就很难收场。消息推送和多院区同理：前者引入第三方平台依赖，后者让数据表复杂度翻倍。功能边界守住了，论文第三章的用例图才画得清爽，第四章的代码量也才压得住。

每个功能都要能对应到「一张表或一组表 + 一个状态字段」。比如「预约挂号」对应挂号单表和 status 字段，「医生排班」对应排班表的日期与时段。这样论文第四章写「功能实现」时，每一节的结构都是：表结构 → 接口逻辑 → 效果截图，评委看起来会很顺。

2.2 十张表怎么设计：从用户到处方明细的依赖顺序

数据表是论文第四章「数据库设计」的原材料，也是后续所有 SQL 的地基。医疗就诊平台常见的表数量在 10 张上下，按依赖顺序排是：用户表、科室表、医生信息表、排班表、挂号单表、病历表、处方主表、药品表、处方明细表，最后再加一张操作日志表。

核心表设计上有一个原则：用户表不要和医生信息混在一张表，因为患者和医生的字段差异很大。我习惯用 user_type 区分角色，医生再单独建 doctor_profile 表存科室 ID、职称、简介、接诊量。排班表也一定要单独拆出来，而不是在医生表里存一个「剩余号数」，因为号源是按日期和时段动态变化的，拆表才能支持同一天不同时段的额度配置。

CREATE TABLE dp_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '排班ID', doctor_id BIGINT NOT NULL COMMENT '医生ID，关联doctor_profile', work_date DATE NOT NULL COMMENT '出诊日期', time_slot TINYINT NOT NULL COMMENT '时段：1上午 2下午 3晚间', total_number INT NOT NULL DEFAULT 20 COMMENT '该时段可挂号总数', remain_number INT NOT NULL DEFAULT 20 COMMENT '剩余可挂数量', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', create_time DATETIME NOT NULL COMMENT '创建时间', UNIQUE KEY uk_doctor_date_slot (doctor_id, work_date, time_slot) ) COMMENT='医生排班表'; CREATE TABLE dp_registration ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '挂号单ID', schedule_id BIGINT NOT NULL COMMENT '排班ID', patient_id BIGINT NOT NULL COMMENT '患者ID', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0待就诊 1已完成 2已取消 3已爽约', create_time DATETIME NOT NULL COMMENT '挂号时间', visit_time DATETIME NULL COMMENT '实际就诊时间', KEY idx_schedule_status (schedule_id, status) ) COMMENT='挂号单表';

这段建表 SQL 有两个设计点值得留意。排班表加了唯一索引 (doctor_id, work_date, time_slot)，从数据库层挡住「同一个医生在同一时段被插入两条排班」。挂号单只存 schedule_id 和 patient_id，不冗余医生和科室名称，因为名称会随基础数据变化，需要时 JOIN 查询即可，避免数据冗余导致的不一致。

version 字段是留给后面做并发扣减号源用的，第四章会重点讲。total_number 和 remain_number 分开存，是为了管理员改号源总量时不影响剩余数的语义。挂号状态用 TINYINT 而不是 VARCHAR，排序和统计都方便，论文里也可以给出状态枚举定义。

另外一张容易被忽略的是处方明细表，它要冗余一份「药品价格」快照字段。理由是药品价格日后可能调整，历史处方必须保留开立时刻的价格，否则论文里「收费统计」这一节的金额怎么都对不上。这个细节处理好之后，第四章实现处方功能时不需要额外处理价格追溯问题，答辩时提到这个点反而是加分项。

3. SpringBoot 工程骨架与第一个能跑的查询：从配置到 JSON 响应

3.1 工程结构与三件套配置：Controller-Service-Mapper 的项目骨架

拿到空白的 SpringBoot 工程，第一步不是写业务代码，而是把分层定死。常见结构是 controller（接收请求、参数校验）、service（业务逻辑、事务边界）、mapper（数据访问）、entity（数据库实体）、common（统一返回体和异常处理）。这样的分层和论文第四章的类图能直接对上，评委看源码时也容易按图索骥。

依赖选型上，我一般会选 Spring Boot 的 2.x 主线配合 MyBatis-Plus 3.x，再用 Lombok 减少 getter/setter 样板代码。版本号建议直接用你本地 Maven 仓库里已有的，避免下载失败浪费时间。如果要用 JWT 做登录态，就再引一个 JWT 工具库；不引也行，先靠拦截器手工校验也能把系统跑通。

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <scope>provided</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> </dependencies>

依赖没有写版本号，是因为 Spring Boot 的 parent 已经统一管理了 starter 的版本，MyBatis-Plus 和 MySQL 驱动你补一个和本机环境匹配的版本即可。pom 里最关键的是 mybatis-plus-boot-starter，它替你完成了 Mapper 扫描和 SQL 注入，写接口时基本不用手写 XML。

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/hospital?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

url 里的 useUnicode、characterEncoding、serverTimezone 三个参数必须写全，少一个就可能出现中文乱码或者 LocalDateTime 解析差 8 小时。jackson 的 date-format 配合 time-zone 解决返回值时间格式问题。map-underscore-to-camel-case 让数据库的 create_time 自动映射到实体的 createTime，少写一堆字段映射注解。log-impl 选 StdOutImpl 是为了在控制台直接看 SQL，排错时非常有用。

3.2 科室列表接口：从建表到返回 JSON 的最小路径

选「科室列表」做第一个接口，是因为它只有一张表、一个查询，链路最短。跑通之后你就可以确认：工程能启动、数据源连通、MyBatis-Plus 映射正常、前端能拿到 JSON。后续的挂号、处方接口都复用同一套写法。

// Department.java @Data @TableName("dp_dept") public class Department { @TableId(type = IdType.AUTO) private Long id; private String deptName; private String description; private Integer status; } // DepartmentMapper.java public interface DepartmentMapper extends BaseMapper<Department> { } // DepartmentService.java public interface DepartmentService extends IService<Department> { } // DepartmentServiceImpl.java @Service public class DepartmentServiceImpl extends ServiceImpl<DepartmentMapper, Department> implements DepartmentService { } // DepartmentController.java @RestController @RequestMapping("/api/dept") public class DepartmentController { @Resource private DepartmentService departmentService; @GetMapping("/list") public Result<List<Department>> list() { List<Department> list = departmentService.list(); return Result.ok(list); } }

这段代码把四层各文件串起来了。Department 用 @TableName 指定表名，@TableId 声明主键。DepartmentMapper 继承 BaseMapper 后，单表查询方法全部免费获得，不需要写一行 SQL。ServiceImpl 继承 IService 的实现类，让 controller 可以直接调用 list() 方法拿到全表数据。

Result 是统一返回体，结构一般是 code、message、data 三个字段。毕业设计里手写一个五行的 Result 类就够了，不要在返回体上过度设计。@RequestMapping("/api/dept") 建议统一加 /api 前缀，后面做登录拦截时，可以按前缀快速放行部分接口。

启动工程访问 /api/dept/list 就能看到 JSON。如果返回 500，优先看控制台 SQL 日志：表名、字段名、驼峰映射对不对一眼就能定位。第一个接口跑通后，剩下的 doctor、schedule、registration 模块按同样套路扩展即可，论文第四章的代码截图也能直接取自这里。

4. 挂号到就诊的核心闭环：状态机、并发扣减与事务边界

4.1 预约挂号接口：为什么「先查再扣」会翻车

预约挂号的业务动作是：校验号源剩余数大于 0，扣减 remain_number，插入一条挂号单记录。很多初版实现写成「先 SELECT 再 UPDATE」，压测一上来就翻车：两个请求同时查到 remain_number=1，都判定可挂号，然后各自插入挂号单，号源被超卖。这就是并发场景下典型的读后写问题。

解决路径有几种，代表性的是悲观锁和乐观锁。悲观锁用 SELECT ... FOR UPDATE 把排班行锁住，事务结束后再释放，吞吐量低但实现简单；乐观锁在 UPDATE 时带上 version 条件，更新行数为 0 就重试。毕业设计这个量级，建议用乐观锁，代码量少，答辩时还能讲出「版本号冲突重试」的细节。

@Transactional(rollbackFor = Exception.class) public Long createRegistration(Long scheduleId, Long patientId) { // 1. 查询排班信息 Schedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null) { throw new BizException("排班不存在"); } if (schedule.getRemainNumber() <= 0) { throw new BizException("号源已满"); } // 2. 乐观锁扣减号源：仅当版本号匹配时更新成功 Schedule update = new Schedule(); update.setId(scheduleId); update.setRemainNumber(schedule.getRemainNumber() - 1); update.setVersion(schedule.getVersion() + 1); int rows = scheduleMapper.update(update, new LambdaUpdateWrapper<Schedule>() .eq(Schedule::getId, scheduleId) .eq(Schedule::getVersion, schedule.getVersion())); if (rows == 0) { throw new BizException("号源冲突，请重试"); } // 3. 插入挂号单 Registration reg = new Registration(); reg.setScheduleId(scheduleId); reg.setPatientId(patientId); reg.setStatus(0); registrationMapper.insert(reg); return reg.getId(); }

第 1 步先查出排班和当前版本号；第 2 步构造一个减 1 后的剩余数和自增版本号，用「主键 + 版本号」作为更新条件；rows 为 0 说明版本已被别人改过，直接抛业务异常。这样即使两个请求同时进来，数据库行锁也只会让其中一个 UPDATE 成功，另一个拿到行数为 0。

@Transactional 注解的 rollbackFor 要写成 Exception.class，因为 Spring 默认只对运行时异常回滚，业务异常如果不继承 RuntimeException，很容易出现「挂号单没插进去但号源已扣」的脏数据。LambdaUpdateWrapper 里的 eq 条件就是乐观锁的防线，不建议省略。

这里有一个事务边界的细节：整个方法都在一个事务里，第 2 步 UPDATE 成功后会持有该行锁直到事务提交，所以第 3 步插入挂号单失败时，号源扣减会一并回滚。如果你把扣号和插单拆成两个接口，就会出现号源没了、挂号单没生成的情况，这是最常见的错误。

4.2 取消挂号与状态机：三个状态和四个动作的约束

挂号单的状态不能只靠代码里 if 判断，必须由数据库字段约束兜底。前面建表时 status 定义了 0 待就诊、1 已完成、2 已取消、3 已爽约四个取值。围绕这个状态，系统里会发生四个动作：用户挂号把状态置为 0；用户取消把 0 改为 2；医生接诊把 0 改为 1；就诊时间过期未到把 0 改为 3。

@Transactional(rollbackFor = Exception.class) public void cancelRegistration(Long regId, Long patientId) { // 1. 条件更新：只有待就诊状态才允许取消 Registration update = new Registration(); update.setId(regId); update.setStatus(2); int rows = registrationMapper.update(update, new LambdaUpdateWrapper<Registration>() .eq(Registration::getId, regId) .eq(Registration::getPatientId, patientId) .eq(Registration::getStatus, 0)); if (rows == 0) { throw new BizException("当前状态不可取消"); } // 2. 回补号源 Registration reg = registrationMapper.selectById(regId); scheduleMapper.update(null, new LambdaUpdateWrapper<Schedule>() .eq(Schedule::getId, reg.getScheduleId()) .setSql("remain_number = remain_number + 1")); }

取消操作的核心是「条件更新」，把 status=0 作为 WHERE 条件之一。如果这个挂号单已经是已完成或爽约状态，更新行数为 0，直接抛异常。第二步回补号源前先查出 scheduleId，再用 setSql 做自增，避免并发回补时把别人的扣减覆盖掉。

setSql 是 MyBatis-Plus 里直接拼 SQL 片段的方式，这里写 remain_number = remain_number + 1，走的是数据库层面的自增，比「先查再加再更新」更安全。取消动作要在就诊时刻之前，这个校验我一般放在 service 层，用当前时间和排班的出诊日期、时段做比较。

状态机边界还要处理「爽约」场景。常见做法是一个定时任务每天扫描：把就诊日期早于今天、状态仍为 0 的挂号单批量改成 3。论文里描述这个任务时，一定要写清楚扫描条件和更新逻辑，否则答辩时被问「系统怎么知道患者没来」就答不上来。定时任务本身用 Spring 的 @Scheduled 就能实现，不需要引入额外组件。

4.3 医生接诊与处方开立：多表写入的顺序与回滚

接诊是第二个业务闭环的入口：患者按时到诊后，医生点击接诊，系统要同时做三件事——把挂号单改成已完成、创建病历记录、生成处方（含明细）。这三个动作跨三张表，必须用一个事务包住，任何一个失败都要整体回滚，否则会出现「病历建了但挂号单还是待就诊」的状态错乱。

@Transactional(rollbackFor = Exception.class) public Long startConsultation(ConsultationRequest req) { // 1. 条件更新挂号状态为已完成 Registration update = new Registration(); update.setId(req.getRegId()); update.setStatus(1); update.setVisitTime(LocalDateTime.now()); int rows = registrationMapper.update(update, new LambdaUpdateWrapper<Registration>() .eq(Registration::getId, req.getRegId()) .eq(Registration::getStatus, 0)); if (rows == 0) { throw new BizException("该挂号单不是待就诊状态"); } // 2. 新建病历 MedicalRecord record = new MedicalRecord(); record.setRegId(req.getRegId()); record.setPatientId(req.getPatientId()); record.setDoctorId(req.getDoctorId()); record.setChiefComplaint(req.getChiefComplaint()); record.setDiagnosis(req.getDiagnosis()); medicalRecordMapper.insert(record); // 3. 新建处方主表与明细 Prescription prescription = new Prescription(); prescription.setRecordId(record.getId()); prescription.setTotalAmount(calculateAmount(req.getItems())); prescriptionMapper.insert(prescription); for (PrescriptionItem item : req.getItems()) { Drug drug = drugMapper.selectById(item.getDrugId()); PrescriptionItem pi = new PrescriptionItem(); pi.setPrescriptionId(prescription.getId()); pi.setDrugId(drug.getId()); pi.setDrugName(drug.getName()); pi.setDrugPrice(drug.getPrice()); // 价格快照 pi.setCount(item.getCount()); prescriptionItemMapper.insert(pi); } return record.getId(); }

第 1 步仍然是条件更新，确保只有待就诊状态的挂号单能被接诊，重复点击接诊时第二次会因行数为 0 被拦截。第 2、3 步在同一个事务里依次插入病历、处方主表、处方明细，病历的自增 ID 作为处方主表的 recordId，形成父子关联。

明细里冗余了 drugName 和 drugPrice 两个快照字段，这一点在第二章建表时就强调过。calculateAmount 是按明细行价格乘数量累加，因为明细总价必须等于主表总金额，我会在插入明细后再做一次总额校验，对不上就抛异常，避免论文里的收费统计出现偏差。

接诊接口的写入顺序也有讲究：先改挂号状态，再建病历和处方。原因是状态更新带条件约束，一旦状态被并发修改，后面的病历和处方根本不该被创建；反过来先建病历再改状态，就会产生「病历已存在、挂号单没完成」的孤儿数据。顺序问题在论文第四章的时序图里要能体现出来，评委看时序图就能看出你对事务的理解。

5. 从启动到验收：医疗就诊平台的 6 条高频踩坑记录

下面这六条，是医疗就诊平台从启动到验收过程中最容易反复出现的坑。前四条和数据一致性有关，后两条是环境配置问题。每条我都按「现象 → 原因 → 解决」的顺序写，你可以直接照着排查。

5.1 排班查询总是少一天：MySQL 时区与 UTC 偏差

现象：医生在管理端录入明天的排班，前端查询里显示成了昨天的日期，整体往前挪了一天。

原因：MySQL 连接串缺 serverTimezone 参数时，驱动用 JVM 默认时区和数据库 UTC 时间换算，导致 DATE 类型在传输过程中被减了一天。这个问题第一次遇到会觉得是玄学，其实是时区换算规则没对齐。

解决：连接串统一加 serverTimezone=Asia/Shanghai，同时 application.yml 里 jackson.time-zone 设成 GMT+8。两个时区要一起对齐，只改一处仍可能偶发差 8 小时。改完重启后，再插入一条排班数据验证日期显示。

5.2 前端调不通接口：CORS 配置顺序不对

现象：前端 devServer 访问 /api/dept/list 报跨域错误，浏览器控制台提示 Access-Control-Allow-Origin 缺失。

原因：CORS 过滤器注册在了拦截器之后，请求先被业务拦截器拦截，响应头没来得及添加，前端拿到的是拦截器返回的错误而不是跨域头。

解决：单独写一个 CorsFilter 并标注 @Order(0)，或者直接在 WebMvcConfigurer 里实现 addCorsMappings。确保跨域处理优先级高于登录拦截器，再遇到跨域报错就先看过滤器顺序。

5.3 压测号源超卖：更新行数为 0 但没处理

现象：用并发工具同时发 5 个挂号请求，号源剩余数变成负数，挂号单多出 5 条。

原因：乐观锁 UPDATE 的返回行数为 0 时直接忽略了，没有抛异常或重试，等于锁形同虚设，代码里写着 version 校验实际没生效。

解决：UPDATE 后判断 rows == 0 就抛业务异常，提示「号源冲突，请重试」。如果希望体验更好，可以在 service 层做一次重试循环，最多重试 3 次后再失败。代码写法就是第四章第一节的完整实现。

5.4 重复点击生成两张挂号单：缺少幂等控制

现象：用户在提交挂号表单时双击按钮，数据库里出现同一个人对同一排班的两条待就诊记录。

原因：前端没有禁用按钮，后端也没有做重复校验，两次请求都通过了号源扣减。

解决：前端在提交中禁用按钮是第一步；后端在挂号接口里先查挂号单表是否存在 patient_id + schedule_id + status=0 的记录，命中就抛出「请勿重复挂号」。这个查询对 (patient_id, schedule_id, status) 加个唯一索引更保险，数据库层再兜一道。

5.5 中文入库变成问号：连接串缺字符集参数

现象：病历主诉里的中文存进 MySQL 后全部变成「???」，查询出来也是问号。

原因：数据库连接串没有指定 characterEncoding=utf8，客户端连接字符集和表字符集不一致，中文在传输过程中被转成了无法识别的字节。

解决：url 里补上 useUnicode=true&characterEncoding=utf8，同时确认表结构字符集是 utf8mb4。改完后之前已经写入的乱码数据需要删除重建，所以建库时就要把默认字符集设对，这个坑属于没有后悔药的类型。

5.6 时间字段返回变成数组：LocalDateTime 序列化缺配置

现象：前端拿到 LocalDateTime 类型的 createTime 时，解析出来的是一串数字数组，而不是 "2025-05-10 12:00:00"。

原因：Spring Boot 默认用 Jackson 序列化 LocalDateTime，没有配格式时输出的是阵列结构，前端不处理就显示异常。

解决：参考第三章 application.yml 里的 jackson date-format 配置，或者在实体字段上注解 @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。前端用字符串格式展示日期最简单，不要为了省配置让前端自己去拼格式。

6. 答辩前一天最该做的一项自查：用一份压测报告把「做了」讲成「做透了」

6.1 把压测结果写进论文：一张表加两句瓶颈分析

功能跑通只是起步，答辩现场评委最常问的一句话是「你这个系统能扛多少并发」。与其到时候支支吾吾，不如在答辩前一天用压测工具把核心接口的吞吐量测一遍，把报告整理进论文第四章末尾。常见做法是用 Jmeter 开一个线程组，并发数从 50 开始，对预约挂号、科室列表、医生排班三个接口各测一轮，导出聚合报告。

表中的数据是示例，实际数值以你自己机器跑出来的为准。拿到数据后，不要只贴截图，要写两三句瓶颈分析。比如：预约挂号接口的吞吐量低于查询接口，瓶颈集中在两条 SQL 的事务往返和乐观锁重试；优化方案是对挂号单表按 schedule_id 加索引，并把号源扣减从两步改为一条 UPDATE。这一段分析在答辩时非常好用，因为它能接住「你怎么证明它可靠」的追问。

如果时间充裕，我还会做一个调优对照组：记录加索引前后 /api/schedule/list 的响应时间，把那两组数字放成一张对比小表。这种「优化前 vs 优化后」的呈现方式，比任何功能截图都更能说明你理解系统的瓶颈在哪里。压测报告放到论文第四章和第五章之间，作为系统测试部分，既能填篇幅又经得起深挖。

我的习惯是功能联调全部结束、论文初稿写完之后，再花半个下午做这一轮压测，因为这时候代码不会再大改了，测出来的数据才是成品数据。压测记录保存成带日期的 CSV 文件，答辩前自己先看一遍错误率最高的接口，预演一下怎么回答。这个动作看起来小，但能让整个项目的完成度上一个台阶，希望帮到你。

本文还有配套的精品资源，点击获取