企业官网建设流程全解析

简介：这是一套基于Spring Boot开发的网吧管理系统完整源码，面向Java初学者、课程设计与毕业设计学生，解决中小型网吧日常运营中的会员管理、上/下机调度、商品销售、网管响应及设备监控等核心业务需求。资源包共425个文件，含115个Java后端逻辑类、45个Vue前端组件、21个JS交互脚本、15个XML配置与SQL脚本、以及SVG图标和JPG/PNG界面素材，结构清晰体现前后端分离架构；压缩包仅8.76MB，轻量易部署。已有144人学习下载，配套代码涵盖用户中心、电脑信息管理、呼叫网管、购买商品等全部功能模块，且包含.bat启动脚本、yml配置、SQL建表语句及多个.vue.bak备份文件，便于理解开发迭代过程与关键页面实现逻辑，适合快速掌握Spring Boot+Vue全栈开发实践。

1. 这不是个“写完就扔”的Demo，而是一套能真正在小网吧跑起来的SpringBoot管理系统

你搜“基于springboot的网吧管理系统源码”，刷出来的大多是GitHub上挂着的、连数据库脚本都没配全的半成品，或者某宝上卖9.9元、解压后报错一堆的“教学项目”。但真正开过网吧、管过几十台机器的人知道：一个能用的系统，核心从来不是“用了SpringBoot”这个标签，而是它能不能在凌晨三点网管睡着时，自动踢掉那个卡死的QQ游戏进程；能不能让收银员只点三下鼠标，就完成会员续费+机器释放+打印小票；能不能在断网两小时后，本地缓存的计费数据不丢一条。我去年帮朋友改造他家县城的“极速风暴”网吧（32台机器，日均客流180+），从零开始搭这套系统，前后迭代了7个大版本，踩过的坑比网管巡检走的步数还多。它用的是SpringBoot 3.2.4（JDK 17），没碰任何冷门中间件，所有依赖都选社区维护活跃、文档齐全的主流组件——MyBatis-Plus做数据层，Redis做会话与缓存，Thymeleaf做后台管理页（拒绝Vue打包部署的复杂性），前端用纯Bootstrap 5+原生JS（兼容IE11，因为老式收银机还在跑Win7）。这不是教你怎么写@RestController，而是告诉你：当一台机器蓝屏重启后，系统怎么在3秒内重新拉起计费服务；当家长来查孩子上网记录时，如何用一行SQL快速导出带时间戳和应用名称的明细；当老板想看“下午三点到五点哪个区域人最多”，报表模块怎么避免把MySQL拖垮。下面拆解的每个模块，都是从真实工单里长出来的——比如“计费引擎”那块，最初用定时任务每分钟扫一次在线状态，结果高峰期MySQL CPU飙到98%，后来改成Redis SortedSet+Lua脚本原子操作，现在32台机器并发计费，服务器负载常年低于0.3。关键词就三个：springboot、网吧管理系统、源码，但背后全是血泪换来的实操细节。

2. 系统设计思路：为什么放弃“高大上”，死磕“稳准快”

2.1 不做微服务，单体架构是小网吧的最优解

很多教程一上来就画个“用户服务+计费服务+设备服务”的微服务图，但现实是：县城网吧年营收不到80万，IT预算为零，唯一的技术人员是兼职网管。强行上SpringCloud，光是Nacos配置中心部署、服务注册发现调试、链路追踪埋点，就能耗掉网管一周时间。我们坚持单体架构，但做了关键分层：

• Controller层：只做参数校验和路由分发，禁止任何业务逻辑。比如/api/machine/release接口，Controller只检查machineId是否为空、是否为数字，然后直接调Service。
• Service层：按业务域切分，MachineService管机器状态（开机/关机/锁定），BillingService管计费（启动/暂停/结算），MemberService管会员（充值/扣费/等级）。每个Service方法加@Transactional，但绝不跨库操作——所有数据都在同一个MySQL实例里。
• Mapper层：用MyBatis-Plus的LambdaQueryWrapper，杜绝手写SQL拼接。比如查询“当前在线且未计费的机器”，代码是machineMapper.selectList(new LambdaQueryWrapper<Machine>().eq(Machine::getStatus, "ONLINE").eq(Machine::getBillingStatus, "IDLE"))，而不是"SELECT * FROM machine WHERE status='ONLINE' AND billing_status='IDLE'"——后者一旦字段名改了，编译期根本发现不了。

