简介基于C#开发的理发会员管理系统面向计算机、软件工程及通信工程专业的课程设计或毕业设计实践涵盖会员信息管理、预约服务、消费记录、积分与权限控制等核心业务模块同时附有数据库设计文档适合用于理解桌面应用与数据表关系建模。压缩包共210个文件以100个C#源码、36个resx界面资源、36个resources编译资源为主并包含SQL数据库文件、项目解决方案、可执行程序及部分文档整体大小约2.63MB结构便于直接加载与二次开发。资源已有280人学习下载可从会员、预约、消费、报表等多条业务线了解完整的C#WinForms数据库开发流程项目保留了Git版本管理线索目录划分清晰适合作为课程设计参照模板或毕业设计基础框架对提升编程与软件工程实践能力有较高价值。1. 理发会员系统看着简单为什么一半人栽在数据库设计上拿到一个“基于C#的理发会员管理系统含数据库设计文档.zip”压缩包很多人的第一反应是解压、跑起来、看界面。接过几轮这类需求之后我的习惯正好反过来先翻开数据库设计文档把表结构和关系捋清楚再碰C#代码。原因很简单理发店的会员业务绕来绕去就三件事——开卡、充值、记账可这三件事背后藏着储值、次卡、积分三种完全不同的计费模型表格设计错了后面每一次消费结算都在填坑。这套系统适合三类人接私活想快速交付的开发者刚学完C#和数据库增删改查、想找综合案例练手的学生以及店里还在用Excel记会员余额的理发店老板。下面的内容按“数据模型 → C#实现 → 踩坑 → 上线加固”的顺序拆最后落到一个能直接抄走的小票打印排版技巧上。2. 先把数据库设计文档吃透六张表盘清储值、次卡与积分2.1 为什么先定数据模型而不是先画窗体理发店的会员结算看上去都是“刷卡扣钱”实际有三种模型互相交织。第一种是储值余额客户一次性充值几百块系统可能再送10块每次消费从余额里扣这是绝大多数店的标配。第二种是次卡花399元买“剪发10次”每次核销一次次数这种卡多半还有有效期而且一个会员可以同时持有“剪发10次”和“烫染5次”两张不同套餐是一对多的关系。第三种是积分消费1元积累1分积分可以抵现金或者换项目。错误做法是把这三个模型全塞进会员表里加几个列“凑合用”。这么干的项目我见过不止一个等做到消费结算时就乱了次卡和储值一起支付时先扣哪个积分兑换的次数去哪查月底对账完全对不上。常见做法是——六张表各管一摊会员主表只管余额和积分总额次卡单独建两张表套餐定义 会员持有的卡充值和消费各建一张流水表再加一张操作员表控制登录权限。流水表宁可多记也不要漏记因为余额和积分是可变状态而流水是不可变的事实。2.2 六张表的职责划分与建表脚本SQL Server在设计文档里首先要写清楚每张表的职责边界否则三个月后你自己都记不住某个字段是干嘛的。表名记录什么关键字段Member会员主档、余额、积分MemberNo, Balance, TotalPointsPackageProduct次卡套餐定义ProductName, TotalCount, SalePriceMemberPackage会员已购的次卡实例RemainCount, ExpireDateRechargeRecord充值流水Amount, GiveAmount, GivePointsConsumeRecord消费流水Amount, PayBalance, PayCash, PayCountSysUser操作员账号UserName, PasswordHash, Role按这套分工写出来的 SQL Server 建表脚本如下直接放进数据库设计文档里就可以当DDL用。CREATE TABLE SysUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(20) NOT NULL UNIQUE, PasswordHash NVARCHAR(64) NOT NULL, -- SHA256哈希不存明文 Role TINYINT NOT NULL DEFAULT 1, -- 1操作员 2管理员 IsEnabled BIT NOT NULL DEFAULT 1 ); CREATE TABLE Member ( MemberId INT IDENTITY(1,1) PRIMARY KEY, MemberNo NVARCHAR(20) NOT NULL UNIQUE, -- 卡号如2401010001 Name NVARCHAR(20) NOT NULL, Mobile NVARCHAR(11), Balance DECIMAL(10,2) NOT NULL DEFAULT 0, TotalPoints INT NOT NULL DEFAULT 0, OpenDate DATETIME NOT NULL DEFAULT GETDATE(), Status TINYINT NOT NULL DEFAULT 1 -- 1正常 0停用 ); CREATE TABLE PackageProduct ( ProductId INT IDENTITY(1,1) PRIMARY KEY, ProductName NVARCHAR(20) NOT NULL, TotalCount INT NOT NULL CHECK (TotalCount 0), SalePrice DECIMAL(10,2) NOT NULL, ValidMonths INT NOT NULL DEFAULT 6, IsEnabled BIT NOT NULL DEFAULT 1 ); CREATE TABLE MemberPackage ( MemberPackageId INT IDENTITY(1,1) PRIMARY KEY, MemberId INT NOT NULL REFERENCES Member(MemberId), ProductId INT NOT NULL REFERENCES PackageProduct(ProductId), RemainCount INT NOT NULL CHECK (RemainCount 0), ExpireDate DATE NOT NULL, -- 按购买日ValidMonths推算 BuyTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE TABLE RechargeRecord ( RecordId INT IDENTITY(1,1) PRIMARY KEY, MemberId INT NOT NULL REFERENCES Member(MemberId), Amount DECIMAL(10,2) NOT NULL CHECK (Amount 0), GiveAmount DECIMAL(10,2) NOT NULL DEFAULT 0, GivePoints INT NOT NULL DEFAULT 0, OperatorId INT NOT NULL REFERENCES SysUser(UserId), RechargeTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE TABLE ConsumeRecord ( ConsumeId INT IDENTITY(1,1) PRIMARY KEY, MemberId INT NOT NULL REFERENCES Member(MemberId), Amount DECIMAL(10,2) NOT NULL, -- 折后实际应收 PayBalance DECIMAL(10,2) NOT NULL DEFAULT 0, PayCash DECIMAL(10,2) NOT NULL DEFAULT 0, PayCount INT NOT NULL DEFAULT 0, -- 次卡扣掉的次数 MemberPackageId INT NULL REFERENCES MemberPackage(MemberPackageId), PointsChange INT NOT NULL DEFAULT 0, -- 正数获得 负数抵扣 OperatorId INT NOT NULL REFERENCES SysUser(UserId), ConsumeTime DATETIME NOT NULL DEFAULT GETDATE() );关键约束看三处。第一Member.Balance 没有加 CHECK (Balance 0)这是故意留的因为余额非负约束要在代码层用条件更新来保证单纯靠数据库约束会在并发时直接报错而不是提示“余额不足”。第二ConsumeRecord 几乎每个字段都有默认值尤其是 PayBalance、PayCash、PayCount这样插入时只填实际用到的支付方式即可。第三MemberPackage 的 ExpireDate 用 DATE 类型不用 DATETIME避免跨天判断有效期时被时间部分干扰。2.3 三个视图放进设计文档交接时别人才能一眼看懂业务数据库设计文档如果只有建表语句等于只给了一半。我一般会再补三个视图对应三种最常见的查询需求会员总览、到期提醒、日报汇总。这样后续写C#的时候窗体里大部分查询直接 SELECT 视图就行不用反复 JOIN。-- 会员总览余额、累计充值、累计消费、剩余次卡总次数 CREATE VIEW vMemberSummary AS SELECT m.MemberId, m.MemberNo, m.Name, m.Mobile, m.Balance, m.TotalPoints, m.OpenDate, m.Status, COALESCE((SELECT SUM(r.Amount r.GiveAmount) FROM RechargeRecord r WHERE r.MemberId m.MemberId), 0) AS TotalRecharge, COALESCE((SELECT SUM(c.Amount) FROM ConsumeRecord c WHERE c.MemberId m.MemberId), 0) AS TotalConsume, COALESCE((SELECT SUM(mp.RemainCount) FROM MemberPackage mp WHERE mp.MemberId m.MemberId AND mp.ExpireDate GETDATE()), 0) AS TotalRemainCount FROM Member m; -- 到期提醒未来30天内到期的次卡 CREATE VIEW vExpireRemind AS SELECT mp.MemberPackageId, m.MemberNo, m.Name, m.Mobile, mp.RemainCount, mp.ExpireDate, DATEDIFF(DAY, GETDATE(), mp.ExpireDate) AS DaysLeft FROM MemberPackage mp JOIN Member m ON mp.MemberId m.MemberId WHERE mp.RemainCount 0 AND mp.ExpireDate BETWEEN GETDATE() AND DATEADD(DAY, 30, GETDATE()); -- 日报按自然日操作员汇总对账用 CREATE VIEW vDailyReport AS SELECT CONVERT(DATE, ConsumeTime) AS BizDate, OperatorId, SUM(Amount) AS TotalAmount, SUM(PayBalance) AS TotalBalance, SUM(PayCash) AS TotalCash, SUM(PayCount) AS TotalCount FROM ConsumeRecord GROUP BY CONVERT(DATE, ConsumeTime), OperatorId;这里有一个值得注意的点vDailyReport 按自然日分组这在理发店场景里是有隐患的后面第4章会专门讲。设计文档里画一张简单的ER图标出这六张表和三个视图的关系再把上面这些脚本附上这个压缩包的“含数据库设计文档”部分就算立住了。C#窗体可以后面慢慢调表结构错了返工成本是最高的。3. 用C# WinForms跑通核心流程连接配置、开卡充值与消费结算3.1 连接字符串放进App.config别把数据库地址写死在窗体里数据库表结构定了接下来就是C#工程。这类系统最常见的形态是 WinForms System.Data.SqlClient轻量、好交付、也方便二次开发。我见过不少老项目把连接字符串直接 new 在 Form 里换一台电脑就要改代码重新编译这是完全没有必要的折腾。连接配置的常见做法是写在 App.config 的 connectionStrings 节里?xml version1.0 encodingutf-8 ? configuration startup useLegacyV2RuntimeActivationPolicytrue supportedRuntime versionv4.0 sku.NETFramework,Versionv4.7.2/ /startup connectionStrings add nameBarberDb connectionStringData Source.\SQLEXPRESS;Initial CatalogBarberDB;Integrated SecurityTrue;Application NameBarberPOS providerNameSystem.Data.SqlClient/ /connectionStrings /configurationC# 侧读取只需要一行var connStr ConfigurationManager.ConnectionStrings[BarberDb].ConnectionString;注意新建 WinForms 项目默认不会引用 System.Configuration.dll要在项目里手动添加引用否则上面这行代码会直接报“名称 ConfigurationManager 不存在”。另外我特意用 Integrated SecurityTrue 而不是写死 sa 密码理由是连接串里存密码发布后的 exe 或配置文件一旦被拖走数据库就等于裸奔用 Windows 集成认证至少密码不会出现在明文配置里。开发机用 .\SQLEXPRESS 默认实例部署到客户机器时把安装文档里加一句“安装 SQL Server Express 并启用默认实例”就够了。有的人喜欢用 Access 或 SQLite小店面单机用 SQLite 也可以但既然标题写的是 C# 数据库设计文档SQL Server 的表达更贴近主流交付场景。3.2 开卡与充值事务 参数化SQL防止“建了会员没入账”开卡和充值看起来是两个操作但本质是一件事插入会员主档同时写入充值流水并把充值金额加到余额上。这三个动作必须是一个事务否则会出现“会员建好了但钱没进来”或者“流水记了余额没变”的灵异现象。下面是一个典型的新开卡加首充方法事务包裹两条插入语句public int CreateMemberWithRecharge(string name, string mobile, decimal amount, int operatorId) { const string sql DECLARE memberId INT; INSERT INTO Member(MemberNo, Name, Mobile, Balance) VALUES (memberNo, name, mobile, amount); SET memberId SCOPE_IDENTITY(); INSERT INTO RechargeRecord(MemberId, Amount, GiveAmount, GivePoints, OperatorId) VALUES (memberId, amount, 0, 0, operatorId); SELECT memberId;; using (var conn new SqlConnection(_connStr)) { conn.Open(); using (var tx conn.BeginTransaction()) using (var cmd new SqlCommand(sql, conn, tx)) { cmd.Parameters.Add(memberNo, SqlDbType.NVarChar, 20).Value DateTime.Now.ToString(yyMMddHHmmss); cmd.Parameters.Add(name, SqlDbType.NVarChar, 20).Value name; cmd.Parameters.Add(mobile, SqlDbType.NVarChar, 11).Value mobile; cmd.Parameters.Add(amount, SqlDbType.Decimal).Value amount; cmd.Parameters.Add(operatorId, SqlDbType.Int).Value operatorId; var memberId (int)cmd.ExecuteScalar(); tx.Commit(); return memberId; } } }逻辑说明SQL 脚本在数据库端完成插入会员、拿到自增ID、再插流水的动作C# 这边只要保证事务提交或回滚。SCOPE_IDENTITY() 拿到的是当前会话刚插入的 MemberId不会被其他连接干扰。参数全部用 cmd.Parameters.Add 显式指定类型会员卡号用时间戳生成精确到秒在单店场景下足够唯一。这里要专门提醒一个参数问题涉及 decimal 金额时不要图省事用 AddWithValue。SqlClient 对 AddWithValue 的十进制数默认按 decimal(18,0) 推断精度够但小数位是0传 100.50 进去有概率被截断成 100等到月底对账时差几十块你怎么查都查不出来属于典型的玄学坑。用 Add 方法并显式指定 SqlDbType.Decimal才是稳的写法。3.3 消费结算次卡、余额、现金混合支付的条件更新写法理发店收银和超市不一样一个单子经常混合支付办了一张剪发次卡今天洗剪吹45元次卡扣1次或者余额付20、现金付25。每次消费要同时处理次卡次数、余额、积分跨三张表最容易出问题的是并发和脏数据。核心思路是只做条件更新不做“先查再改”。每次扣减都用 UPDATE 语句在 WHERE 里带上前置条件影响行数不是 1 就说明不满足扣减条件。public void Pay(int memberId, int? memberPackageId, decimal balancePay, decimal cashPay, int operatorId) { using (var conn new SqlConnection(_connStr)) { conn.Open(); using (var tx conn.BeginTransaction()) { // 第一步扣次卡次数条件是还有剩余且未过期 if (memberPackageId.HasValue) { var rows ExecUpdate(tx, conn, UPDATE MemberPackage SET RemainCount RemainCount - 1 WHERE MemberPackageId mpId AND RemainCount 0 AND ExpireDate GETDATE(), cmd cmd.Parameters.Add(mpId, SqlDbType.Int).Value memberPackageId.Value); if (rows ! 1) throw new Exception(次卡不可用或次数不足); } // 第二步扣余额条件更新天然防止扣成负数 if (balancePay 0) { var rows ExecUpdate(tx, conn, UPDATE Member SET Balance Balance - amt WHERE MemberId id AND Balance amt, cmd { cmd.Parameters.Add(amt, SqlDbType.Decimal).Value balancePay; cmd.Parameters.Add(id, SqlDbType.Int).Value memberId; }); if (rows ! 1) throw new Exception(余额不足); } // 第三步写消费流水 ExecUpdate(tx, conn, INSERT INTO ConsumeRecord( MemberId, Amount, PayBalance, PayCash, PayCount, MemberPackageId, PointsChange, OperatorId) VALUES( id, amount, balancePay, cashPay, payCount, mpId, points, opId), cmd { cmd.Parameters.Add(id, SqlDbType.Int).Value memberId; cmd.Parameters.Add(amount, SqlDbType.Decimal).Value balancePay cashPay (memberPackageId.HasValue ? 0 : 0); cmd.Parameters.Add(balancePay, SqlDbType.Decimal).Value balancePay; cmd.Parameters.Add(cashPay, SqlDbType.Decimal).Value cashPay; cmd.Parameters.Add(payCount, SqlDbType.Int).Value memberPackageId.HasValue ? 1 : 0; cmd.Parameters.Add(mpId, SqlDbType.Int).Value (object)memberPackageId ?? DBNull.Value; cmd.Parameters.Add(points, SqlDbType.Int).Value (int)(balancePay cashPay); cmd.Parameters.Add(opId, SqlDbType.Int).Value operatorId; }); tx.Commit(); } } }逻辑说明扣次卡的 UPDATE 同时校验 RemainCount 0 和 ExpireDate GETDATE()这两个条件少一个都不更新错误提示由影响行数驱动。扣余额同理Balance amt 写在 WHERE 里高并发下即使两个收银窗口同时按下“结账”数据库行锁也会让其中一个 UPDATE 等到另一个提交后再执行余额永远不可能变负数。积分规则按消费金额1:1累计这里直接取 balancePay cashPay如果你有会员折扣或积分倍率替换成实际规则即可。4. 理发会员系统避坑合集并发扣费、报表日期和部署环境三个翻车现场4.1 现象两个收银台同时结账余额被扣成负数店里的实际场景是前台和二楼各有一个收银窗口同一个会员卡在两个窗口同时消费余额只剩30两单各要扣20。如果代码是先 SELECT 余额算出新余额再 UPDATE 写回两个窗口同时读到30各自算出10最后余额被覆盖成10虽然没变成负数但其中一单等于白嫖了20。更严重的是余额500、两单各扣400的场景直接变成负300。原因就是经典的读改写竞态先查再改在并发下必然出错。解决方式上面3.3已经写了用 UPDATE ... WHERE Balance amt 的条件更新数据库的行锁会串行化这两个操作第二个 UPDATE 影响行数为0代码直接抛“余额不足”。次卡扣次数同理条件更新是唯一靠谱的写法不要在业务层加锁也不要想着用 Application 级别的静态锁——理发店老板不会接受“两个窗口不能同时收银”这种限制。4.2 现象“今天的日报”少了昨晚的最后一单老板有晚上盘账的习惯凌晨零点半看系统里的“今日日报”发现昨晚十一点多做的几单没统计进去。开发人员的第一反应是查时间字段是不是存错了其实数据没丢是报表的日期口径错了。原因vDailyReport 用 CONVERT(DATE, ConsumeTime) 按自然日分组23:50 的消费归属当天凌晨00:10 的消费归属第二天。但对理发店来说一个营业日往往是“早班晚班”晚班经常跨天老板心里的“今天”是从昨天营业开始到今天关门前而不是自然日零点到零点。解决给流水表加营业日字段日结时由收银员点“日结”按钮系统把当前未日结的流水统一打上 BizDate 标记或者简单点定义晚班跨天规则比如每天 06:00 之前产生的消费归属前一天。我的建议是做一张 DailyClose 日结表每天关店时生成一条记录日报从日结快照里出而不是实时 GROUP BY 流水。这样做还有一个额外好处日结后如果发现某笔单录错了可以清楚地看出是“日结前”还是“日结后”的数据对账时有据可查。4.3 现象开发机跑得好好的装到理发店电脑上就报“数据库连接失败”这是被问得最多的问题。开发机上装了 SQL Server Express代码平时连的都是 .\SQLEXPRESS客户店里的收银电脑是台老 Windows上面只有 .NET Framework没有数据库服务程序一启动连数据库必然失败。原因不是代码问题是交付物里漏了数据库运行时。常见做法有两种第一交付文档里明确写“安装 SQL Server Express”并附上安装包和建库脚本让客户电脑上有一个默认实例第二改用 SQL Server LocalDB连接串写成 AttachDbFilename|DataDirectory|\BarberDB.mdf 的形式数据库文件随程序一起走客户机器不需要安装完整服务。我一般倾向于第一种因为理发店以后大概率要加第二台收银机LocalDB 单机模式到时候迁移反而麻烦。另外不管哪种方式安装完都要验证一下服务是否启动很多“连接失败”其实是 SQL Server 服务被安全软件禁掉了。4.4 现象系统用了两个月某天打开提示找不到数据库文件有一种隐蔽的翻车开发时图方便把 .mdf 数据库文件放在桌面或者“我的文档”里程序用 AttachDbFilename 直接附加。客户用了两个月有一天开机发现数据库打不开一看是文件被安全软件隔离了或者系统清理把目录清掉了。原因很简单数据库文件放错了地方。桌面和文档目录对收银机来说是不可靠的系统还原、安全软件扫描、用户手动清理都可能波及。解决程序目录下单独建 data 子目录放数据库文件安装时用管理员权限创建再配合第5章的一键备份功能每天自动把备份文件写到另一个盘。记住一个原则数据库文件的位置必须由程序自己管理不能依赖用户手动维护。5. 交付前的“后悔药”一键备份、登录权限与防止反编译5.1 一键备份把 BACKUP DATABASE 接到界面按钮上理发店老板不会用 SQL Server Management Studio他们需要的是界面上一个“备份数据”按钮。C# 里执行数据库备份本质就是一行 SQL难点在于备份文件的存放位置和命名。我一般放在程序根目录的 Backup 子目录下文件名带时间戳方便以后按日期找回。private void btnBackup_Click(object sender, EventArgs e) { var backupDir Path.Combine(AppDomain.CurrentDomain.BaseDirectory, Backup); Directory.CreateDirectory(backupDir); var fileName string.Format(BarberDB_{0:yyyyMMdd_HHmmss}.bak, DateTime.Now); var backupPath Path.Combine(backupDir, fileName); var sql string.Format( BACKUP DATABASE BarberDB TO DISK N{0} WITH INIT, COMPRESSION, backupPath.Replace(, )); using (var conn new SqlConnection(_connStr)) using (var cmd new SqlCommand(sql, conn)) { conn.Open(); cmd.ExecuteNonQuery(); } MessageBox.Show(备份完成 backupPath); }参数说明WITH INIT 表示覆盖同名文件文件名带了分秒一般不会冲突COMPRESSION 压缩备份体积理发店的数据量不大但养成习惯没坏处。注意路径里的单引号要做转义如果文件夹路径里有中文也不需要额外处理N 前缀配合 NVARCHAR 字面量即可。更进一步可以在程序启动时检测“距上次备份超过7天”就自动弹一次提醒用 Windows 任务计划程序定时触发这个按钮背后的方法也行看交付约定。5.2 操作员和管理员分开别让店员天天看老板报表很多这种小系统的败笔是登录框就是个摆设谁都能进进了都能看经营日报。理发店人员流动大店员权限和管理员权限不分开很容易出问题。SysUser 表里 Role 字段存 1或2C# 登录成功后把角色存进全局变量主窗体的菜单和按钮按角色设置 Visible。比如“日报汇总”“充值赠送配置”“日结”只有管理员可见操作员只保留开卡、充值、消费、查询自己经手的流水。密码不要存明文至少做一层哈希private static string HashPassword(string raw) { using (var sha SHA256.Create()) { var bytes sha.ComputeHash(Encoding.UTF8.GetBytes(raw)); var sb new StringBuilder(); foreach (var b in bytes) sb.Append(b.ToString(x2)); return sb.ToString(); } }逻辑说明存哈希不存明文即使配置文件或者数据库文件被人拷走也没法直接看到密码。管理员重置店员密码时直接拿新密码重新 Hash 后 UPDATE 进去不需要支持“找回原密码”。功能不大但这一层决定了系统敢不敢真正交付给门店用。5.3 防止反编译.NET 发布前的三个固定动作C# 程序集是托管代码用 dnSpy 或 ILSpy 一拖就能看到源码这是很多刚入门的人没意识到的问题。接私活交付的程序被甲方找人反编译出源码后续尾款和口碑都会出问题。防止反编译不追求绝对安全追求的是提高门槛。我发布前的三个固定动作第一连接字符串里不存任何数据库密码用集成认证这样即使被反编译也拿不到数据库凭据第二核心业务规则不写在客户端比如会员折扣算法、积分倍率这些敏感逻辑放到服务端接口客户端只做展示和录入第三用 ConfuserEx 之类的混淆工具加壳变量名和流程会被打乱反编译难度显著上升。注意加壳之后要完整跑一遍所有功能有些混淆选项会破坏 WinForms 的反射调用我就遇到过发布后报表窗体打不开的问题。另外混淆后的 exe 有一定概率被杀毒软件误报交付时要提前跟客户打招呼让收银电脑把程序目录加进白名单。6. 再进一步卡在小票打印上的可复用收银排版很多理发店会员系统做到了能开卡、能结账、能查报表最后却栽在一张消费小票上。热敏打印机宽度有限会员名太长、套餐名太长打印出来换行错位老板娘看着乱糟糟的小票只想退款。打印的核心不是调用 PrintDocument而是控制每行文本的长度。我习惯用一个简单的截断方法按打印宽度测量字符串超宽就截断再加省略号。C# 里用 Graphics.MeasureString 能根据字体和画布准确算出像素宽度再除以字符宽度决定保留几个字符。下面是一个简化版private static string TruncateForPrint(string text, int maxWidth, Font font, Graphics g) { if (text.Length maxWidth) return text; var fullWidth g.MeasureString(text, font).Width; var charWidth fullWidth / text.Length; var maxChars (int)(maxWidth / charWidth) - 1; if (maxChars 1) return text.Substring(0, 1); return text.Substring(0, maxChars) ..; }用法也很直白打印小票前把每一行都按这个方式处理超长字符截掉保证“品名”、“数量”、“金额”三列对齐。80mm 热敏纸一行一般能放下32个中文字符但不同打印机驱动有差异所以不要写死数字用 MeasureString 现测现算最稳。第一次交付理发店项目时我没问清楚收银机是58mm还是80mm纸结果小票打印出来密密麻麻行都叠在一起老板娘当场让我改了三版才通过。后来我养成了习惯动手写打印模块前先问一句打印机型号和纸宽再定排版参数。这个习惯帮我省了不少售后电话。做这类会员管理系统数据库设计是骨架C# 代码是血肉打印和备份这些细节才是门店愿不愿意长期用的关键。希望帮到你。本文还有配套的精品资源点击获取