Spring Boot实战：构建高并发网吧管理系统核心架构与源码解析-开发者社区

简介：这是一套基于Spring Boot开发的网吧管理系统完整源码，面向Java初学者、毕业设计学生及中小型网吧行业信息化改造需求者，解决传统网吧在会员管理、上/下机调度、商品销售、设备监控与网管响应等方面的数字化管理痛点。资源包共425个文件，涵盖115个核心Java后端逻辑、45个Vue前端页面组件、21个JS交互脚本、15个XML配置与SQL数据库脚本，辅以SVG图标、JPG/PNG界面素材及YML/BAT部署配置文件，结构清晰，前后端分离明确，压缩包仅8.76MB，轻量易导入。已有144人学习下载，适合用于课程设计实践、毕设快速原型搭建或二次开发参考。源码包含完整的用户权限体系（会员/网管）、实时电脑状态管理、购买与呼叫流程闭环、以及可扩展的商品类型与信息模块，配套.bat一键启停脚本与.bak备份文件，便于调试与版本回溯。

1. 项目概述：从零到一构建一个现代化的网吧管理系统

最近几年，虽然个人电脑和移动设备普及率很高，但网吧作为一个集社交、娱乐和特定工作环境于一体的场所，依然有其独特的市场需求。不过，现在的网吧早已不是当年那个靠几台电脑、一个计费软件就能运营的“黑网吧”了。一个现代化的网吧，本质上是一个小型的、提供IT服务的商业实体，其管理涉及会员、计费、商品、设备、安防、财务等多个复杂环节。手动记账、口头喊网管的日子一去不复返，一套稳定、高效、可扩展的管理系统成了标配。

今天要聊的，就是基于 Spring Boot 这样一个现代 Java 开发框架，来从零开始设计和实现一套网吧管理系统的核心思路与源码级解析。Spring Boot 以其“约定大于配置”的理念和强大的生态，能让我们快速搭建起一个健壮的后端服务，把精力集中在业务逻辑本身，而不是繁琐的框架配置上。这个系统不仅要能解决“开机-计费-下机”这个基本流程，更要能应对会员营销、商品库存、设备监控、数据报表等精细化运营需求。

如果你是一名有一定 Java 和 Spring Boot 基础的开发者，或者是对网吧、网咖这类实体门店的数字化管理感兴趣的技术负责人，那么这篇内容会带你走一遍从需求分析、技术选型、数据库设计到核心功能模块编码的完整过程。我会分享在实际编码中遇到的坑，以及如何用 Spring Boot 的特性优雅地避开它们，最终交付一个可运行、可二次开发的系统源码。

2. 系统核心需求与整体架构设计

在动手写代码之前，我们必须先把业务边界和核心功能定义清楚。一个网吧管理系统，其核心用户是前台收银员、网管（技术维护人员）和老板（管理者）。他们的需求各不相同，但都围绕着一个中心：高效、准确、透明地完成营业活动。

2.1 核心业务模块拆解

基于上述角色，我们可以将系统分解为以下几个核心模块：

会员管理模块：这是营收和客户粘性的核心。需要支持会员注册、充值、消费、积分、等级升降、挂失/解挂等功能。会员通常享受折扣，因此计费模块必须能根据会员身份动态计算费用。
上机计费模块：系统的“心脏”。它需要实时监听客户机的状态（开机、关机、锁定），根据预设的费率策略（如分区价格、会员折扣、时段优惠）进行计费，并精准地扣费或从押金中扣除。
商品零售模块：网吧的“第二营收曲线”。管理泡面、饮料、零食等商品的库存、进货、销售。需要与会员模块打通，支持会员积分兑换商品，或商品消费累积积分。
设备管理模块：对网吧内所有电脑（客户机）进行管理。包括机器编号、IP地址、所在区域、硬件配置、当前状态（空闲、使用中、故障、维护中）的维护。这个模块是计费模块的基础数据来源。
财务管理模块：为老板提供决策支持。需要生成日报、月报、年报，统计营收（上机收入、商品收入）、支出、会员充值情况、商品利润等。所有资金流水必须清晰可追溯。
系统管理模块：后台配置中枢。管理操作员（收银员、网管）的账号、权限、交接班；配置全局参数如费率策略、会员规则、系统开关等。