提示：别信“微服务解决一切”的鬼话。小规模系统上微服务，就像给自行车装涡轮增压——成本翻倍，可靠性归零。单体架构下，一个jar包丢进Linux服务器/opt/netbar目录，执行java -jar netbar-system.jar --spring.profiles.active=prod，5分钟搞定上线。这才是网吧需要的“快”。

2.2 计费引擎：用Redis替代数据库轮询，响应速度从秒级到毫秒级

早期版本用MySQL定时任务每10秒扫描machine表查在线状态，问题爆发在暑假高峰期：32台机器同时在线，MySQL慢查询日志里全是SELECT * FROM machine WHERE status='ONLINE'，CPU持续95%以上，导致续费请求超时。解决方案不是升级服务器，而是重构计费触发机制：

• 所有机器客户端（Windows服务）每5秒向Redis发送心跳：SET machine:001 "ONLINE|2024-06-15T23:59:59"，并设置过期时间30秒。
• BillingService不再轮询DB，而是监听Redis Key变化：用RedisMessageListenerContainer订阅__keyevent@0__:expired频道，当machine:001过期时，自动触发billingEngine.stopBilling("001")。
• 计费数据存在Redis Hash里：HSET billing:001 start_time "2024-06-15T23:00:00" total_seconds 3600，结算时用HGETALL读取，再用DEL billing:001清理。

实测效果：单次计费启动耗时从平均850ms降到23ms，MySQL负载下降70%。更重要的是，断网时机器客户端继续往本地Redis写心跳（我们用嵌入式Redis），网络恢复后同步到主Redis，计费数据零丢失。

2.3 安全底线：不用JWT，用Session+IP白名单防爆破

网上教程清一色教JWT，但网吧场景下JWT有致命缺陷：管理员密码输错10次，token还在有效期内，攻击者拿着旧token能继续调用/api/admin/delete。我们回归传统Session，但加了三层加固：

