简介：《金吧台台球管理系统V》下载包面向台球厅经营者、店长及门店信息化实施人员，针对会员等级与折扣、球桌在线预订、器材库存预警、收支报表核对、员工考勤绩效等日常运营环节，提供一套可直接部署的管理系统文件。压缩包共158个文件，约60.04MB，以60个dll组件库和10个exe可执行程序为主体，另含60个mp3语音提示、12个log运行日志及ini、dat、config等配置数据文件，并附带CHM格式系统说明书，便于理解模块结构与参数含义。目前已有1017人学习下载。读者可获得较完整的安装目录与依赖组件，用于本地搭建测试、功能体验和部署排错，也能借说明书与配置样例梳理会员、预订、库存、财务等业务流程，适合需要低成本落地台球厅信息化管理的读者参考。
1. 从晚上八点的收银台说起：金吧台台球管理系统到底在管什么
晚上八点，台球厅前台排起小队，收银员一手接预约电话、一手点鼠标开台，屏幕上十几张桌子的状态、计时、消费金额要同时看得见——金吧台台球管理系统这类软件就是在这种场景里干活的。它不是给球员用的记分工具，而是给老板和前台用的经营后台：开台计时、按桌型和时间段算钱、会员储值、饮料香烟出库、交班对账，全套动作在一台收银机上闭环。
适合谁？手里已经拿到这份源码、想二次开发或接手维护的开发者；也适合刚入行、想拿一个业务闭环完整的小系统练手的同学。它的技术门槛不算高，但业务规则特别碎，计费、会员、库存三块里任何一处算错，月底盘账就得熬夜。下面按「这套系统怎么搭起来 → 一条开台链路怎么跑 → 哪些地方最容易翻车 → 二次开发从哪下手」的顺序拆。
2. 技术形态与运行环境：WinForms 客户端加 SQL Server 这套组合怎么落地
台球厅的现场约束很硬：收银机就一台，断网也得能开台结账；要接 58mm 小票打印机、会员读卡器，不少店还要接灯控继电器板；老板隔三差五要导出营业报表。这几条加起来，基本把技术栈推向「桌面客户端 + 本地数据库」。Web 版也有，但下载包里如果是 .sln 解决方案，那大概率就是 C# WinForms 那一套，数据库配 SQL Server。
先别急着双击 exe。这类系统跑不起来，九成不是代码问题，而是环境、实例名、初始化脚本顺序三件事没对齐。这一章按「判断形态 → 认目录 → 配环境」推一遍。
2.1 先判断形态：从解决方案和引用关系反推架构
拿到包先看根目录有没有.sln。用 Visual Studio 打开后，别急着 F5，先看解决方案资源管理器里的项目数量和引用方向。典型的台球厅收银系统会分成客户端、领域逻辑、数据访问、设备对接、报表五块，引用方向是单向的：Client 依赖 Core 和 Data，Data 依赖 Core，Core 谁也不依赖。如果发现 Core 里using System.Windows.Forms，那说明计费逻辑和界面耦合了，后面想加自助开台或者做接口对接会很难受。
另一个快速判断点是数据库访问方式。搜一下SqlConnection、SqlCommand出现的位置：如果全挤在窗体代码的按钮事件里，这套代码属于「能跑但不好改」的类型；如果集中在一个Data项目、外面套了仓储接口，那维护成本会低很多。我一般会先翻一遍有没有DAL、BLL、Common这类命名，再看App.config里有没有连接串，五分钟就能对代码质量有个底。
技术栈上，这类项目常见的组合是 .NET Framework 4.7.2 或 4.8 + WinForms + ADO.NET + SQL Server 2012 以上。没有 ORM 很正常，这个体量的系统用原生 ADO.NET 反而省事，少一层映射就少一处排查点。打印模块通常用PrintDocument手绘小票，或者引用了某个报表控件；设备模块会用System.IO.Ports.SerialPort对接灯控板。这些引用在「引用」节点里一眼能看出来。
2.2 目录结构：按职责还原一份可读的工程布局
不同版本的文件夹命名会有出入，但职责划分大同小异。按项目引用关系反推，大致是下面这种布局：
BilliardsManager/ ├── BilliardsManager.sln ├── src/ │ ├── BLD.Manager.Client/ # WinForms 主程序：收银台、桌台图、结账窗 │ ├── BLD.Manager.Core/ # 领域逻辑：计费、会员、库存、交班 │ ├── BLD.Manager.Data/ # ADO.NET 数据访问、仓储实现、事务封装 │ ├── BLD.Manager.Device/ # 小票打印、灯控串口、读卡器 │ └── BLD.Manager.Report/ # 营业报表、交班单、导出 ├── db/ │ ├── 01_schema.sql # 建表脚本 │ ├── 02_initdata.sql # 桌台、计费方案、管理员账号等基础数据 │ └── upgrade/ # 版本升级补丁，按日期命名 ├── tools/ # 数据备份、串口调试小工具 └── docs/ # 部署说明、操作手册重点看两个地方。一是db/目录，建表脚本和初始化数据是否齐全，直接决定你能不能把系统跑起来；如果只有.bak备份文件没有脚本，就得先还原数据库再反向生成脚本。二是Core里计费和会员相关的类，这是整个系统真正的价值所在，界面可以重画，计费规则重写一遍成本极高。
upgrade/这个目录很多人会忽略。有它说明这套系统经历过至少一次线上版本迭代，里面的补丁脚本往往记录了字段变更和口径调整，比如「最低消费从按桌改为按人」「会员折扣改为只对台费生效」。翻这些脚本比读代码更快理解业务演进。
2.3 数据库初始化与连接配置：第一次跑起来要改的三个地方
环境准备按顺序来：装 .NET Framework 运行时（或者直接用 Visual Studio 打开编译）、装 SQL Server Express、还原或执行建表脚本、改连接串、编译运行。
连接串必须外置到App.config，不要写死在代码里。这是后面换机器、换实例名时唯一的救命绳：
<!-- App.config：把连接串放在这里，换机器只改这一处 --> <configuration> <connectionStrings> <add name="BilliardsDb" connectionString="Server=.\SQLEXPRESS;Database=BilliardsDb;User Id=sa;Password=YourPwd;Connect Timeout=15;" providerName="System.Data.SqlClient" /> </connectionStrings> </configuration>代码侧统一从一个入口取连接，避免几十个窗体各写一遍：
// Db.cs：全项目唯一的连接入口 public static class Db { private static readonly string ConnStr = ConfigurationManager.ConnectionStrings["BilliardsDb"].ConnectionString; // 每次调用返回新连接，由 using 负责释放 public static SqlConnection Open() { var conn = new SqlConnection(ConnStr); conn.Open(); return conn; } }需要改的三处：Server写成实际实例名（Express 版一般是.\SQLEXPRESS，命名实例要写机器名\实例名）；Database要和建库脚本里的库名一致；认证方式按现场来，sa只适合内网单机，正式部署建议建独立登录并只给这一个库的权限。另外记得在 SQL Server 配置管理器里把 TCP/IP 协议启用，否则本机连得上、局域网另一台收银机连不上，这种问题排查起来很耗时间。
初始化脚本的执行顺序不能颠倒：先01_schema.sql建表和约束，再02_initdata.sql灌桌台、计费方案、管理员账号。如果顺序反了，外键约束会直接报错。跑完之后用一条简单查询验证基础数据是否到位：
-- 验证桌台和计费方案是否初始化成功 SELECT t.TableNo, t.TableName, r.RateName, r.PricePerHour FROM TableInfo t LEFT JOIN RatePlan r ON r.RatePlanId = t.RatePlanId ORDER BY t.TableNo;如果RatePlan字段是 NULL，说明桌台和计费方案没关联上，开台时算出来的费用会是 0，这种账最难对。跑通这一步再谈功能，顺序别乱。
3. 核心链路拆解：一张球桌从开台到结账要经过哪些代码
整套系统里最不能出错的就是这条链路：开台 → 计时 → 加商品 → 结账 → 落账。它串起了桌台状态、计费规则、会员折扣、库存和报表，任何一环写歪，表现出来都是「钱不对」。这一章把数据模型、状态流转和计费函数拆开看。
3.1 数据模型：四张表撑起一条开台链路
桌台、会话、订单明细、支付流水，这四张表是主干。桌台表存静态信息，会话表存一次开台的完整生命周期，明细表挂商品和附加费，支付表记录钱怎么收的。很多简易版本会把明细直接塞进会话表的一个文本字段里，看着省事，后面做商品销量排行和库存对账就没法看了。
-- 桌台：静态信息，含所属计费方案 CREATE TABLE TableInfo ( TableId INT IDENTITY(1,1) PRIMARY KEY, TableNo VARCHAR(10) NOT NULL UNIQUE, -- 桌号，如 A01 TableName NVARCHAR(30) NOT NULL, -- 显示名，如 中式八球 1 号 TableTypeId INT NOT NULL, -- 桌型：中式八球/斯诺克/九球 RatePlanId INT NOT NULL, -- 关联计费方案 Status TINYINT NOT NULL DEFAULT 0 -- 0空闲 1使用中 2预约 3维修 ); -- 开台会话：一次开台一条记录，结账时回填金额和结束时间 CREATE TABLE TableSession ( SessionId BIGINT IDENTITY(1,1) PRIMARY KEY, TableId INT NOT NULL, MemberId INT NULL, -- 散客为 NULL OpenTime DATETIME NOT NULL, CloseTime DATETIME NULL, TableFee DECIMAL(10,2) NOT NULL DEFAULT 0, GoodsFee DECIMAL(10,2) NOT NULL DEFAULT 0, Discount DECIMAL(10,2) NOT NULL DEFAULT 0, TotalFee DECIMAL(10,2) NOT NULL DEFAULT 0, Status TINYINT NOT NULL DEFAULT 0 -- 0进行中 1已结账 2已撤销 );TableSession.Status和TableInfo.Status是两套状态，必须一起改。只改桌台状态不落会话，断电重启后桌子会「凭空在使用中」；只落会话不改桌台，前台看到的还是空闲桌，两桌客人被开到同一张台上。这两个字段的同步要放在同一个事务里，后面开台代码会体现。
OpenTime用数据库时间而不是客户端时间。收银机被手动改过系统时间的情况不算罕见，一改就是几小时的计费偏差，事后对账根本说不清。
3.2 开台与计时：状态流转和并发保护
开台这个动作看着简单，其实是整条链路并发风险最高的地方。两个收银员同时点同一张空闲桌，如果没有保护，会开出两条会话，最后两个人各自结一次账，钱收重了或者收漏了。
// 开台：条件更新 + 事务，防止同一张桌被开两次 public long OpenTable(int tableId, int? memberId) { using (var conn = Db.Open()) using (var tran = conn.BeginTransaction()) { // 关键：WHERE Status = 0，只有真正空闲的桌才更新成功 var affected = conn.ExecuteNonQuery(tran, "UPDATE TableInfo SET Status = 1 WHERE TableId = @id AND Status = 0", new { id = tableId }); if (affected == 0) throw new InvalidOperationException("该桌已被占用，请刷新后重试"); // 会话的开台时间取数据库时间，避免客户端时钟漂移 var sessionId = conn.ExecuteScalar<long>(tran, @"INSERT INTO TableSession(TableId, MemberId, OpenTime, Status) VALUES(@id, @mid, GETDATE(), 0); SELECT CAST(SCOPE_IDENTITY() AS BIGINT);", new { id = tableId, mid = memberId }); tran.Commit(); return sessionId; } }这段代码有两个要点。UPDATE ... WHERE Status = 0是乐观并发控制，靠数据库行锁保证只有一个请求能把状态从 0 改成 1，影响行数为 0 就直接失败，比先查后改安全得多。GETDATE()用数据库时间，客户端只负责发起动作。SCOPE_IDENTITY()取当前作用域的自增主键，不会串到别的会话。
桌台状态流转要把所有出口想全：正常结账回到空闲，撤单回到空闲，换桌是「旧桌置空闲 + 新桌置占用 + 会话改 TableId」，维修是人工置 3 且不允许开台。漏掉任何一个出口，桌子就会卡在某个状态里出不来，前台只能重启软件。
3.3 计费函数逐段拆：跨时段、最低消费、会员折扣
计费是整个系统最容易出分歧的地方，因为每家店的规则都不一样：白天一个价、晚上一个价、夜宵再一个价；有的按小时、有的按局；有最低消费；会员折扣只对台费生效还是对总额生效。函数要写得能改，不能把规则硬编码成一串 if。
// 台费计算：先拆时段，再算金额，最后套规则 public decimal CalcTableFee(TableSession s, DateTime endTime) { // 1. 实际时长向上取整到分钟，不足 1 分钟按 1 分钟 var totalMinutes = (int)Math.Ceiling((endTime - s.OpenTime).TotalMinutes); if (totalMinutes < 1) totalMinutes = 1; // 2. 按时段拆段，每段用自己的单价 decimal fee = 0m; foreach (var seg in SplitByRatePeriod(s.OpenTime, endTime)) { var pricePerHour = GetPricePerHour(s.TableId, seg.Start); fee += pricePerHour * seg.Minutes / 60m; } // 3. 最低消费兜底 var minCharge = GetMinCharge(s.TableId); if (fee < minCharge) fee = minCharge; // 4. 会员折扣只作用于台费 if (s.MemberId.HasValue) fee *= GetMemberDiscount(s.MemberId.Value); // 5. 抹零到角，避免出现分币 return Math.Round(fee, 1, MidpointRounding.AwayFromZero); }逐段说明。第一步用Math.Ceiling向上取整，是台球厅的通行做法，客人打了 61 分钟按 62 分钟算，和计程车逻辑类似；如果直接(int)截断，一小时零一分只算一小时，老板月底看流水会发现台费总是偏低。第二步SplitByRatePeriod把跨时段的会话切成几段，比如 21:50 开台、23:10 结账，要拆成 21:50–22:00 按白天价、22:00–23:10 按夜间价，跨段不拆直接按开台时的单价算，晚间高峰的账会少收一截。
第三步最低消费是争议最多的规则，有的店按桌收、有的店按人收，GetMinCharge里要能读到人数。第四步折扣只作用于台费，商品一般不参与打折，这个口径必须和老板确认清楚，改错了就是真金白银。第五步抹零到角，MidpointRounding.AwayFromZero保证 0.05 不会因为银行家舍入变成 0。
函数之外还要留一个「费用重算」入口。客人加了瓶水、换了桌、用了优惠券，账单都要重算，重算逻辑必须和结账走同一个函数，不能各写一份。两份计费代码是这类系统最常见的坏味道，改了一处忘另一处，线上就开始出现「同样打两小时，两张单金额不一样」的投诉。
4. 会员储值、商品库存与交班报表：三块最容易做成糊涂账的模块
台费算对了只是及格线。真正让老板睡不着的是会员卡里的余额、货架上的库存、交班时的现金，这三块对不上，损失是静默发生的，不会有人当场发现。这一章按「扣钱 → 扣货 → 对账」的顺序拆。
4.1 会员储值：一次扣款要写几张表，事务边界在哪
会员储值本质是一个小账本，余额字段只是缓存，真正的凭据是流水表。只改余额不写流水，出了问题查不到任何痕迹；只写流水不改余额，余额和流水对不上。正确做法是在同一个事务里做三件事：条件扣减余额、插入流水、回填订单的支付方式。
// 会员扣款：条件更新保证余额不会被扣成负数 public bool DeductBalance(int memberId, decimal amount, long sessionId, string remark) { using (var conn = Db.Open()) using (var tran = conn.BeginTransaction()) { // WHERE Balance >= @amt 是关键，影响行数为 0 说明余额不足 var affected = conn.ExecuteNonQuery(tran, @"UPDATE Member SET Balance = Balance - @amt WHERE MemberId = @mid AND Balance >= @amt", new { amt = amount, mid = memberId }); if (affected == 0) { tran.Rollback(); return false; } // 流水是唯一凭据，金额记负数表示支出 conn.ExecuteNonQuery(tran, @"INSERT INTO MemberFlow(MemberId, ChangeAmt, BalanceAfter, BizType, BizId, Remark, CreateTime) VALUES(@mid, -@amt, (SELECT Balance FROM Member WHERE MemberId = @mid), 2, @sid, @remark, GETDATE())", new { mid = memberId, amt = amount, sid = sessionId, remark = remark }); tran.Commit(); return true; } }WHERE Balance >= @amt这一句是血泪经验。很多人写成先SELECT Balance判断够不够，再UPDATE扣减，两个收银台同时扣同一张卡，中间那一瞬间就能把余额扣成负数。条件更新把判断和扣减压成一条原子语句，靠数据库的行锁兜底。
BalanceAfter用子查询在同一事务里取，保证流水里记的余额是扣完之后的真实值。如果先查余额再扣，并发下记进去的就是旧值，对账时按流水累加会得出一条永远对不上的曲线。
充值侧同理，充送活动（充 500 送 100）要拆成两条流水：一条本金、一条赠送。混在一起记，退款时算不清该退多少，这是后期纠纷的高发点。
4.2 商品与库存：为什么不能直接改库存字段
饮料香烟的库存比台费更容易烂。原因在于它有两个方向：卖出要减，进货要加，退货要再加回去。如果每次操作都直接UPDATE Goods SET Stock = Stock - 1，一个月后库存数字和实际货架必然对不上，而且查不出是哪一笔错了。
合格的做法是「库存字段 + 出入库流水」双写，任何变动都留一条记录：
-- 商品出库：先校验库存，再扣减，再写流水，三步一个事务 UPDATE Goods SET Stock = Stock - @qty WHERE GoodsId = @gid AND Stock >= @qty; INSERT INTO StockFlow(GoodsId, ChangeQty, BizType, BizId, CreateTime) VALUES(@gid, -@qty, 1, @sessionId, GETDATE()); -- BizType 1=销售 2=进货 3=退货Stock >= @qty同样是为了防止超卖。库存流水表的价值在盘点：实际货架数减去系统库存数，差额再去流水里按时间排序找，大概率能定位到某天某笔漏记或重复记。
商品定价和台费要分开管。台费打折、商品不打折是常见口径，但也有店做「满赠」或者「套餐价」，这些规则不要塞进计费函数，单独做一个促销计算层，改动时影响面可控。我见过把促销逻辑写进结账按钮事件里的版本，后来加一个「第二瓶半价」改了三天，还带出了别的 bug。
4.3 交班报表：对账口径要在写代码前定死
交班单是收银员和老板之间的凭证，口径必须先定：营业额是否含未结账的挂单、会员储值消费算不算现金收入、抹零金额记在哪个科目、退款是冲减当日还是单独列示。这些问题不提前定，代码写完再改就是推倒重来。
一个可用的交班汇总大致是这几组数：现金、微信、支付宝、会员储值各收了多少；台费收入、商品收入、其他收入分别是多少；开台数、客单价、抹零合计；本期充值、本期退款。口径上建议「会员储值消费」单独列，因为它没有现金流入，混进营业额会让老板误判当天流水。
-- 交班汇总：按支付方式分组，储值单列 SELECT PayType, COUNT(*) AS OrderCount, SUM(TotalFee) AS Amount, SUM(Discount) AS DiscountTotal FROM PayRecord WHERE CreateTime >= @shiftStart AND CreateTime < @shiftEnd AND Status = 1 GROUP BY PayType;@shiftStart和@shiftEnd从交班记录表里取，不要让收银员手输时间。手输就一定会有人输错，输错的那张交班单和前后班次全部重叠，月底汇总直接崩。班次时间在开班时就落库，交班时只读不改。
报表还有个隐性要求：能重算。同一段时间的报表，今天跑和明天跑结果必须一致。这就要求所有汇总都基于已落库的原始单据，不能依赖内存里的临时状态。有些版本为了快，报表直接读客户端缓存，软件一重启数字就变，这种设计在验收时一定要揪出来。
5. 上线排查：部署和运行阶段最常见的五类问题
代码能编译不代表能营业。台球厅的现场环境比办公室复杂：收银机可能是几年前的老机器、打印机是杂牌的、灯控板是淘宝买的、员工会随手改系统时间。下面五条是按现场频率排的，每条按「现象 → 原因 → 解决」写。
5.1 环境与部署：装完双击没反应、连不上数据库
现象：程序双击后一闪而过，或者弹出「连接数据库失败」，但 SQL Server 服务看着是启动的。
原因：一是缺少对应版本的 .NET Framework 运行时，WinForms 程序在没有运行时的机器上不会有友好提示；二是连接串里的实例名写错，Express 版默认是.\SQLEXPRESS而不是localhost；三是 TCP/IP 协议没启用，本机用共享内存能连、局域网另一台连不上。
解决：先在目标机装对应运行时，再在命令行用sqlcmd -S .\SQLEXPRESS -U sa -P 密码验证能不能连。能连但程序连不上，就去配置管理器启用 TCP/IP 并重启实例，检查防火墙有没有放行 1433。连接串统一放App.config，别在代码里散着写。
5.2 计费与状态：金额差几块、桌子卡在「使用中」
现象：客人结账时金额和手算差几块；或者某张桌明明没人，前台显示使用中，点结账提示「无进行中会话」。
原因：金额偏差多半是计时取整方式不一致，开台用截断、结账用四舍五入，跨时段没拆段也会差；状态卡死通常是开台或结账只更新了一张表，事务没包住，中途异常导致桌台状态和会话状态脱节。
解决：计费统一走一个函数，取整规则写死为向上取整到分钟，跨时段必须拆段。状态同步放进同一个事务，并在程序启动时加一段自检：扫描TableSession里状态为进行中、但TableInfo显示空闲的记录，以及反过来的情况，列出来人工确认后修正。这段自检代码上线后能省掉大量半夜电话。
5.3 数据一致性：会员余额被扣成负数
现象：两张卡同时结账，其中一张余额变成负数，或者流水累加和余额对不上。
原因：扣款用了「先查后改」，没有事务和条件更新；或者流水表插入失败但余额已经扣了，事务边界划错。
解决：改成UPDATE ... WHERE Balance >= @amt并判断影响行数，扣减、写流水、回填订单三件事放同一个事务。已经出现负数的手工冲正，同时补一条冲正流水，不要直接改余额字段，否则账永远对不平。
5.4 打印与硬件：小票乱码、走纸错位、灯控没反应
现象：小票打出来中文是乱码，或者每行被截断；开台后对应的台球灯不亮。
原因：小票机编码和代码里写的不一致，58mm 和 80mm 纸宽每行字符数不同，按 80mm 排的版打到 58mm 上就会折行错位；灯控没反应多半是串口号被占用、波特率不匹配，或者继电器板地址和配置对不上。
解决：打印前按纸宽算好每行字符数，中文按两个字符宽度计算，编码显式指定为打印机支持的字符集。灯控做一个独立的设备层，串口打开失败要捕获异常并降级为「不控制灯但业务继续」，不能因为灯不亮就让开台失败。串口号做成配置项，换机器不用改代码。
5.5 时间与口径：跨零点营业、报表数字天天变
现象：凌晨两点的单被算进第二天，日报表和老板手记的对不上；同一段时间的报表，今天查和昨天查金额不一样。
原因：营业日直接用了自然日00:00切分，而台球厅的营业日通常到凌晨两三点；报表依赖了未结账的挂单或者客户端缓存，数据源不稳定。
解决：加一个「营业日切换时间」配置，比如凌晨 5 点，所有按日汇总的查询都用这个偏移量换算，而不是直接用CONVERT(date, CreateTime)。报表只统计已结账单据，挂单单独一张表列示。改完之后拿三天的历史数据双跑对比，数字对上了再上线。
6. 二次开发：从改一个字段到接一套自助开台
拿到这套系统后真正的工作量在改造，不在跑通。改造前先划一条线：计费、会员扣款、库存扣减这三处是核心，尽量只扩展不改写；界面、报表、设备对接可以随便动，改坏了不影响钱。
小改动的典型是加字段。比如老板要按区域（大厅、包间、VIP）统计桌台利用率，就在TableInfo加AreaId，在桌台维护界面补一个下拉，报表按AreaId分组。这类改动涉及三处：建表脚本、实体类、界面绑定，改完记得同步到db/upgrade/下写一个补丁脚本，别只改开发库。
中改动是加业务流程。比如扫码自助开台：客人在桌上扫码，选时长、付押金，系统自动开台并亮灯。做法是在现有客户端旁边挂一个轻量 Web API，复用Core里的计费类，开台仍然走OpenTable那个条件更新方法，不要另写一套。客户端定时拉取或者用消息通知刷新桌台图。这里最容易犯的错是把计费逻辑在 API 里复制一遍，两边规则一有出入就是客诉。
改动的风险和验证方式，我整理成一张表：
| 改造点 | 涉及表/模块 | 主要风险 | 验证方式 |
|---|---|---|---|
| 桌台加区域字段 | TableInfo、桌台维护、报表 | 老数据 AreaId 为空导致分组缺失 | 补默认值后再上线，报表加「未分配」分组 |
| 分时段计费调整 | RatePlan、计费函数 | 跨时段边界单金额跳变 | 构造 21:55–22:05 的边界单，手算比对 |
| 自助开台接口 | Core、TableSession | 与前台并发开同一张桌 | 压测两张请求同时开一桌，只允许一单成功 |
| 灯控对接 | Device、串口配置 | 串口占用导致开台阻塞 | 拔掉串口线，验证业务是否仍能继续 |
| 会员充送拆分 | Member、MemberFlow | 退款金额算错 | 用测试卡跑一遍充 500 送 100 再退，核对流水 |
验证的核心思路是「双跑对账」：改造版和原版同时接一批测试数据，各自出账单和报表，逐单比对差异。差异清单比任何单元测试都直观，尤其是计费和会员这种规则密集的模块。
还有个小技巧：在结账前加一个「费用明细」弹窗，把时长、拆段、单价、折扣、最低消费逐项列出来。开发阶段这是最好的调试工具，上线后也成了收银员和客人解释账单的依据。这个弹窗我一般第一天就加上，比打断点快得多。
最后说个教训。早些年改一套类似的收银系统，为了赶时间直接在结账按钮里加了几行折扣代码，测试时只试了会员单，散客单没走。上线第二天散客结账全部报错，前台排了十几个人。从那以后我每次动结账相关的代码，都强制走一遍「散客、会员、跨时段、加商品、撤单」这五种单子的回归，一条不落，哪怕只改了一个字符。希望帮到你。
本文还有配套的精品资源，点击获取