2.2 技术栈选型与架构图

明确了业务，接下来就是技术选型。为什么选择 Spring Boot？因为它能极大地简化 Spring 应用的初始搭建和开发过程。我们不需要再为复杂的 XML 配置和依赖冲突头疼，通过 Starter 依赖和自动配置，可以快速集成我们需要的各种组件。

后端框架：Spring Boot 2.x + Spring MVC + Spring Data JPA。JPA（这里选用 Hibernate 实现）能让我们用面向对象的方式操作数据库，减少手写 SQL 的繁琐和错误，对于业务逻辑复杂的系统非常友好。
数据库：MySQL 8.0。关系型数据库在事务一致性、复杂查询和报表生成方面有天然优势，适合网吧这种对账务准确性要求极高的场景。
缓存：Redis。用于存储用户登录会话（替代传统的 Session）、热点数据（如费率配置）、以及作为分布式锁的组件，应对高并发场景，比如多人同时开卡上机。
前端：考虑到开发效率和前后端分离的流行趋势，可以选择 Vue.js 或 React 构建管理后台。但为了项目完整性和快速演示，初期也可以使用 Thymeleaf 模板引擎开发一个简单的后台页面。这里我们讨论的核心是后端，前端仅作为接口消费者。
消息队列：RabbitMQ。这是一个可选项，但对于大型网吧或连锁店很有用。可以将“下机结算”、“商品出库”等耗时或需要保证最终一致性的操作异步化，提升系统响应速度和解耦模块。
监控与部署：Spring Boot Actuator 用于监控应用健康状态，最终通过 Docker 打包，部署到 Linux 服务器。

整体架构上，我们采用经典的分层架构：表现层（Controller）接收前端请求 -> 业务逻辑层（Service）处理核心业务 -> 数据访问层（Repository）操作数据库。同时，利用 Spring 的依赖注入（IoC）和面向切面编程（AOP）来管理事务、日志等横切关注点。

实操心得：在技术选型初期，切忌追求“最新最热”。Spring Boot 2.x 是一个长期支持且生态极其成熟的版本。对于数据库，除非有明确的超大规模数据需求，否则 MySQL 足以应对99%的网吧场景。先让核心业务跑起来，比纠结于技术栈的“时髦度”更重要。

3. 数据库设计与核心表结构解析

数据库是系统的基石，设计的好坏直接决定了后期开发的难度和系统的性能。我们遵循第三范式进行设计，但也会在必要时为了性能做适当的反范式化。

3.1 核心实体与关系

主要实体包括：会员(Member)、上机记录(OnlineRecord)、电脑(Computer)、商品(Product)、订单(Order)、操作员(Operator)。

它们之间的关系是：

一个会员可以有多个上机记录和多个订单（商品订单）。
一台电脑在不同时间可以被不同会员使用，产生多条上机记录。
一个订单可以包含多个商品（通过订单明细表关联）。
一个操作员可以创建多个上机记录和订单。

3.2 关键表结构设计示例

这里给出几个最关键的表结构设计，并解释字段设计的考量。

1. 会员表 (t_member)

CREATE TABLE `t_member` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `card_number` varchar(20) NOT NULL UNIQUE COMMENT '会员卡号', `name` varchar(50) DEFAULT NULL COMMENT '姓名', `phone` varchar(20) DEFAULT NULL UNIQUE COMMENT '手机号', `password` varchar(255) NOT NULL COMMENT '登录密码（加密存储）', `balance` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '账户余额', `integral` int(11) NOT NULL DEFAULT '0' COMMENT '积分', `member_level` tinyint(4) NOT NULL DEFAULT '1' COMMENT '会员等级（1-普通，2-白银，3-黄金...）', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态（1-正常，2-挂失，3-冻结）', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `last_recharge_time` datetime DEFAULT NULL COMMENT '最后充值时间', PRIMARY KEY (`id`), KEY `idx_card_number` (`card_number`), KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员表';