• 登录接口限流：用Guava RateLimiter，同一IP每分钟最多5次登录请求。代码就三行：

  @PostMapping("/login") public Result login(@RequestBody LoginDTO dto, HttpServletRequest request) { String ip = getClientIp(request); if (!rateLimiterMap.get(ip).tryAcquire()) { return Result.fail("请求过于频繁，请1分钟后重试"); } // ...后续逻辑 }

• Session绑定IP：登录成功后，把用户Session ID和客户端IP存入Redis，Key为session:abc123，Value为{"userId":1,"ip":"192.168.1.100"}。每次请求校验时，先从Cookie读Session ID，再查Redis里存的IP是否匹配当前请求IP。
• 关键操作二次验证：删除会员、修改费率等敏感操作，必须输入短信验证码。短信用阿里云API，但验证码不存DB，而是存在Redis里带过期时间：SET verify:138****1234 "8899" EX 300（5分钟过期）。

注意：别被“无状态”忽悠。网吧系统要的是可审计、可追溯、可拦截，不是技术炫技。Session方案下，管理员在后台点“踢出所有用户”，执行redis-cli KEYS "session:*" | xargs redis-cli DEL，3秒清空全部会话，比JWT黑名单方案简单粗暴有效。

3. 核心模块实现：从数据库建表到收银台一键结账

3.1 数据库设计：宁可多建一张表，也不让字段承担多重语义

MySQL用的是8.0.33，字符集utf8mb4，排序规则utf8mb4_0900_ai_ci。重点说三张核心表的设计逻辑：

• machine表（机器信息）：

  CREATE TABLE `machine` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `mac_address` varchar(17) NOT NULL COMMENT 'MAC地址，唯一索引', `ip_address` varchar(15) NOT NULL COMMENT 'IP地址，如192.168.1.101', `area` varchar(10) NOT NULL DEFAULT 'A区' COMMENT '所在区域，A区/B区/包间', `status` varchar(10) NOT NULL DEFAULT 'OFFLINE' COMMENT '状态：OFFLINE/ONLINE/LOCKED', `billing_status` varchar(10) NOT NULL DEFAULT 'IDLE' COMMENT '计费状态：IDLE/RUNNING/PAUSED', `last_heartbeat` datetime DEFAULT NULL COMMENT '最后心跳时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_mac` (`mac_address`), KEY `idx_area_status` (`area`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  关键点：status和billing_status分开存。因为“机器开着但没计费”（比如网管调试）和“机器关机但计费未结算”（突然断电）是两种独立状态，混在一个字段里会导致查询逻辑爆炸。

• member表（会员信息）：

  CREATE TABLE `member` ( `id` bigint NOT NULL AUTO_INCREMENT, `phone` varchar(11) NOT NULL COMMENT '手机号，唯一', `real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名，用于实名制', `balance` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '余额，单位元', `level` tinyint NOT NULL DEFAULT '1' COMMENT '等级：1普通/2VIP/3黄金', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  关键点：balance用decimal(10,2)，不是double。曾有网吧用double存余额，结算时出现0.1 + 0.2 = 0.30000000000000004，导致会员投诉“少扣了0.00000000000000004元”。decimal保证金融计算精度。

• billing_record表（计费记录）：

  CREATE TABLE `billing_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `machine_id` bigint NOT NULL COMMENT '机器ID', `member_id` bigint DEFAULT NULL COMMENT '会员ID，NULL为散客', `start_time` datetime NOT NULL COMMENT '开始时间', `end_time` datetime DEFAULT NULL COMMENT '结束时间，NULL表示进行中', `total_seconds` int DEFAULT '0' COMMENT '总秒数', `amount` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '金额', `status` varchar(10) NOT NULL DEFAULT 'RUNNING' COMMENT '状态：RUNNING/COMPLETED/CANCELLED', PRIMARY KEY (`id`), KEY `idx_machine_time` (`machine_id`,`start_time`), KEY `idx_member_time` (`member_id`,`start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  关键点：total_seconds冗余存储。虽然可以从end_time-start_time算出来，但高峰期每秒上百条计费记录插入，UNIX_TIMESTAMP(end_time)-UNIX_TIMESTAMP(start_time)在MySQL里是函数计算，索引失效。冗余字段让SELECT SUM(total_seconds) FROM billing_record WHERE member_id=123能走索引，查询速度从2.3秒降到0.015秒。

3.2 收银台功能：三步完成结账，代码不到20行

前台收银员最怕“点错按钮”。我们的结账流程极度简化：

1. 扫描机器二维码（或输入机器号）
2. 选择会员（支持手机号模糊搜索）
3. 点击“结账”按钮

后端BillingController代码：

@PostMapping("/checkout") public Result checkout(@RequestBody CheckoutDTO dto) { // 1. 校验机器是否在线且正在计费 Machine machine = machineService.getById(dto.getMachineId()); if (!"ONLINE".equals(machine.getStatus()) || !"RUNNING".equals(machine.getBillingStatus())) { return Result.fail("机器未开机或未计费"); } // 2. 调用计费引擎结算 BillingRecord record = billingService.settleBilling(dto.getMachineId(), dto.getMemberId()); // 3. 打印小票（调用本地打印机） printService.printReceipt(record); return Result.success(record); }

其中settleBilling方法核心逻辑：

public BillingRecord settleBilling(Long machineId, Long memberId) { // 从Redis读取计费数据 Map<String, String> billingData = redisTemplate.opsForHash() .entries("billing:" + machineId); long seconds = System.currentTimeMillis() - LocalDateTime.parse(billingData.get("start_time")).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli(); seconds /= 1000; // 转秒 // 计算金额：基础费率 + 区域加价 BigDecimal amount = calculateAmount(seconds, machineId); // 写入MySQL BillingRecord record = new BillingRecord(); record.setMachineId(machineId); record.setMemberId(memberId); record.setStartTime(LocalDateTime.parse(billingData.get("start_time"))); record.setEndTime(LocalDateTime.now()); record.setTotalSeconds((int) seconds); record.setAmount(amount); record.setStatus("COMPLETED"); billingRecordMapper.insert(record); // 清理Redis redisTemplate.delete("billing:" + machineId); return record; }

实操心得：收银台界面禁止任何“确认弹窗”。曾有版本加了“确定要结账吗？”，网管手滑连点两下，生成两条重复记录。现在规则是：点击即执行，失败才弹Toast提示。用户教育成本远低于开发成本。

3.3 后台管理：用Thymeleaf+AJAX实现零刷新报表

管理员要看“今日各区域收入”，传统做法是点菜单跳转新页面，但网吧老板常边看报表边接电话，页面刷新导致数据丢失。我们用Thymeleaf渲染骨架，数据用AJAX加载：

• HTML模板里只放容器：

  <div id="area-revenue-chart"> <canvas id="revenueChart"></canvas> </div>

• 页面加载完，自动执行JS：

  $(document).ready(function() { $.get('/api/report/areaRevenue?date=' + today, function(data) { new Chart(document.getElementById('revenueChart'), { type: 'bar', data: { labels: data.labels, datasets: [{ label: '收入(元)', data: data.values, backgroundColor: ['#FF6384', '#36A2EB', '#FFCE56'] }] } }); }); });

• 后端ReportController返回JSON：

  @GetMapping("/areaRevenue") @ResponseBody public Map<String, Object> areaRevenue(@RequestParam String date) { List<Object[]> results = reportService.getAreaRevenue(date); Map<String, Object> map = new HashMap<>(); map.put("labels", results.stream().map(r -> (String)r[0]).collect(Collectors.toList())); map.put("values", results.stream().map(r -> ((BigDecimal)r[1]).doubleValue()).collect(Collectors.toList())); return map; }

好处：报表模块完全独立，换ECharts或Chart.js只需改前端JS，后端代码零改动。我们甚至预留了/api/report/custom接口，支持老板自己写SQL填参数查数据——当然加了白名单校验，只允许SELECT开头的语句。

4. 部署与运维：Linux一键部署脚本，网管照着念就能操作

4.1 生产环境配置：application-prod.yml的12个关键参数

别信“配置全放yml里”的说法。我们把配置拆成三层：

• 基础配置（application.yml）：定义SpringBoot通用项

  spring: profiles: active: prod main: allow-circular-references: true logging: level: com.netbar: debug

• 生产配置（application-prod.yml）：数据库、Redis等敏感信息

  spring: datasource: url: jdbc:mysql://127.0.0.1:3306/netbar?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: netbar_user password: 'your_strong_password_here' # 单引号防特殊字符 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: 127.0.0.1 port: 6379 password: your_redis_password database: 0 timeout: 2000 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 开发时打开，生产注释掉

• 环境变量配置（.env文件）：JVM参数、文件路径等

  # JVM参数 JAVA_OPTS="-Xms512m -Xmx1024m -XX:+UseG1GC -Dfile.encoding=UTF-8" # 日志路径 LOG_PATH="/var/log/netbar" # 上传文件根目录 UPLOAD_ROOT="/opt/netbar/uploads"

注意：password字段必须用单引号包裹，否则#符号会被YAML解析器当成注释。曾有网吧因密码含#，导致连接MySQL失败，排查3小时才发现是YAML语法问题。

4.2 一键部署脚本：deploy.sh，网管复制粘贴即可运行

脚本内容精简到12行，去掉所有注释和空行：

#!/bin/bash mkdir -p /opt/netbar/{logs,uploads} cp netbar-system.jar /opt/netbar/ cp application-prod.yml /opt/netbar/ cp .env /opt/netbar/ cd /opt/netbar source .env nohup java $JAVA_OPTS -jar netbar-system.jar --spring.profiles.active=prod > logs/start.log 2>&1 & echo "系统已启动，日志查看：tail -f /opt/netbar/logs/start.log"

使用流程：

1. 网管用WinSCP把netbar-system.jar、application-prod.yml、.env三个文件传到服务器/tmp目录
2. 登录服务器，执行sudo bash /tmp/deploy.sh
3. 看到“系统已启动”提示，打开浏览器访问http://服务器IP:8080

脚本里nohup保证进程后台运行，2>&1把错误日志也重定向到start.log，方便排查。我们甚至写了restart.sh脚本，内容就一行：ps aux | grep netbar-system.jar | grep -v grep | awk '{print $2}' | xargs kill -9 && bash /opt/netbar/deploy.sh。

4.3 日常运维：三类日志定位90%的问题

系统上线后，问题80%来自三类日志：

• 应用日志（/var/log/netbar/app.log）：记录业务操作，如“会员123充值200元成功”、“机器001结算金额15.50元”。用Logback配置按天滚动，保留30天。
• MySQL慢查询日志：在my.cnf里开启：

  slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1

  每天用mysqldumpslow -s t -t 10 /var/log/mysql/slow.log看最慢的10条SQL，针对性优化索引。
• Nginx访问日志（如果前端用Nginx反代）：记录HTTP状态码。重点监控502（网关错误，通常是SpringBoot挂了）和401（未授权，可能是Session过期或IP被封）。

曾有个问题：网管反映“有时结账按钮点了没反应”。查Nginx日志发现大量502，再查应用日志，发现OutOfMemoryError。原因是-Xmx1024m不够，把JVM堆内存调到2G，问题消失。没有日志，这就是玄学问题。

5. 常见问题与排查技巧：网管亲测有效的17个解决方案

5.1 “机器列表不显示在线状态”——Redis连接池耗尽

现象：后台机器列表里所有机器状态都是“离线”，但实际机器开着。

排查步骤：

1. 查应用日志：grep "RedisConnectionFailureException" /var/log/netbar/app.log
2. 如果有，执行redis-cli info | grep "connected_clients"，看连接数是否接近maxclients（默认10000）
3. 检查代码：是否在循环里new RedisTemplate？正确做法是Spring容器管理单例Bean。

解决方案：

• 在application-prod.yml里加连接池配置：

  spring: redis: lettuce: pool: max-active: 20 max-idle: 10 min-idle: 2 max-wait: 5000

• 代码里禁止手动new RedisTemplate()，全部用@Autowired注入。

5.2 “会员充值后余额没变”——事务传播失效

现象：管理员在后台给会员充100元，操作成功提示，但查数据库余额仍是0。

根本原因：MemberService.recharge()方法被另一个Service调用，而调用方没加@Transactional，导致recharge方法的事务失效。

验证方法：

• 在recharge方法开头加日志：log.info("recharge transaction: {}", TransactionSynchronizationManager.isActualTransactionActive());
• 如果输出false，说明没事务。

修复方案：

• 方案1（推荐）：确保所有调用链路都有@Transactional，哪怕只是@Transactional(propagation = Propagation.SUPPORTS)
• 方案2：用TransactionTemplate手动控制：

  @Autowired private TransactionTemplate transactionTemplate; public void recharge(Long memberId, BigDecimal amount) { transactionTemplate.execute(status -> { memberMapper.updateBalance(memberId, amount); return null; }); }

5.3 “打印小票乱码”——Linux字体缺失

现象：收银台点击结账，小票打印出来全是方框。

原因：Linux服务器没装中文字体，Java用默认字体渲染中文时 fallback 到无字形字体。

解决步骤：

1. 上传字体文件（如simhei.ttf）到/usr/share/fonts/目录
2. 执行mkfontscale && mkfontdir刷新字体缓存
3. 在printService.printReceipt()里指定字体：

   Graphics2D g2d = graphics.create(); Font font = Font.createFont(Font.TRUETYPE_FONT, new File("/usr/share/fonts/simhei.ttf")); g2d.setFont(font.deriveFont(12f));

实操心得：别信“Linux自带中文字体”的说法。CentOS最小化安装默认只有DejaVu Sans，不支持中文。我们打包了一个fonts-install.sh脚本，网管执行就自动下载安装思源黑体。

5.4 “高峰期MySQL CPU 100%”——慢SQL没走索引

现象：下午两点到四点，MySQL CPU持续100%，show processlist看到大量Sending data状态。

定位方法：

1. 开启慢查询日志（前文已提）
2. 用pt-query-digest分析慢日志：

   pt-query-digest /var/log/mysql/slow.log | head -20

3. 找到最慢的SQL，如SELECT * FROM billing_record WHERE member_id=123 ORDER BY start_time DESC LIMIT 10

优化方案：

• 给billing_record表加复合索引：

  ALTER TABLE billing_record ADD INDEX idx_member_time (member_id, start_time);

• 把SELECT *改成SELECT id, start_time, amount，减少IO。

5.5 “断网后计费数据丢失”——Redis持久化配置错误

现象：网吧断网2小时，恢复后发现断网期间的计费记录全没了。

原因：Redis默认RDB持久化，save 900 1（900秒内1次修改才保存），断网期间没触发保存。

解决方案：

• 改用AOF持久化，在redis.conf里：

  appendonly yes appendfsync everysec # 每秒刷盘，平衡性能与安全

• 同时开启RDB作为备份：save 300 1（5分钟1次修改就保存）

这样即使Redis崩溃，最多丢失1秒数据，对网吧计费来说完全可接受。

6. 源码结构与扩展建议：从能用到好用的进阶路径

6.1 源码目录结构：按功能域组织，拒绝“controller/service/mapper”三层套娃

项目根目录结构：

netbar-system/ ├── pom.xml ├── src/ │ ├── main/ │ │ ├── java/com/netbar/ │ │ │ ├── NetbarApplication.java # 启动类 │ │ │ ├── config/ # 全局配置 │ │ │ │ ├── RedisConfig.java │ │ │ │ └── MyBatisPlusConfig.java │ │ │ ├── controller/ # 控制器 │ │ │ │ ├── MachineController.java │ │ │ │ └── BillingController.java │ │ │ ├── service/ # 业务服务 │ │ │ │ ├── impl/ │ │ │ │ │ ├── MachineServiceImpl.java │ │ │ │ │ └── BillingServiceImpl.java │ │ │ │ └── MachineService.java # 接口 │ │ │ ├── mapper/ # 数据映射 │ │ │ │ └── MachineMapper.java │ │ │ ├── entity/ # 实体类 │ │ │ │ └── Machine.java │ │ │ ├── dto/ # 数据传输对象 │ │ │ │ └── CheckoutDTO.java │ │ │ └── util/ # 工具类 │ │ │ └── PrintUtil.java │ │ └── resources/ │ │ ├── application.yml │ │ └── static/ # 前端静态资源 │ └── test/ # 测试 └── docs/ # 部署文档、数据库脚本 ├── db_init.sql └── deploy_guide.md

关键原则：按业务域分包，不是按技术层分包。比如MachineService和MachineMapper放在同个包里，而不是service.machine和mapper.machine分开。这样新人看代码，找Machine相关功能，只用进com.netbar.machine包，不用在七八个包里跳来跳去。

6.2 可扩展方向：三个低成本高价值的升级点

6.2.1 加人脸识别登录（硬件成本≈200元）

买个USB摄像头（罗技C270），用OpenCV Java版做人脸检测：

CascadeClassifier faceDetector = new CascadeClassifier("haarcascade_frontalface_default.xml"); Mat image = Imgcodecs.imread("photo.jpg"); MatOfRect faceDetections = new MatOfRect(); faceDetector.detectMultiScale(image, faceDetections); if (faceDetections.toArray().length > 0) { // 人脸检测成功，关联会员 }

对接现有会员系统，会员第一次刷脸绑定手机号，之后直接刷脸开机。硬件成本低，体验提升巨大，家长满意度直线上升。

6.2.2 接微信支付（官方SDK，3小时接入）

用微信支付V3版SDK，替换原有现金支付：

• 在BillingService.settleBilling()里，调用WechatPayClient.nativePay()生成支付链接
• 前端用window.open(paymentUrl)唤起微信
• 支付成功回调地址/api/wechat/notify，更新billing_record.status为PAID全程不用改数据库结构，只加3个新接口。

6.2.3 做机器健康监控（用Prometheus+Grafana）

在机器客户端加心跳上报：

// 每30秒上报一次CPU、内存、磁盘使用率 Map<String, Object> metrics = new HashMap<>(); metrics.put("cpu_usage", getCpuUsage()); metrics.put("mem_usage", getMemUsage()); restTemplate.postForObject("http://server:9090/metrics", metrics, Void.class);

Prometheus抓取数据，Grafana画图。网管一眼看出“007号机器CPU长期95%”，提前更换硬件，避免半夜蓝屏。

最后分享个小技巧：每次版本升级，我们都在docs/changelog.md里写清楚“本次更新解决了什么问题”。比如V2.3版本写：“修复机器001蓝屏后，计费状态未重置为IDLE的BUG”。这样网管一看就知道值不值得升级，而不是盲目执行git pull。系统不是越新越好，而是越稳越好。

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