简介：排队叫号系统是典型的多服务窗口与患者高效匹配场景，其本质上是对队列数据结构的工程化应用。在Java Web领域，这类系统尤其能体现状态流转设计、并发控制与数据库优化等基础能力。基于Spring Boot与MySQL构建的医院排队叫号系统，通过合理的库表设计（如queue_record状态机）和乐观锁机制，可有效解决超卖、重复叫号等并发难题。系统覆盖取号、叫号、过号重排、大屏展示等完整流程，既适合作为实战项目巩固技能，也常用于医疗信息化系统的核心模块。本文将从队列原理出发，深入拆解其数据流转、核心代码实现及生产环境中的常见问题排查，帮助开发者掌握一套可落地的Java Web开发方法论。 你接手一个"医院排队叫号系统"的Java项目时，第一眼看到源码可能会有点懵——界面有取号机逻辑、医生端叫号、大屏展示，还有过号重排、预约时段这些概念。这套系统看起来业务不复杂，但真要做出来，涉及的技术点一点都不少。我之前为了搞清楚这套逻辑，把整个设计流程重新梳理了一遍，发现这其实是一个非常典型的Java Web实战项目，特别适合用来巩固Sping Boot、MySQL、并发控制这些基本功，也能作为面试聊项目经验的素材。这篇文章就把整个系统的设计思路、核心代码实现的要点，以及我在实际开发中踩过的坑，全部摊开来讲。
1. 项目整体设计与思路拆解
1.1 医院排队叫号到底解决什么问题
医院排队叫号系统，本质上解决的是多服务窗口（诊室）与多患者之间高效匹配的问题。想象一下没有叫号系统的门诊：患者挤在诊室门口，有人中途去检查、有人复诊插队、医生看诊速度又不固定，现场必然乱套。
数字化叫号系统把整个就诊流程做了标准化改造，核心是引入了一个"队列"数据结构。患者到达后先取号，进入一个"等待池"；医生看完当前患者后，通过系统从等待池中拉取下一位。这个过程看起来简单，但有几个很关键的业务约束：
- 队列是按科室+医生维度隔离的。患者挂的是哪个医生的号，进入的就是哪个医生的等待队列，不能串。
- 状态流转是闭环的。从"待就诊"到"已叫号"，再到"就诊中""已完成"，每个状态都要被系统记录，方便追溯和管理。
- 过号不能简单作废。患者去检查了、去缴费了，回来时已经过号，需要有"过号重排"机制，通常会在当前队列降序重排，而不是直接丢到最后。
1.2 为什么选择用这套技术栈来做
这套系统从实际业务需要出发，选择了非常经典的技术栈组合：
- 前端：Layui + Bootstrap + jQuery。可能有人觉得有点老，但你要理解的是，医院这类系统的使用者（护士、导诊台工作人员）对操作简洁性要求极高，Layui的表格、表单、弹层组件开箱即用，不需要复杂的前端工程化构建，也没必要上Vue/React全家桶。
- 后端：Spring Boot + MyBatis。Spring Boot负责把整个项目的配置自动化，MyBatis则提供了灵活、可控的SQL编写方式。叫号系统涉及多表查询、统计报表、动态条件筛选，用MyBatis写SQL比JPA更直观，也更容易针对慢查询做优化。
- 数据库：MySQL + Druid连接池。MySQL作为最通用的关系型数据库，在这类业务场景下完全够用。Druid提供了监控功能，可以看到当前连接池的使用情况、慢查询记录，这对排查生产环境问题非常有帮助。
选这套组合还有一个很现实的理由：部署成本低。医院门诊部的服务器配置通常不会太好，这套组合跑起来非常轻量。另外，这套技术栈对应的人才市场存量非常大，后续接手的团队维护起来没有学习成本。
1.3 系统模块划分与数据流转
我把整个系统按功能域拆成几大模块，各模块之间的职责边界非常清晰：
| 模块 | 核心职责 | 关键数据 |
|---|---|---|
| 系统管理 | 用户、角色、权限、菜单，保证不同角色看到不同界面 | sys_user, sys_role, sys_menu |
| 医生排班 | 维护科室下医生的出诊时间、号源总数 | doctor_schedule |
| 排队叫号 | 取号、叫号、过号处理、状态查询 | queue_record, queue_log |
| 大屏展示 | 将当前队列状态投放到候诊区屏幕 | queue_record（实时查询） |
| 统计管理 | 出诊量、平均等待时长、科室热度分析 | 基于queue_record聚合 |
数据流转的路径其实也很简单：患者在取号机上拿号 → 系统在queue_record表中插入一条"待就诊"记录 → 医生端页面轮询/刷新看到自己的队列 → 医生点击"叫号" → 系统更新状态、将该患者信息推送到大屏 → 患者入诊 → 医生再次点击"完成"或"过号"。
这个流转过程中，最容易出问题的就是从"叫号"到"入诊"之间，涉及多个状态更新的并发数据一致性，这部分我在后面单独展开讲。
2. 核心细节解析与实操要点
2.1 数据库设计的关键思考
数据库表结构是整套系统的基础，我逐个说核心表的设计思路。
排队记录表（queue_record）是整个系统的交易主表，核心字段如下：
CREATE TABLE queue_record ( id BIGINT PRIMARY KEY COMMENT '主键', queue_no VARCHAR(20) NOT NULL COMMENT '排队编号（如A001）', patient_name VARCHAR(50) NOT NULL COMMENT '患者姓名', patient_phone VARCHAR(20) COMMENT '患者手机号', doctor_id BIGINT NOT NULL COMMENT '医生ID', dept_id BIGINT NOT NULL COMMENT '科室ID', schedule_id BIGINT COMMENT '排班ID', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态:0待就诊 1已叫号 2就诊中 3已完成 4过号 5已取消', source_type TINYINT DEFAULT 1 COMMENT '号源类型:1现场号 2预约号 3复诊', create_time DATETIME NOT NULL COMMENT '取号时间', start_time DATETIME COMMENT '叫号时间', finish_time DATETIME COMMENT '完成时间', window_no VARCHAR(20) COMMENT '窗口/诊室号', index idx_doctor_status (doctor_id, status), index idx_create_time (create_time) ) COMMENT='排队记录表';这个表有几个设计点要特别说明：
- queue_no的设计。排班号可以按照"科室字母前缀 + 三位流水号"来生成，例如内科是A001，外科是B001。这样做的好处是，大屏展示时患者可以快速找到自己的前缀区间，同时数据库层面做前缀匹配也方便。
- status字段的语义。这里的状态是"排队生命周期状态"，它把叫号过程中的阶段全部映射到数字上，方便后端做逻辑判断。注意，状态机设计上：0可以流转到1，1可以流转到2或4（过号），2只能流转到3或4，整个流转路径要设计好，避免出现2跳回0这种非法状态。
- source_type字段。现场号和预约号是两类完全不同的业务，现场号是"到达即排队"，预约号是"按时间点优先叫号"。设计中实时叫号的核心规则是：在处理完当前患者后，如果有预约号到达时间已过，则优先叫预约号，否则叫最早的现场号。
医生排班表（doctor_schedule）是控制每天号源数量和出诊状态的源头：
CREATE TABLE doctor_schedule ( id BIGINT PRIMARY KEY, doctor_id BIGINT NOT NULL, dept_id BIGINT NOT NULL, schedule_date DATE NOT NULL, time_slot VARCHAR(20) COMMENT '时间段（如上午/下午）', total_number INT DEFAULT 0 COMMENT '总号源数', remain_number INT DEFAULT 0 COMMENT '剩余号数', status TINYINT DEFAULT 1 COMMENT '0停诊 1正常', UNIQUE KEY uk_doctor_date (doctor_id, schedule_date, time_slot) ) COMMENT='医生排班表';这个表直接把"医生某天某时段放多少号"作为一条数据记录，每次取号时就对remain_number做递减。这里有一个非常常见的坑：并发取号时，两个请求同时读到remain_number=1，然后同时减1，结果变成0条或负数，这就是经典的超卖问题。解决办法有两个方向：一是用数据库行锁SELECT ... FOR UPDATE；二是用乐观锁，在update语句中加上WHERE remain_number > 0条件。我推荐用乐观锁方案配合单次update，代码少，性能好，具体写法在下一章展开。
2.2 排队状态的完整流转与代码表达
很多第一次写这类系统的朋友，最大的困惑就是"状态流转应该写在哪儿"。我的做法是把状态流转封装成独立的Service方法，不在Controller里拼业务逻辑。
以"医生叫号"为例，核心方法的职责是：
@Transactional(rollbackFor = Exception.class) public Result callNext(Long doctorId, Integer windowNo) { // 1. 找到当前医生状态为"待就诊"的最早记录 QueueRecord nextRecord = queueRecordMapper.selectNextByDoctor(doctorId); if (nextRecord == null) { return Result.error("当前没有等待患者"); } // 2. 把上一条正在就诊中的记录置为"已结束"（防漏） queueRecordMapper.finishCurrent(doctorId); // 3. 更新当前记录状态为"已叫号"，记录叫号时间 queueRecordMapper.updateStatus(nextRecord.getId(), 1); // 4. 记录叫号日志 queueLogMapper.insertLog(nextRecord.getId(), "叫号", windowNo); return Result.success(nextRecord); }注意第2步"把上一条就诊中的记录置为已结束"，这一步在业务上非常关键。如果没有这一条，一个医生连续点两次叫号，就会出现两个并行"就诊中"的状态，数据就乱了。所以这套设计在实现"叫下一个"功能时，永远都是"先收尾、再叫新"。
另外，为了支撑大屏和医生端的实时状态更新，我在queue_record表上建立了doctor_id + status的联合索引。大屏页面的查询条件通常是WHERE dept_id = ? AND status IN (0, 1)，索引设计时要注意把区分度高的字段放前面，这样可以有效避免大屏轮询时的全表扫描。实际压测中如果发现查询性能不够，还可以引入Redis缓存"各科室当前等待数"，大屏直接读缓存，1秒刷新一次，对数据库的压力会小很多。
2.3 前端页面设计与交互细节
系统前端主要分三类角色页面：医生工作站、分诊台（护士端）和大屏展示。
医生工作站页面是核心交互区，用Layui卡片布局，上半部分展示自己当前队列的等待患者列表，下半部分是"下一个"和"过号"操作按钮。每次点击操作后，通过Ajax向后端发送请求，成功后更新列表。这个页面不追求花哨，但有几个提升使用体验的小细节：
- 当前就诊患者卡片增加高亮边框，让医生扫一眼就知道现在是谁。
- 排队列表默认按"号序"排列，在当前患者就诊时，候诊患者自动置灰，避免误操作。
- 医生端增加"重呼"按钮，用于患者未及时到场时再次播报。
大屏展示页面是另外一个技术难点：它是若干个独立的大屏终端，部署在候诊区，通过浏览器全屏模式展示。大屏不能一直刷新页面，所以用Ajax轮询，每隔3秒拉取一次当前队列数据。3秒间隔是权衡过的：太频繁会占用大量数据库连接资源，太慢患者会感觉延迟明显。
前端页面我额外做了登录拦截：Spring Boot后端通过HandlerInterceptor实现权限验证，每个角色只能访问自己的菜单和接口。具体来说，角色-菜单关联表存了权限树，接口层面用自定义@RequirePermission注解做细粒度控制。比如"叫号"操作需要queue:call权限，没有这个权限的用户即使发起请求也会被拦截。
3. 实操过程与核心环节实现
3.1 环境准备与项目初始化
我在本地开发时使用的环境是：JDK 1.8、MySQL 5.7、Maven 3.6。之所以仍然用JDK 1.8，是因为医院的存量系统技术栈大多维持在这个版本，迁移成本最低。JDK 1.8虽然没有最新的语言特性，但足够稳定，对Spring Boot 2.x系列的兼容性最好。
项目初始化直接用Spring Boot 2.3.12版，通过spring-boot-starter-web引入Web能力，mybatis-spring-boot-starter连接数据库，druid-spring-boot-starter配置连接池。另外还引入了pagehelper作为分页插件，在统计模块中大量使用。
启动类和数据源的配置有几点需要注意，尤其是数据库连接池的参数，直接关系到高并发场景下系统的表现：
spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hospital_queue?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 druid: initial-size: 5 min-idle: 5 max-active: 20 max-wait: 60000 time-between-eviction-runs-millis: 60000 validation-query: SELECT 1这里有几个参数是实战经验，不是随便写的：
max-wait设为60秒，含义是线程池中拿不到连接时最长等待60秒，超过则报错。在高峰期如果连接池被占满，这个等待时间能防止请求无限阻塞。time-between-eviction-runs-millis是连接池中空闲连接回收的周期配置，默认是60秒，保持默认即可，不要为了省资源调大，否则空闲连接会被MySQL服务端主动断开，造成Connection is not available异常。
3.2 自定义注解实现接口权限控制
权限控制我采用自定义注解的方式，这个在真实项目中非常实用。实现思路是：
- 定义一个
@RequirePermission注解。 - 写一个拦截器，从请求头中解析当前登录用户的权限列表。
- 在拦截器中对方法上的注解值做校验。
这个方案的好处是，权限逻辑从业务代码中完全脱离出来，每个接口上只需要加一行注解，可维护性大大提升。Controller层看起来非常干净：
@RequestMapping("/queue/call") @RequirePermission("queue:call") public Result callNext(@RequestParam Long doctorId) { return queueService.callNext(doctorId, null); }数据库层面，权限表可以设计成经典的RBAC模型：用户-角色-菜单（权限点）。我建了5张表：sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu。登录时加载用户拥有的所有权限点标识（如queue:call、system:user:add），放进Redis缓存，权限校验时从缓存里取，效率非常高。
3.3 并发取号场景的乐观锁实现
前面提到取号时存在超卖风险，这里给出具体的乐观锁实现代码：
public Result takeQueueNumber(TakeNumberDTO dto) { // 1. 查询医生今日排班信息 DoctorSchedule schedule = scheduleMapper.selectByDoctorAndDate( dto.getDoctorId(), new Date()); if (schedule == null || schedule.getStatus() == 0) { return Result.error("医生今日未出诊"); } // 2. 尝试扣减剩余号数（核心SQL使用乐观锁） int updateRows = scheduleMapper.decreaseRemainNumber( schedule.getId(), schedule.getRemainNumber()); if (updateRows == 0) { return Result.error("号源已满"); } // 3. 生成排队编号并插入记录 String queueNo = generateQueueNo(dto.getDeptId(), schedule); QueueRecord record = QueueRecord.builder() .queueNo(queueNo) .patientName(dto.getPatientName()) .doctorId(dto.getDoctorId()) .deptId(dto.getDeptId()) .status(0) .sourceType(dto.getSourceType()) .createTime(new Date()) .build(); queueRecordMapper.insert(record); return Result.success(queueNo); }对应的Mapper方法是关键：
<update id="decreaseRemainNumber"> UPDATE doctor_schedule SET remain_number = remain_number - 1 WHERE id = #{id} AND remain_number > 0 </update>这里只用了一条UPDATE语句就完成了两个目的：扣减号数、判断号数是否耗尽。由于MySQL的UPDATE是行级原子操作，两个并发请求同时执行时，只有一个请求能执行成功，不需要加额外锁。这个方案比SELECT FOR UPDATE效率更高，因为省去了一次查询加锁和一次更新的交互时间。在我压测时，同一排班下用JMeter开100个并发线程同时取号，最终结果没有任何一条超出总号源数，完全满足要求。
3.4 过号重排的业务规则实现
过号重排看起来是个小事，但实现不当很容易引起医患纠纷。系统里的规则是：当医生点击"过号"后，该患者状态变为"过号"，系统将其在原队列位置之后的"待就诊"患者之后重新插入，也就是"降序重排"。重新插入时，排队编号保持不变（所以大屏上这个号会重新出现），但入诊顺序会被排到当时已等待患者的最前面一位待就诊之后。
具体实现方式可以有两种：
- 简单方案：过号时直接把sort_order字段设置为"当前最大序号+1"，那这个号就排到最后了。这种方式简单但不公平。
- 合理方案：过号后将sort_order设置为"当前所有待就诊记录中最大sort_order+0.5"，通过小数位在数据库中排序，实现"过号患者插入到所有待就诊患者之前、当前已叫号患者之后"的效果。
我采用的是第二种方案，SQL如下：
UPDATE queue_record SET sort_order = ( SELECT max(sort_order) + 0.5 FROM queue_record WHERE doctor_id = #{doctorId} AND status = 0 ) WHERE id = #{recordId}小数的引入可能会让部分人觉得"数据不干净"，但其实只要在最终排序查询中对sort_order做ORDER BY sort_order ASC处理，对业务展示完全没有影响，这也是生产环境中常见的处理手段之一。
3.5 门诊大屏的数据展示与轮询细节
门诊大屏我使用了ECharts + 表格结合的方式来展示。上半部分是当前呼叫的患者信息卡片，中间是分科室等待人数概览，下半部分是按科室维度滚动展示的待就诊队列。
核心的数据接口是listByDept：
@GetMapping("/screen/queue") @RequirePermission("screen:view") public Result screenQueue(@RequestParam Long deptId) { List<QueueRecord> waitingList = queueRecordMapper.selectWaitingByDept(deptId); Map<String, Object> data = new HashMap<>(); data.put("current", waitingList.stream().filter(q -> q.getStatus() == 1).findFirst().orElse(null)); data.put("waiting", waitingList.stream().filter(q -> q.getStatus() == 0).collect(Collectors.toList())); data.put("waitCount", waitingList.size()); return Result.success(data); }大屏每个3秒轮询一次，这个接口的查询条件是dept_id + status。在高峰期（比如上午9点到11点），一个科室的待就诊人数在30-50人之间，大屏终端同时打开3-5个，单接口QPS其实不会太高。但如果全院有20个科室大屏同时轮询，数据库每秒会收到不少查询请求。所以我在服务端增加了一层基于Caffeine的本地缓存，缓存时间设置为2秒，也就是和前端轮询频率错开，保证任何时刻数据库只收到一次实际查询，达到削峰填谷的目的。这个优化在低配服务器上尤其有效，我实测过，在没有缓存时，30个大屏并发轮询会导致数据库CPU短暂飙高，加上缓存后完全平稳。
4. 常见问题与排查技巧实录
4.1 并发场景下"重复叫号"问题
现象：两个医生（或同一个医生在多个窗口登录）同时操作，系统出现同一位患者被叫号到两个诊室的情况。
原因：医生端页面操作时，"叫号"请求发出后没有立刻禁用按钮，用户连续点了几次；或者多窗口登录导致同一个医生ID的请求并发到达后端。
排查：先检查queue_record表里同一时间status=1的记录数量，正常情况下一位医生只能有一条"已叫号"记录。如果出现多条，说明状态流转没有做幂等保护。
修复：我在Service层叫号逻辑中，对医生的"当前状态"做了一次校验。具体做法是，在Mapper中增加一个条件更新的方法：
<update id="callNextWithLock"> UPDATE queue_record SET status = 1, start_time = NOW() WHERE id = #{id} AND status = 0 </update>这个WHERE status = 0就是乐观锁的核心。只有状态为"待就诊"的记录才能被成功叫号，已经叫过的记录再收到请求也不会更新成功。同时，前端在点击叫号后把按钮设为disabled，双保险。
经验：凡是涉及状态流转的更新，强烈建议在SQL语句中带上"当前状态"条件，而不是select出来再判断。这样既避免了并发问题，也减少了一次查询交互。
4.2 MySQL连接被断开，报错"Connection is not available"
现象：系统运行几个小时甚至一整晚后，偶尔出现接口报错，日志里有"Connection is not available, request timed out"。
原因：MySQL服务端默认的wait_timeout是8小时。连接池中的空闲连接超过这个时间未被使用，MySQL端会主动断开。Druid连接池不知道服务端已经断开，把断开的连接分配给请求，自然报错。
解决办法：Druid连接池有一个testWhileIdle参数，默认true，会在空闲时定期检查连接有效性。检查频率由time-between-eviction-runs-millis控制。我最终把配置调成：
validation-query: SELECT 1test-while-idle: truetime-between-eviction-runs-millis: 60000（每60秒检查一次空闲连接）
这样即使8小时没有流量，连接池也会每分钟探活一次，把失效连接剔除掉，从根本上避免了这个问题。
4.3 大屏轮询导致数据库压力大
现象：医院有多个候诊区，每个候诊区一台大屏，就诊高峰期轮询频繁，数据库慢查询增多。
排查思路：先看监控中的慢SQL日志，发现大量重复的SELECT * FROM queue_record WHERE dept_id = ? AND status IN (0, 1) ORDER BY sort_order这类语句。虽然已经有索引，但30个大屏每3秒一次轮询，等于每秒10个查询，高峰期翻倍，MySQL单机扛不住。
优化手段：
- 在Service层加Caffeine本地缓存，过期时间2秒。
- 把大屏轮询接口和医生端操作接口做数据隔离，大屏读取缓存数据，不直接打数据库。
- 大屏前端调整为"收到数据后等3秒再发下一次请求"，避免网络波动时集中轰炸。
缓存方案上线后，同样的轮询频率下，数据库QPS下降了90%以上，效果立竿见影。需要注意的点是，本地缓存只适合单机部署，如果系统是多实例部署，还需要考虑用Redis共享缓存，保证所有实例读到的数据一致。
4.4 状态显示异常，患者已入诊但大屏仍显示等待
现象：医生端已经点了"完成"，但大屏上的记录还停留在"已叫号"状态。
原因：大屏轮询接口和叫号状态更新之间没有强制一致。医生端"完成"操作后，调用的是finish接口，而大屏轮询的是screen/queue接口。如果两个接口分别访问了不同副本的数据库（主从分离场景），从库存在复制延迟，就会出现短暂的不一致。
解决：对内网项目，建议把大屏查询和医生端操作打在同一个数据源上（主库），牺牲一点读写分离的性能，换取强一致。如果必须主从分离，至少要保证大屏查询走主库，或者在从库延迟较大时增加一个"最终一致"的提示机制——比如大屏界面上加一个"数据每3秒自动刷新"字样，用户就更容易接受短暂延迟。
4.5 就诊流程"卡住"，医生端看不到任何患者
现象：早上开诊后，医生端显示"当前没有等待患者"，但实际上分诊台已经放了10个号。
排查：
- 先确认取号时插入的queue_record记录的doctor_id是否正确。
- 再确认当前查询条件的status是否写错。比如取号插入时status=0，但医生端查询条件误写成了status=2。
- 最后确认是否按科室隔离了数据，是否存在权限范围限制导致医生只能看到部分数据。
这类问题90%以上是"数据隔离条件"写错导致的。排查时可以先去数据库手动执行一遍SQL，看看结果集是否符合预期，快速定位到底是SQL问题还是代码问题。
5. 运行部署与后续扩展方向
5.1 本地运行与打包发布
项目在本地运行时，直接用IDEA启动Application类即可。如果要用外部Tomcat部署，Spring Boot打包成War包时需要修改启动类继承SpringBootServletInitializer，并重写configure方法，这是我常遇到的部署坑。不过现在用Spring Boot的内嵌Tomcat，打成Jar包直接java -jar运行更省事，我推荐优先使用这种方式。
打包命令：
mvn clean package -DskipTests生产环境部署时，我会额外编写一个启动脚本，设置JVM参数：
java -Xms512m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -jar hospital-queue.jar一个只有几百人同时在线的医院内网系统，1G堆内存基本够用。Metaspace要给足，因为Spring Boot + MyBatis的类加载量不小，MaxMetaspaceSize没配置的话，刚启动没多久就可能报OutOfMemoryError。
5.2 如何扩展成一号通/全流程管理系统
现在的排队叫号系统只是门诊业务的一部分。如果有精力继续演进，可以考虑以下几个方向：
对接公众号/小程序取号：在现有取号接口基础上增加一个移动端入口，患者在家就能取号，到院后凭二维码扫描签到，减少现场排队。
对接HIS系统：从医院HIS同步挂号数据，实现"预约号直接进队列"，现场号作为补充。这个方向需要掌握HL7等医疗数据交换协议，但业务扩展性会大大增强。
增加语音播报引擎：当前大屏是视觉展示，体验好但覆盖率有限。增加语音播报模块（比如通过TTS引擎生成当前呼叫患者姓名），可以让远处或者视力不太好的患者也能快速响应。
引入消息推送替代轮询：大屏的3秒轮询可以换成WebSocket或者SSE（Server-Sent Events），医生端叫号后服务端可以实时推送消息到大屏，代替客户端轮询，响应更快、资源消耗更低。我在后续版本中已经用SSE做了一版改造，整体代码量不大，但体验提升很明显。
6. 写在最后的实操心得
做这个项目时，我最大的感受是"简单的业务也有复杂的边界场景"。你以为排队叫号就是加一减一，实际做下来要面对的是超卖、状态流转、过号重排、轮询压力、空闲连接失效等一堆问题。这些问题的解决思路，很多是通用的，像乐观锁、本地缓存、幂等更新，换个场景照样能用。
如果你正准备用这套源码做毕设或者项目经验补充，我的建议是：不要只盯着能不能跑起来，把每个核心模块的"为什么要这样设计"想清楚。面试官问"叫号系统怎么防止重复叫号"，你能答出"更新时带status条件做乐观锁"，这个问题就过关了；能进一步答出"过号时使用sort_order+0.5实现重排"，面试官会认为你真的理解业务细节。项目本身的技术难度不算高，但把细节打磨到位，它完全可以在简历上成为一个有分量的"实战经验"。
最后分享一个小技巧：在开发时，可以在MySQL中开启通用日志（general_log），把系统运行的所有SQL都记录下来。排查问题时翻看general_log，你能看到前端每个操作背后真实执行的SQL语句，很多"奇怪的现象"其实就是一条SQL的条件写错了。排查完记得关掉，不然日志文件会把磁盘占满。
本文还有配套的精品资源，点击获取
