简介本资源是一套基于Java技术栈的互联网医院系统源码采用Spring Boot框架与MySQL数据库构建面向具备一定Java Web基础、希望深入理解微服务架构与在线医疗业务开发的开发者。项目覆盖在线挂号、电子病历、在线问诊、处方开具、药品配送等核心医疗场景并涉及JPA与Hibernate数据持久化、Spring Security安全认证、前后端分离的RESTful API设计、日志记录与异常处理、JUnit单元测试以及Docker容器化部署等关键知识点可作为课程设计、毕业设计或技术进阶的完整参考方案。压缩包为zip格式整体约267.92MB目录结构清晰便于按模块检索学习。目前已有207人学习下载适合希望系统掌握Spring Boot企业级开发与互联网医疗业务逻辑的开发者对照研读与二次开发。1. 从一套互联网医院系统源码说起Java SpringBoot MySQL 原生 APP 到底能跑通什么一套互联网医院系统源码核心是把挂号、问诊、处方、订单这几条业务链在 Java SpringBoot MySQL 原生 APP 这套组合上跑通。很多人搜「互联网医院系统源码」其实心里想的是我能不能拿一套现成的后端加一个原生 APP把在线问诊这条链路真正落地而不是只跑个 Demo。这套技术栈的价值在于后端用 SpringBoot 把接口和业务分层做清楚MySQL 存患者、医生、订单、处方这些强关系数据原生 APP 负责把实时性和交互体验撑起来。适合谁适合手里有医疗信息化需求、想自己搭一套可维护系统的后端和移动端开发者也适合拿它当毕设或课程设计案例源码的进阶版本。但要注意医疗业务对数据一致性、状态流转、权限隔离的要求比普通电商高一个量级源码能跑起来和能上线是两回事下面按落地路径一层层拆。2. 技术选型与分层为什么是 SpringBoot MySQL 原生 APP 这套组合2.1 后端为什么选 SpringBoot 而不是传统 SSM互联网医院系统的接口数量不算特别多但状态流转复杂一个问诊单会经历待接诊、问诊中、已开方、待支付、已完成、已取消等多个状态每个状态变更都要落库、要校验权限、要触发通知。传统 SSM 要写大量 XML 配置改一个状态机就得动好几处。SpringBoot 的自动配置和 starter 机制能把数据源、事务、拦截器、参数校验这些基础能力快速装配起来让开发者把精力放在业务状态机上。我一般会这样分层controller 只做参数接收和返回封装service 承载状态流转和事务边界mapper 只做单表或简单关联查询复杂查询走 XML。这样做的直接好处是后面要加一个「复诊提醒」功能只需要在 service 层加一个定时任务调用已有查询不用动 controller 和 mapper。// 问诊单状态流转的核心 service 方法事务边界放在这里 Service public class ConsultationService { Autowired private ConsultationMapper consultationMapper; Autowired private PrescriptionService prescriptionService; // 医生接诊只有待接诊状态才能被接诊防止并发重复接诊 Transactional(rollbackFor Exception.class) public void acceptConsultation(Long consultationId, Long doctorId) { // 先查当前状态这里用行锁避免两个医生同时接同一单 Consultation c consultationMapper.selectForUpdate(consultationId); if (c null || !WAITING.equals(c.getStatus())) { throw new BizException(该问诊单已被接诊或已取消); } c.setStatus(IN_PROGRESS); c.setDoctorId(doctorId); c.setAcceptTime(new Date()); consultationMapper.updateById(c); } }这段代码的关键在selectForUpdate它对应 SQL 里的SELECT ... FOR UPDATE在 MySQL InnoDB 下会对这一行加排他锁。参数上要注意Transactional的rollbackFor必须显式写Exception.class否则遇到受检异常不会回滚这是血泪经验。状态判断放在锁之后保证并发下只有一个医生能接诊成功。2.2 MySQL 表结构怎么设计才扛得住问诊状态流转互联网医院系统的表不用多但几张核心表必须设计到位。患者表、医生表、科室表、问诊单表、处方表、订单表这六张是骨架。问诊单表是状态流转的中心字段设计直接决定后面查询和统计好不好做。表名关键字段说明consultationid, patient_id, doctor_id, dept_id, status, create_time, accept_time, finish_timestatus 用字符串枚举便于排查prescriptionid, consultation_id, drug_json, status, create_timedrug_json 存处方明细避免多表关联orderid, consultation_id, amount, pay_status, pay_time金额用 decimal(10,2)别用 floatstatus 字段我建议用字符串而不是数字比如WAITING、IN_PROGRESS、FINISHED。数字枚举在排查问题时需要对着文档翻译字符串一眼就能看懂代价只是多占几个字节。处方明细用 JSON 字段存是因为处方药品种类和数量不固定拆成子表会让查询变复杂而处方一旦开出基本不会单独查某一味药JSON 足够用。索引方面consultation表要在patient_id、doctor_id、status上建索引因为患者查自己的问诊记录、医生查待接诊列表、后台统计各状态数量这三类查询最频繁。注意不要给status单独建索引它的区分度低单独建索引效果差应该和doctor_id或create_time建联合索引。2.3 原生 APP 和 SpringBoot 的接口约定原生 APP 和后端的交互核心是接口协议要稳定。我一般会定一套统一返回结构code、message、data。code 用 0 表示成功非 0 表示业务异常HTTP 状态码统一 200避免 APP 端要同时处理 HTTP 状态和业务状态两套逻辑。{ code: 0, message: success, data: { consultationId: 1001, status: WAITING } }APP 端拿到code后判断是否成功失败时直接弹message。这里有个坑message不要直接暴露数据库错误信息比如「Duplicate entry for key」要统一转成「操作失败请稍后重试」否则既泄露表结构又让用户困惑。参数校验用 SpringBoot 的Valid加自定义注解在 controller 层拦截别等到 service 里再判空。3. 从零把后端跑起来建库、配置、启动的最小闭环3.1 MySQL 建库建表和连接池配置先把库建出来字符集用utf8mb4因为患者姓名和地址可能包含生僻字和 emoji。排序规则用utf8mb4_general_ci就够医疗系统不需要区分大小写排序。CREATE DATABASE internet_hospital DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE internet_hospital; CREATE TABLE consultation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, doctor_id BIGINT DEFAULT NULL, dept_id BIGINT NOT NULL, status VARCHAR(20) NOT NULL DEFAULT WAITING, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, accept_time DATETIME DEFAULT NULL, finish_time DATETIME DEFAULT NULL, INDEX idx_patient (patient_id), INDEX idx_doctor_status (doctor_id, status) ) ENGINEInnoDB;status默认值设成WAITING这样插入时不用显式传状态。create_time用CURRENT_TIMESTAMP默认值避免应用层忘记赋值。注意doctor_id允许为空因为患者提交问诊时还没分配医生。连接池用 HikariCPSpringBoot 默认就是它。配置里重点调三个参数maximum-pool-size设成 CPU 核数乘 2 再加磁盘数一般 10 到 20 够用connection-timeout设 3000 毫秒超过就快速失败而不是让请求堆积max-lifetime设 1800000 毫秒比 MySQL 的wait_timeout短一点避免拿到已被服务端关闭的连接。spring: datasource: url: jdbc:mysql://127.0.0.1:3306/internet_hospital?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 15 connection-timeout: 3000 max-lifetime: 1800000serverTimezone必须显式指定否则 MySQL 8 驱动会报时区错误。如果遇到error 2002 (hy000): cant connect to local mysql server through socket说明 MySQL 服务没启动或者 socket 路径不对先确认服务状态再查配置。3.2 SpringBoot 项目结构和启动类项目结构按功能分包不要按层分包。按层分包controller 一个包、service 一个包在项目变大后改一个功能要跳好几个包。按功能分包consultation 一个包、prescription 一个包更利于维护。SpringBootApplication MapperScan(com.hospital.**.mapper) public class HospitalApplication { public static void main(String[] args) { SpringApplication.run(HospitalApplication.class, args); } }MapperScan用通配符扫描所有模块下的 mapper这样新增模块不用改启动类。启动后先访问/actuator/health确认应用和数据库连接都正常再开始调业务接口。3.3 用 Postman 或 curl 验证问诊接口后端跑起来后先用 curl 验证核心接口别急着连 APP。# 创建问诊单 curl -X POST http://127.0.0.1:8080/api/consultation/create \ -H Content-Type: application/json \ -d {patientId:1,deptId:2,symptom:咳嗽三天} # 医生接诊 curl -X POST http://127.0.0.1:8080/api/consultation/accept \ -H Content-Type: application/json \ -d {consultationId:1001,doctorId:5}先创建再接诊观察返回的 status 是否从WAITING变成IN_PROGRESS。如果接诊返回「该问诊单已被接诊」说明状态判断生效了。这一步能跑通说明数据库、事务、接口协议这条链路是通的后面接 APP 只是换一个调用方。4. 原生 APP 对接与核心业务链路问诊、处方、订单怎么串4.1 问诊链路的接口时序和状态机问诊链路是患者提交问诊 → 医生接诊 → 医生开方 → 患者支付 → 问诊完成。每个状态变更都是一个独立接口APP 端按顺序调用。状态机要严格不能从WAITING直接跳到FINISHED。// 状态流转校验放在 service 层统一入口 private void checkTransition(String from, String to) { MapString, ListString allowed new HashMap(); allowed.put(WAITING, Arrays.asList(IN_PROGRESS, CANCELLED)); allowed.put(IN_PROGRESS, Arrays.asList(PRESCRIBED, CANCELLED)); allowed.put(PRESCRIBED, Arrays.asList(PAID, CANCELLED)); allowed.put(PAID, Arrays.asList(FINISHED)); if (!allowed.getOrDefault(from, Collections.emptyList()).contains(to)) { throw new BizException(非法的状态流转 from - to); } }把允许的流转关系集中在一个 map 里新增状态时只改这一处。参数上from是数据库当前状态to是目标状态任何不在允许列表里的组合都直接抛异常。这样即使 APP 端因为网络重试重复调用也不会把状态改乱。4.2 处方和订单的数据一致性怎么保证处方开出后生成订单这两个动作必须在一个事务里。如果处方写成功但订单写失败患者会看到处方却无法支付这是典型的翻车场景。Transactional(rollbackFor Exception.class) public void createPrescriptionAndOrder(Long consultationId, ListDrug drugs) { Prescription p new Prescription(); p.setConsultationId(consultationId); p.setDrugJson(JSON.toJSONString(drugs)); p.setStatus(CREATED); prescriptionMapper.insert(p); Order o new Order(); o.setConsultationId(consultationId); o.setAmount(calcAmount(drugs)); o.setPayStatus(UNPAID); orderMapper.insert(o); // 更新问诊单状态为已开方 consultationMapper.updateStatus(consultationId, PRESCRIBED); }三个写操作在同一个事务里任何一个失败全部回滚。calcAmount在应用层算金额不要用数据库触发器因为金额计算规则可能随业务调整放在代码里好改也好测。注意drugJson序列化时用JSON.toJSONString反序列化时用JSON.parseArray指定泛型否则会得到JSONObject而不是Drug。4.3 APP 端登录态和接口鉴权原生 APP 的登录态用 token后端用拦截器统一校验。token 里放 userId 和角色角色决定能访问哪些接口。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); if (token null || !jwtUtil.validate(token)) { response.setStatus(401); return false; } // 把用户信息放进 ThreadLocal供后续业务使用 UserContext.set(jwtUtil.parse(token)); return true; } }拦截器里只做 token 校验和用户信息注入具体权限判断放在 service 层因为同一个接口不同角色看到的数据范围不同。比如患者只能查自己的问诊单医生只能查自己接诊的这个过滤条件在 service 里拼到 SQL 的 where 里不要靠前端传参控制。5. 避坑与排查互联网医院系统源码落地时最容易翻车的几个点5.1 并发接诊导致一个问诊单被两个医生接走现象两个医生同时点接诊都提示成功数据库里 doctor_id 被后一个覆盖。原因先查状态再更新两步之间没有锁。解决用SELECT ... FOR UPDATE在事务里锁行或者用UPDATE consultation SET statusIN_PROGRESS, doctor_id? WHERE id? AND statusWAITING这种带条件的更新根据 affected rows 判断是否成功。后者更轻量推荐优先用。5.2 处方 JSON 字段反序列化报错现象从数据库读出 drug_json 后转成 List 报ClassCastException。原因JSON 库默认把对象转成JSONObject或LinkedHashMap没有指定目标类型。解决反序列化时显式传类型JSON.parseArray(json, Drug.class)别用JSON.parseObject再强转。5.3 连接池耗尽导致接口大面积超时现象压测时接口响应越来越慢最后全部超时。原因连接池最大连接数设太小或者有慢查询占着连接不放。解决先看慢查询日志把超过 1 秒的 SQL 优化掉再把maximum-pool-size适当调大但不要超过数据库max_connections的 80%。另外检查有没有在事务里调用远程接口那会把连接持有时间拉长。5.4 时区不一致导致问诊时间差 8 小时现象APP 显示的问诊时间和实际差 8 小时。原因MySQL 服务端时区、JDBC 连接时区、JVM 时区三者不一致。解决JDBC URL 里显式写serverTimezoneAsia/ShanghaiJVM 启动参数加-Duser.timezoneAsia/ShanghaiMySQL 配置文件里设default-time-zone08:00。三处统一后就不会再漂。5.5 接口返回敏感信息泄露表结构现象APP 端弹出「Duplicate entry 1001 for key PRIMARY」。原因全局异常处理直接把异常 message 返回了。解决在全局异常处理器里区分业务异常和系统异常业务异常返回自定义提示系统异常统一返回「操作失败请稍后重试」同时把原始异常打到日志里。这样既保护了表结构又不影响排查。6. 进阶技巧用状态机 幂等设计让问诊链路真正可维护前面把链路跑通了但要让这套互联网医院系统源码经得起真实流量还得在状态机和幂等上再走一步。我一般会把状态流转从散落的 if-else 抽成一个独立的状态机组件每个状态和事件定义清楚这样新增一个「医生拒诊」事件时只加一条流转规则不用去翻 service 里所有判断。public enum ConsultationEvent { ACCEPT, PRESCRIBE, PAY, FINISH, CANCEL } // 状态机配置当前状态 事件 - 目标状态 MapString, MapConsultationEvent, String machine new HashMap(); machine.put(WAITING, Map.of( ConsultationEvent.ACCEPT, IN_PROGRESS, ConsultationEvent.CANCEL, CANCELLED )); machine.put(IN_PROGRESS, Map.of( ConsultationEvent.PRESCRIBE, PRESCRIBED, ConsultationEvent.CANCEL, CANCELLED ));用枚举定义事件用嵌套 map 定义流转好处是状态和事件的关系一目了然测试时也能直接遍历这个 map 生成用例。参数上machine.get(currentStatus)拿到当前状态允许的事件集合如果事件不在集合里就拒绝逻辑比一堆 if 清晰得多。幂等这块问诊创建和支付回调是两个重灾区。创建问诊时APP 可能因为网络超时重试导致同一患者同一科室短时间内生成多条问诊单。我的做法是在创建接口加一个客户端生成的requestId服务端用 Redis 做setnxkey 是consult:create:{patientId}:{requestId}过期时间设 5 分钟。第一次请求写入成功继续处理重复请求直接返回上一次的结果。支付回调同理用订单号做幂等键回调处理前先查订单状态已支付就直接返回成功不重复改状态。验证这套设计有没有生效我会写一个简单的并发测试用 JMeter 或自己写个多线程脚本同时发 20 个接诊请求看最终数据库里是不是只有一个医生接诊成功其余都返回业务异常。再模拟支付回调重复发送 5 次看订单状态和金额有没有被重复处理。这两个测试过了基本可以认为链路是稳的。最后说个我自己的习惯每次改状态机或加新接口先把状态流转图在纸上画一遍确认没有死状态和不可达状态再动手写代码。医疗系统的状态一旦乱掉排查起来比普通业务痛苦得多因为涉及处方和订单改数据要非常谨慎。希望帮到你。本文还有配套的精品资源点击获取 互联网医院系统源码落地：SpringBoot+MySQL+原生APP问诊链路实战
简介本资源是一套基于Java技术栈的互联网医院系统源码采用Spring Boot框架与MySQL数据库构建面向具备一定Java Web基础、希望深入理解微服务架构与在线医疗业务开发的开发者。项目覆盖在线挂号、电子病历、在线问诊、处方开具、药品配送等核心医疗场景并涉及JPA与Hibernate数据持久化、Spring Security安全认证、前后端分离的RESTful API设计、日志记录与异常处理、JUnit单元测试以及Docker容器化部署等关键知识点可作为课程设计、毕业设计或技术进阶的完整参考方案。压缩包为zip格式整体约267.92MB目录结构清晰便于按模块检索学习。目前已有207人学习下载适合希望系统掌握Spring Boot企业级开发与互联网医疗业务逻辑的开发者对照研读与二次开发。1. 从一套互联网医院系统源码说起Java SpringBoot MySQL 原生 APP 到底能跑通什么一套互联网医院系统源码核心是把挂号、问诊、处方、订单这几条业务链在 Java SpringBoot MySQL 原生 APP 这套组合上跑通。很多人搜「互联网医院系统源码」其实心里想的是我能不能拿一套现成的后端加一个原生 APP把在线问诊这条链路真正落地而不是只跑个 Demo。这套技术栈的价值在于后端用 SpringBoot 把接口和业务分层做清楚MySQL 存患者、医生、订单、处方这些强关系数据原生 APP 负责把实时性和交互体验撑起来。适合谁适合手里有医疗信息化需求、想自己搭一套可维护系统的后端和移动端开发者也适合拿它当毕设或课程设计案例源码的进阶版本。但要注意医疗业务对数据一致性、状态流转、权限隔离的要求比普通电商高一个量级源码能跑起来和能上线是两回事下面按落地路径一层层拆。2. 技术选型与分层为什么是 SpringBoot MySQL 原生 APP 这套组合2.1 后端为什么选 SpringBoot 而不是传统 SSM互联网医院系统的接口数量不算特别多但状态流转复杂一个问诊单会经历待接诊、问诊中、已开方、待支付、已完成、已取消等多个状态每个状态变更都要落库、要校验权限、要触发通知。传统 SSM 要写大量 XML 配置改一个状态机就得动好几处。SpringBoot 的自动配置和 starter 机制能把数据源、事务、拦截器、参数校验这些基础能力快速装配起来让开发者把精力放在业务状态机上。我一般会这样分层controller 只做参数接收和返回封装service 承载状态流转和事务边界mapper 只做单表或简单关联查询复杂查询走 XML。这样做的直接好处是后面要加一个「复诊提醒」功能只需要在 service 层加一个定时任务调用已有查询不用动 controller 和 mapper。// 问诊单状态流转的核心 service 方法事务边界放在这里 Service public class ConsultationService { Autowired private ConsultationMapper consultationMapper; Autowired private PrescriptionService prescriptionService; // 医生接诊只有待接诊状态才能被接诊防止并发重复接诊 Transactional(rollbackFor Exception.class) public void acceptConsultation(Long consultationId, Long doctorId) { // 先查当前状态这里用行锁避免两个医生同时接同一单 Consultation c consultationMapper.selectForUpdate(consultationId); if (c null || !WAITING.equals(c.getStatus())) { throw new BizException(该问诊单已被接诊或已取消); } c.setStatus(IN_PROGRESS); c.setDoctorId(doctorId); c.setAcceptTime(new Date()); consultationMapper.updateById(c); } }这段代码的关键在selectForUpdate它对应 SQL 里的SELECT ... FOR UPDATE在 MySQL InnoDB 下会对这一行加排他锁。参数上要注意Transactional的rollbackFor必须显式写Exception.class否则遇到受检异常不会回滚这是血泪经验。状态判断放在锁之后保证并发下只有一个医生能接诊成功。2.2 MySQL 表结构怎么设计才扛得住问诊状态流转互联网医院系统的表不用多但几张核心表必须设计到位。患者表、医生表、科室表、问诊单表、处方表、订单表这六张是骨架。问诊单表是状态流转的中心字段设计直接决定后面查询和统计好不好做。表名关键字段说明consultationid, patient_id, doctor_id, dept_id, status, create_time, accept_time, finish_timestatus 用字符串枚举便于排查prescriptionid, consultation_id, drug_json, status, create_timedrug_json 存处方明细避免多表关联orderid, consultation_id, amount, pay_status, pay_time金额用 decimal(10,2)别用 floatstatus 字段我建议用字符串而不是数字比如WAITING、IN_PROGRESS、FINISHED。数字枚举在排查问题时需要对着文档翻译字符串一眼就能看懂代价只是多占几个字节。处方明细用 JSON 字段存是因为处方药品种类和数量不固定拆成子表会让查询变复杂而处方一旦开出基本不会单独查某一味药JSON 足够用。索引方面consultation表要在patient_id、doctor_id、status上建索引因为患者查自己的问诊记录、医生查待接诊列表、后台统计各状态数量这三类查询最频繁。注意不要给status单独建索引它的区分度低单独建索引效果差应该和doctor_id或create_time建联合索引。2.3 原生 APP 和 SpringBoot 的接口约定原生 APP 和后端的交互核心是接口协议要稳定。我一般会定一套统一返回结构code、message、data。code 用 0 表示成功非 0 表示业务异常HTTP 状态码统一 200避免 APP 端要同时处理 HTTP 状态和业务状态两套逻辑。{ code: 0, message: success, data: { consultationId: 1001, status: WAITING } }APP 端拿到code后判断是否成功失败时直接弹message。这里有个坑message不要直接暴露数据库错误信息比如「Duplicate entry for key」要统一转成「操作失败请稍后重试」否则既泄露表结构又让用户困惑。参数校验用 SpringBoot 的Valid加自定义注解在 controller 层拦截别等到 service 里再判空。3. 从零把后端跑起来建库、配置、启动的最小闭环3.1 MySQL 建库建表和连接池配置先把库建出来字符集用utf8mb4因为患者姓名和地址可能包含生僻字和 emoji。排序规则用utf8mb4_general_ci就够医疗系统不需要区分大小写排序。CREATE DATABASE internet_hospital DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE internet_hospital; CREATE TABLE consultation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, doctor_id BIGINT DEFAULT NULL, dept_id BIGINT NOT NULL, status VARCHAR(20) NOT NULL DEFAULT WAITING, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, accept_time DATETIME DEFAULT NULL, finish_time DATETIME DEFAULT NULL, INDEX idx_patient (patient_id), INDEX idx_doctor_status (doctor_id, status) ) ENGINEInnoDB;status默认值设成WAITING这样插入时不用显式传状态。create_time用CURRENT_TIMESTAMP默认值避免应用层忘记赋值。注意doctor_id允许为空因为患者提交问诊时还没分配医生。连接池用 HikariCPSpringBoot 默认就是它。配置里重点调三个参数maximum-pool-size设成 CPU 核数乘 2 再加磁盘数一般 10 到 20 够用connection-timeout设 3000 毫秒超过就快速失败而不是让请求堆积max-lifetime设 1800000 毫秒比 MySQL 的wait_timeout短一点避免拿到已被服务端关闭的连接。spring: datasource: url: jdbc:mysql://127.0.0.1:3306/internet_hospital?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 15 connection-timeout: 3000 max-lifetime: 1800000serverTimezone必须显式指定否则 MySQL 8 驱动会报时区错误。如果遇到error 2002 (hy000): cant connect to local mysql server through socket说明 MySQL 服务没启动或者 socket 路径不对先确认服务状态再查配置。3.2 SpringBoot 项目结构和启动类项目结构按功能分包不要按层分包。按层分包controller 一个包、service 一个包在项目变大后改一个功能要跳好几个包。按功能分包consultation 一个包、prescription 一个包更利于维护。SpringBootApplication MapperScan(com.hospital.**.mapper) public class HospitalApplication { public static void main(String[] args) { SpringApplication.run(HospitalApplication.class, args); } }MapperScan用通配符扫描所有模块下的 mapper这样新增模块不用改启动类。启动后先访问/actuator/health确认应用和数据库连接都正常再开始调业务接口。3.3 用 Postman 或 curl 验证问诊接口后端跑起来后先用 curl 验证核心接口别急着连 APP。# 创建问诊单 curl -X POST http://127.0.0.1:8080/api/consultation/create \ -H Content-Type: application/json \ -d {patientId:1,deptId:2,symptom:咳嗽三天} # 医生接诊 curl -X POST http://127.0.0.1:8080/api/consultation/accept \ -H Content-Type: application/json \ -d {consultationId:1001,doctorId:5}先创建再接诊观察返回的 status 是否从WAITING变成IN_PROGRESS。如果接诊返回「该问诊单已被接诊」说明状态判断生效了。这一步能跑通说明数据库、事务、接口协议这条链路是通的后面接 APP 只是换一个调用方。4. 原生 APP 对接与核心业务链路问诊、处方、订单怎么串4.1 问诊链路的接口时序和状态机问诊链路是患者提交问诊 → 医生接诊 → 医生开方 → 患者支付 → 问诊完成。每个状态变更都是一个独立接口APP 端按顺序调用。状态机要严格不能从WAITING直接跳到FINISHED。// 状态流转校验放在 service 层统一入口 private void checkTransition(String from, String to) { MapString, ListString allowed new HashMap(); allowed.put(WAITING, Arrays.asList(IN_PROGRESS, CANCELLED)); allowed.put(IN_PROGRESS, Arrays.asList(PRESCRIBED, CANCELLED)); allowed.put(PRESCRIBED, Arrays.asList(PAID, CANCELLED)); allowed.put(PAID, Arrays.asList(FINISHED)); if (!allowed.getOrDefault(from, Collections.emptyList()).contains(to)) { throw new BizException(非法的状态流转 from - to); } }把允许的流转关系集中在一个 map 里新增状态时只改这一处。参数上from是数据库当前状态to是目标状态任何不在允许列表里的组合都直接抛异常。这样即使 APP 端因为网络重试重复调用也不会把状态改乱。4.2 处方和订单的数据一致性怎么保证处方开出后生成订单这两个动作必须在一个事务里。如果处方写成功但订单写失败患者会看到处方却无法支付这是典型的翻车场景。Transactional(rollbackFor Exception.class) public void createPrescriptionAndOrder(Long consultationId, ListDrug drugs) { Prescription p new Prescription(); p.setConsultationId(consultationId); p.setDrugJson(JSON.toJSONString(drugs)); p.setStatus(CREATED); prescriptionMapper.insert(p); Order o new Order(); o.setConsultationId(consultationId); o.setAmount(calcAmount(drugs)); o.setPayStatus(UNPAID); orderMapper.insert(o); // 更新问诊单状态为已开方 consultationMapper.updateStatus(consultationId, PRESCRIBED); }三个写操作在同一个事务里任何一个失败全部回滚。calcAmount在应用层算金额不要用数据库触发器因为金额计算规则可能随业务调整放在代码里好改也好测。注意drugJson序列化时用JSON.toJSONString反序列化时用JSON.parseArray指定泛型否则会得到JSONObject而不是Drug。4.3 APP 端登录态和接口鉴权原生 APP 的登录态用 token后端用拦截器统一校验。token 里放 userId 和角色角色决定能访问哪些接口。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(Authorization); if (token null || !jwtUtil.validate(token)) { response.setStatus(401); return false; } // 把用户信息放进 ThreadLocal供后续业务使用 UserContext.set(jwtUtil.parse(token)); return true; } }拦截器里只做 token 校验和用户信息注入具体权限判断放在 service 层因为同一个接口不同角色看到的数据范围不同。比如患者只能查自己的问诊单医生只能查自己接诊的这个过滤条件在 service 里拼到 SQL 的 where 里不要靠前端传参控制。5. 避坑与排查互联网医院系统源码落地时最容易翻车的几个点5.1 并发接诊导致一个问诊单被两个医生接走现象两个医生同时点接诊都提示成功数据库里 doctor_id 被后一个覆盖。原因先查状态再更新两步之间没有锁。解决用SELECT ... FOR UPDATE在事务里锁行或者用UPDATE consultation SET statusIN_PROGRESS, doctor_id? WHERE id? AND statusWAITING这种带条件的更新根据 affected rows 判断是否成功。后者更轻量推荐优先用。5.2 处方 JSON 字段反序列化报错现象从数据库读出 drug_json 后转成 List 报ClassCastException。原因JSON 库默认把对象转成JSONObject或LinkedHashMap没有指定目标类型。解决反序列化时显式传类型JSON.parseArray(json, Drug.class)别用JSON.parseObject再强转。5.3 连接池耗尽导致接口大面积超时现象压测时接口响应越来越慢最后全部超时。原因连接池最大连接数设太小或者有慢查询占着连接不放。解决先看慢查询日志把超过 1 秒的 SQL 优化掉再把maximum-pool-size适当调大但不要超过数据库max_connections的 80%。另外检查有没有在事务里调用远程接口那会把连接持有时间拉长。5.4 时区不一致导致问诊时间差 8 小时现象APP 显示的问诊时间和实际差 8 小时。原因MySQL 服务端时区、JDBC 连接时区、JVM 时区三者不一致。解决JDBC URL 里显式写serverTimezoneAsia/ShanghaiJVM 启动参数加-Duser.timezoneAsia/ShanghaiMySQL 配置文件里设default-time-zone08:00。三处统一后就不会再漂。5.5 接口返回敏感信息泄露表结构现象APP 端弹出「Duplicate entry 1001 for key PRIMARY」。原因全局异常处理直接把异常 message 返回了。解决在全局异常处理器里区分业务异常和系统异常业务异常返回自定义提示系统异常统一返回「操作失败请稍后重试」同时把原始异常打到日志里。这样既保护了表结构又不影响排查。6. 进阶技巧用状态机 幂等设计让问诊链路真正可维护前面把链路跑通了但要让这套互联网医院系统源码经得起真实流量还得在状态机和幂等上再走一步。我一般会把状态流转从散落的 if-else 抽成一个独立的状态机组件每个状态和事件定义清楚这样新增一个「医生拒诊」事件时只加一条流转规则不用去翻 service 里所有判断。public enum ConsultationEvent { ACCEPT, PRESCRIBE, PAY, FINISH, CANCEL } // 状态机配置当前状态 事件 - 目标状态 MapString, MapConsultationEvent, String machine new HashMap(); machine.put(WAITING, Map.of( ConsultationEvent.ACCEPT, IN_PROGRESS, ConsultationEvent.CANCEL, CANCELLED )); machine.put(IN_PROGRESS, Map.of( ConsultationEvent.PRESCRIBE, PRESCRIBED, ConsultationEvent.CANCEL, CANCELLED ));用枚举定义事件用嵌套 map 定义流转好处是状态和事件的关系一目了然测试时也能直接遍历这个 map 生成用例。参数上machine.get(currentStatus)拿到当前状态允许的事件集合如果事件不在集合里就拒绝逻辑比一堆 if 清晰得多。幂等这块问诊创建和支付回调是两个重灾区。创建问诊时APP 可能因为网络超时重试导致同一患者同一科室短时间内生成多条问诊单。我的做法是在创建接口加一个客户端生成的requestId服务端用 Redis 做setnxkey 是consult:create:{patientId}:{requestId}过期时间设 5 分钟。第一次请求写入成功继续处理重复请求直接返回上一次的结果。支付回调同理用订单号做幂等键回调处理前先查订单状态已支付就直接返回成功不重复改状态。验证这套设计有没有生效我会写一个简单的并发测试用 JMeter 或自己写个多线程脚本同时发 20 个接诊请求看最终数据库里是不是只有一个医生接诊成功其余都返回业务异常。再模拟支付回调重复发送 5 次看订单状态和金额有没有被重复处理。这两个测试过了基本可以认为链路是稳的。最后说个我自己的习惯每次改状态机或加新接口先把状态流转图在纸上画一遍确认没有死状态和不可达状态再动手写代码。医疗系统的状态一旦乱掉排查起来比普通业务痛苦得多因为涉及处方和订单改数据要非常谨慎。希望帮到你。本文还有配套的精品资源点击获取