设计要点：card_number（卡号）和phone（手机号）都需要建唯一索引，作为登录和业务查询的关键字段。balance（余额）使用decimal类型，绝对避免使用float或double，防止金额计算出现精度丢失。status字段用于控制会员卡的业务状态流转。

2. 上机记录表 (t_online_record)

CREATE TABLE `t_online_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `member_id` bigint(20) DEFAULT NULL COMMENT '会员ID（非会员上机则为空）', `computer_id` bigint(20) NOT NULL COMMENT '电脑ID', `operator_id` bigint(20) NOT NULL COMMENT '操作员ID', `start_time` datetime NOT NULL COMMENT '上机时间', `end_time` datetime DEFAULT NULL COMMENT '下机时间', `duration` int(11) DEFAULT NULL COMMENT '上机时长（分钟）', `total_fee` decimal(10,2) DEFAULT NULL COMMENT '总费用', `pay_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '支付状态（0-未结算，1-已结算）', `payment_method` tinyint(4) DEFAULT NULL COMMENT '支付方式（1-余额，2-现金，3-扫码）', `remark` varchar(255) DEFAULT NULL COMMENT '备注', PRIMARY KEY (`id`), KEY `idx_member_id` (`member_id`), KEY `idx_computer_id` (`computer_id`), KEY `idx_start_time` (`start_time`), KEY `idx_pay_status` (`pay_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='上机记录表';

设计要点：这是系统的核心流水表，数据量会随时间快速增长。member_id允许为NULL，是为了支持临时顾客（非会员）上机。start_time和computer_id是高频查询条件（如查询某台机器的当前使用记录），必须建立索引。pay_status用于标识记录是否已结算，是财务对账的关键字段。duration和total_fee可以在下机时计算并更新，避免每次查询时实时计算，这是一种“用空间换时间”的优化。

3. 商品库存与订单表商品管理涉及t_product（商品信息）、t_stock（库存流水）、t_order（订单主表）、t_order_item（订单明细表）。这里重点讲一下库存扣减的设计。

-- 库存流水表 CREATE TABLE `t_stock` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_id` bigint(20) NOT NULL, `change_quantity` int(11) NOT NULL COMMENT '变动数量（正为入库，负为出库）', `current_quantity` int(11) NOT NULL COMMENT '变动后实时库存', `order_id` bigint(20) DEFAULT NULL COMMENT '关联订单ID', `type` tinyint(4) NOT NULL COMMENT '类型（1-采购入库，2-销售出库，3-盘盈盘亏）', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_product_id` (`product_id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

设计要点：绝不推荐直接在t_product表上用一个stock字段进行UPDATE stock = stock - 1。在高并发销售场景下，这会导致严重的超卖问题。正确的做法是使用库存流水表。每次库存变动都插入一条流水记录，current_quantity通过应用层逻辑或数据库触发器计算得出。查询实时库存时，可以缓存结果，或者通过SELECT current_quantity FROM t_stock WHERE product_id=? ORDER BY id DESC LIMIT 1来获取。结合乐观锁（在t_product表加一个version字段）或悲观锁（SELECT ... FOR UPDATE）可以完美解决并发问题。

踩坑记录：早期版本我曾直接在商品表上扣减库存，在促销活动时出现了库存扣成负数的情况。后来改为“流水表+乐观锁”的方案，虽然稍微复杂一点，但数据一致性得到了绝对保证。记住，涉及“钱”和“物”的数据，一致性永远是第一位的。

4. Spring Boot 后端核心功能实现详解

有了清晰的数据结构，我们就可以开始用 Spring Boot 搭建后端工程了。这里我使用 IDEA，基于 Spring Initializr 创建一个标准的 Spring Boot 项目，依赖选择：Spring Web,Spring Data JPA,MySQL Driver,Lombok（简化POJO类）。

4.1 实体类与Repository层

首先，根据数据库表设计 JPA 实体类。以Member实体为例：

@Entity @Table(name = "t_member") @Data // Lombok注解，自动生成getter/setter等 @NoArgsConstructor @AllArgsConstructor public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "card_number", unique = true, nullable = false, length = 20) private String cardNumber; @Column(name = "name", length = 50) private String name; @Column(name = "phone", unique = true, length = 20) private String phone; @Column(name = "password", nullable = false) private String password; // 存储BCrypt加密后的密文 @Column(name = "balance", precision = 10, scale = 2) private BigDecimal balance = BigDecimal.ZERO; @Column(name = "integral") private Integer integral = 0; @Column(name = "member_level") private Integer memberLevel = 1; @Column(name = "status") private Integer status = 1; // 使用枚举类型更佳 @Column(name = "create_time", updatable = false) @CreationTimestamp private LocalDateTime createTime; @Column(name = "last_recharge_time") private LocalDateTime lastRechargeTime; // 省略构造函数、getter/setter（由Lombok处理） }

对应的 Repository 接口非常简单：

@Repository public interface MemberRepository extends JpaRepository<Member, Long> { // 根据卡号查找 Optional<Member> findByCardNumber(String cardNumber); // 根据手机号查找 Optional<Member> findByPhone(String phone); // 查找状态正常的会员 List<Member> findByStatus(Integer status); }

JPA 的强大之处在于，你只需要定义接口和方法名（遵循特定规则），它就能自动实现查询逻辑，无需编写 SQL。

4.2 业务逻辑层：上机与计费的核心实现

这是整个系统最复杂的部分。核心流程是：选择电脑 -> 验证会员/收取押金 -> 开机（生成上机记录） -> 实时计费 -> 下机结算。

1. 费率策略设计费率不能硬编码，需要设计成可配置的。我们可以创建一个FeePolicy实体，包含字段：id,policyName,computerZone（机器区域），feePerHour（每小时单价），discount（折扣，如会员折扣），startHour,endHour（生效时段，用于实现分时段价格）。在服务层，根据上机时间、机器区域、会员等级动态匹配费率。

2. 上机服务实现

@Service @Transactional @Slf4j public class OnlineService { @Autowired private MemberRepository memberRepository; @Autowired private ComputerRepository computerRepository; @Autowired private OnlineRecordRepository recordRepository; @Autowired private FeePolicyRepository policyRepository; @Autowired private RedisTemplate<String, String> redisTemplate; // 用于分布式锁 public OnlineRecord startOnline(Long computerId, String cardNumber, BigDecimal deposit, Long operatorId) { // 1. 校验电脑状态 Computer computer = computerRepository.findById(computerId) .orElseThrow(() -> new BizException("电脑不存在")); if (!computer.getStatus().equals(ComputerStatus.IDLE.getCode())) { throw new BizException("该电脑当前不可用"); } // 2. 处理会员/非会员 Member member = null; if (StringUtils.hasText(cardNumber)) { member = memberRepository.findByCardNumber(cardNumber) .orElseThrow(() -> new BizException("会员卡号不存在")); if (!MemberStatus.NORMAL.getCode().equals(member.getStatus())) { throw new BizException("会员卡状态异常"); } // 会员使用余额，检查余额是否足够抵扣押金 if (member.getBalance().compareTo(deposit) < 0) { throw new BizException("会员余额不足"); } // 预扣押金（实际业务中可能只是冻结部分余额） member.setBalance(member.getBalance().subtract(deposit)); memberRepository.save(member); } else { // 非会员，押金为现金，记录在record的remark或单独字段中 } // 3. 使用Redis分布式锁，防止同一台机器被重复开机 String lockKey = "computer:lock:" + computerId; Boolean lockAcquired = redisTemplate.opsForValue().setIfAbsent(lockKey, "locked", 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(lockAcquired)) { throw new BizException("操作过于频繁，请稍后再试"); } try { // 4. 创建上机记录 OnlineRecord record = new OnlineRecord(); record.setComputerId(computerId); record.setMemberId(member != null ? member.getId() : null); record.setOperatorId(operatorId); record.setStartTime(LocalDateTime.now()); record.setPayStatus(PayStatus.UNPAID.getCode()); record.setDeposit(deposit); record = recordRepository.save(record); // 5. 更新电脑状态为使用中 computer.setStatus(ComputerStatus.IN_USE.getCode()); computer.setCurrentRecordId(record.getId()); // 关联当前上机记录ID computerRepository.save(computer); log.info("上机成功，记录ID：{}, 电脑：{}, 会员：{}", record.getId(), computerId, cardNumber); return record; } finally { // 释放锁 redisTemplate.delete(lockKey); } } }

关键点：@Transactional注解确保了步骤4和5在一个数据库事务中，要么都成功，要么都回滚，保证了“记录生成”和“电脑状态更新”的一致性。Redis分布式锁是防止高并发下同一台机器被两个请求同时开机的关键。锁的过期时间（如10秒）要设置合理，防止死锁。

3. 实时计费与自动下机计费不能只靠“下机时计算”，需要有一个后台任务，定期扫描所有pay_status=0（未结算）且end_time为NULL（未下机）的记录，根据当前时间更新费用。我们可以使用 Spring 的@Scheduled注解。

@Component @Slf4j public class FeeCalculateTask { @Autowired private OnlineRecordRepository recordRepository; @Autowired private FeeService feeService; // 每5分钟执行一次 @Scheduled(cron = "0 */5 * * * ?") public void calculateFeeForOnlineComputers() { List<OnlineRecord> unpaidRecords = recordRepository.findByPayStatusAndEndTimeIsNull(PayStatus.UNPAID.getCode()); for (OnlineRecord record : unpaidRecords) { try { // 计算从start_time到当前时间产生的费用 BigDecimal fee = feeService.calculateFee(record.getStartTime(), LocalDateTime.now(), record.getComputerId(), record.getMemberId()); // 更新记录的临时费用字段（非最终总费用） record.setTempFee(fee); recordRepository.save(record); log.debug("更新上机记录{}临时费用：{}", record.getId(), fee); } catch (Exception e) { log.error("计算记录{}费用失败：", record.getId(), e); } } } // 自动下机任务：检查余额不足或到达预定时间的会员 @Scheduled(fixedRate = 60000) // 每1分钟检查一次 public void autoLogoffTask() { // 1. 查找所有未结算的会员上机记录 // 2. 关联查询会员余额和预付押金 // 3. 如果（余额+押金） < 当前产生的临时费用 * 预警系数（如1.2），则调用下机服务 // 4. 或者，如果记录有预设的下机时间且已到达，也自动下机 } }

FeeService.calculateFee方法是计费核心，它需要根据上机时段、机器区域、会员等级去匹配对应的FeePolicy，进行分段计算和累加。这里逻辑较复杂，需要仔细处理时间段的交叉和费率优先级。

4.3 下机结算流程

下机结算是另一个关键事务，涉及费用最终计算、扣款、更新记录、释放电脑、退还押金（如有）等。

@Transactional(rollbackFor = Exception.class) public SettlementResult settle(Long recordId, Long operatorId) { OnlineRecord record = recordRepository.findById(recordId) .orElseThrow(() -> new BizException("上机记录不存在")); if (!PayStatus.UNPAID.getCode().equals(record.getPayStatus())) { throw new BizException("该记录已结算"); } // 1. 计算最终费用 LocalDateTime endTime = LocalDateTime.now(); BigDecimal finalFee = feeService.calculateFee(record.getStartTime(), endTime, record.getComputerId(), record.getMemberId()); // 2. 扣款逻辑 BigDecimal deposit = record.getDeposit(); BigDecimal amountPayable = finalFee; // 应付金额 SettlementResult result = new SettlementResult(); result.setFinalFee(finalFee); result.setDeposit(deposit); if (record.getMemberId() != null) { // 会员结算：从余额中扣除 Member member = memberRepository.findById(record.getMemberId()).orElseThrow(); BigDecimal balance = member.getBalance(); // 先使用押金抵扣 BigDecimal balanceToDeduct = amountPayable.subtract(deposit.compareTo(amountPayable) > 0 ? amountPayable : deposit); deposit = deposit.subtract(amountPayable.subtract(balanceToDeduct)); // 剩余押金 if (balanceToDeduct.compareTo(BigDecimal.ZERO) > 0) { if (balance.compareTo(balanceToDeduct) < 0) { throw new BizException("会员余额不足，请充值"); } member.setBalance(balance.subtract(balanceToDeduct)); } // 退还剩余押金到余额 if (deposit.compareTo(BigDecimal.ZERO) > 0) { member.setBalance(member.getBalance().add(deposit)); } memberRepository.save(member); result.setPaymentMethod(PaymentMethod.BALANCE); result.setChange(deposit); // 实际退还金额 } else { // 非会员结算：现金或扫码，记录支付方式即可，押金在开机时已收现金 result.setPaymentMethod(PaymentMethod.CASH); result.setChange(deposit.subtract(finalFee)); // 找零 } // 3. 更新上机记录 record.setEndTime(endTime); record.setDuration((int) ChronoUnit.MINUTES.between(record.getStartTime(), endTime)); record.setTotalFee(finalFee); record.setPayStatus(PayStatus.PAID.getCode()); record.setPaymentMethod(result.getPaymentMethod().getCode()); recordRepository.save(record); // 4. 释放电脑 Computer computer = computerRepository.findById(record.getComputerId()).orElseThrow(); computer.setStatus(ComputerStatus.IDLE.getCode()); computer.setCurrentRecordId(null); computerRepository.save(computer); // 5. 记录财务流水（略） // financeService.recordIncome(...); return result; }

注意事项：结算事务必须包含所有数据更新操作（会员余额、上机记录、电脑状态）。@Transactional保证了原子性。金额计算务必使用BigDecimal，并且设置正确的精度和舍入模式（如RoundingMode.HALF_UP四舍五入）。对于非会员的现金结算，change（找零）是给前台的提示，实际现金操作在线下完成。

5. 关键问题排查与性能优化实战

在实际开发和部署中，一定会遇到各种问题。这里分享几个典型场景及其解决方案。

5.1 并发操作导致的数据不一致

场景：高峰期，多个收银员同时为不同的顾客操作，涉及到同一张会员卡的余额并发修改（如同时充值、消费），或者同时操作同一台电脑。

解决方案：

数据库乐观锁：在Member表增加version字段。更新时带上版本号。

@Entity public class Member { // ... 其他字段 @Version private Integer version; }

在Service层更新余额时：

@Transactional public void recharge(Long memberId, BigDecimal amount) { Member member = memberRepository.findById(memberId).orElseThrow(); member.setBalance(member.getBalance().add(amount)); // JPA的save方法会在更新时自动检查version，如果不一致则抛出OptimisticLockException memberRepository.save(member); }

前端或调用方需要捕获这个异常，并提示用户“数据已被修改，请刷新重试”。

悲观锁或分布式锁：对于核心资源（如某台特定电脑的开机权），使用前面提到的Redis分布式锁。对于数据库行级锁，可以在Repository方法上使用@Lock(LockModeType.PESSIMISTIC_WRITE)，但要注意这可能影响性能并增加死锁风险。
业务逻辑降级：将一些实时性要求不高的操作异步化。例如，会员消费积分可以发送到消息队列（RabbitMQ），由消费者异步处理，避免直接竞争数据库资源。

5.2 计费不准或性能瓶颈

场景：网吧有200台机器，每5分钟扫描计算一次费用，如果每次都是全表扫描t_online_record并关联查询费率策略，数据库压力会很大。

优化方案：

缓存费率策略：费率策略变动不频繁，可以将其加载到Redis缓存中。FeeService计算费用时，优先从Redis获取，不存在再查库并回填缓存。
优化查询：为t_online_record表的pay_status和end_time字段建立联合索引idx_status_endtime。这样，定时任务查询WHERE pay_status=0 AND end_time IS NULL会非常快。

分批处理：如果记录数量巨大，定时任务不应一次性处理所有数据。可以使用分页查询，每次处理100-200条。

@Scheduled(cron = "0 */5 * * * ?") public void calculateFeeBatch() { int page = 0; int size = 100; Pageable pageable = PageRequest.of(page, size, Sort.by("id").ascending()); Page<OnlineRecord> recordPage; do { recordPage = recordRepository.findUnpaidRecords(pageable); // 自定义分页查询方法 List<OnlineRecord> records = recordPage.getContent(); // ... 处理本批记录 pageable = pageable.next(); } while (recordPage.hasNext()); }

5.3 客户端通信与状态同步

场景：管理系统如何知道客户机是开机还是关机？传统做法是在客户机安装“计费客户端”，客户端定时向服务端发送心跳。

实现思路：

在客户机端，开发一个轻量级程序（可以用C#、Electron等），开机自启动。
客户端启动后，向服务端的特定API（如/client/heartbeat）发送心跳，携带机器唯一标识（如MAC地址或IP）。
服务端提供一个ComputerService，接收心跳后，更新对应电脑的last_heartbeat_time。
服务端另一个定时任务（如每2分钟运行一次），扫描t_computer表，如果某台机器的last_heartbeat_time超过一定阈值（如3分钟），则将其状态标记为“离线”或“故障”。
当在管理端点击“开机”时，实际上是通过服务端向该机器的客户端发送一个指令（可以通过WebSocket、或客户端轮询服务端指令队列实现），客户端收到指令后执行解锁或启动计费程序的操作。

实操心得：客户端-服务端通信的稳定性是关键。心跳间隔和超时阈值需要根据网络环境调整。务必做好日志记录，当出现“机器显示使用中但实际空置”的bug时，通过查看心跳日志和指令日志能快速定位是网络问题、客户端崩溃还是服务端逻辑问题。

6. 安全、部署与扩展思考

一个可用的系统，还必须是一个安全的、易于部署的系统。

6.1 安全防护要点

认证与授权：使用 Spring Security 实现。操作员登录后颁发 JWT Token。根据角色（收银员、网管、老板）控制API访问权限。例如，只有老板才能查看财务报表接口。
密码安全：会员和操作员的密码必须加密存储。绝对禁止明文存储。使用 BCryptPasswordEncoder 进行哈希加密。
```
@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }
```
SQL注入与XSS：使用 JPA 的参数化查询可以避免绝大部分SQL注入。对于前端传入的富文本内容（如商品描述），要进行HTML转义或使用白名单过滤，防止XSS攻击。Spring Boot 默认集成了对常见Web攻击（如CSRF）的防护。
接口防刷：对于登录、充值等敏感接口，使用注解+Redis实现简单的限流。例如，同一IP一分钟内只能请求5次登录接口。
```
@RateLimit(key = "login:", limit = 5, period = 60) @PostMapping("/login") public Result login(@RequestBody LoginForm form) { ... }
```

6.2 项目部署与监控

配置分离：使用application.yml和application-prod.yml管理不同环境的配置（数据库地址、Redis地址、文件上传路径等）。通过启动参数--spring.profiles.active=prod激活生产环境配置。
日志管理：使用 Logback 或 Log4j2，配置合理的滚动策略和日志级别。将错误日志和业务关键日志单独输出到文件，便于排查问题。
健康检查：启用 Spring Boot Actuator，暴露/actuator/health端点，配合运维监控平台（如 Prometheus + Grafana）监控应用状态。

Docker 化部署：编写 Dockerfile，将应用打包成镜像。使用 docker-compose 编排应用、MySQL、Redis等服务，实现一键部署。

FROM openjdk:11-jre-slim VOLUME /tmp COPY target/netbar-management-system-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

6.3 未来扩展方向

当单店系统运行稳定后，可能会面临新的需求：

连锁店支持：需要在数据库设计中加入shop_id字段，所有业务数据都归属到具体门店。服务端需要根据登录操作员所属门店进行数据隔离。
小程序/APP端：为会员开发小程序，实现远程充值、查看余额、预约机器等功能。这需要将现有的后端API进行改造和扩展，提供一套面向移动端的RESTful API。
大数据分析：将业务数据同步到数据仓库（如ClickHouse），进行更复杂的经营分析，如用户上机时段偏好、热门商品关联推荐等。

开发这样一个系统，最大的收获不是学会了多少 Spring Boot 注解，而是对业务复杂性和数据一致性的深刻理解。从最初简单的“计时收费”想法，到后面要考虑会员折扣、商品库存、并发锁、财务对账等一系列问题，每一个细节都需要仔细推敲。代码的健壮性往往就体现在这些边界情况的处理上。建议大家在实现核心流程后，多花时间思考异常流程：网络断了怎么办？数据库连接超时怎么办？突然断电数据会不会错乱？把这些都想清楚了，你的系统才能真正扛得住实战考验。

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