尧图网站开发 
简介这是一套基于C#语言开发的销售管理系统完整项目适用于刚接触WinForms与SQL Server的初学者帮助理解商品、进货、销售、库存、报表及用户权限等业务的实现方式。压缩包共93个文件大小约15.53MB其中包含C#源代码文件.cs、SQL Server数据库文件.mdf与日志 .ldf、界面图标及按钮素材.ico/.bmp、可执行程序.exe以及解决方案和配置文件展开后可直接用Visual Studio打开运行并跟踪调试。项目内置了登录窗体与进销存主窗体的设计源码数据库文件中预置了商品、供应商等基础数据并演示了如何通过ADO.NET或Entity Framework完成数据库连接与查询。同时提供系统界面预览图片便于快速确认效果。目前已有296人学习。对希望借真实项目掌握C#桌面开发与数据库编程的初学者而言这份资料结构完整、代码可读、运行方便是很好的实践范例。1. 销售管理系统为什么值得用 C# 重写一套很多公司一开始用 Excel 记录销售订单等到要查“上周每个业务员的回款”时就崩溃了。销售管理系统本质是数据管理系统围绕订单、客户、商品、员工权限把散落的表格变成一套可追溯的流程。C# 在这个领域有一个优势WinForms/WPF 做门店收银前端ASP.NET Core 做后台 API数据库访问和实体模型可以共用一套类库业务规则只写一遍。适合的业务场景是门店直营、多店连锁或中小型批发贸易不需要重型 ERP又要能对接扫码枪、电子秤和连续打印小票。下面这套思路不是某个现成系统的说明书而是从零搭一个可维护的 C# 销售管理系统时我会按顺序考虑的问题。2. 数据管理系统的核心订单表结构与 C# 数据访问层建模2.1 订单主表、明细表和库存表的字段设计要点销售管理系统的第一张蓝图不是界面原型而是表结构。只要订单主表和明细表关系清楚后续的报表、盘点、对账都会顺。用 SQL Server 举例最少的四张核心表是 SalesOrder、SalesOrderItem、Product、Customer。主表保存订单头信息明细表保存商品行两张表通过 OrderId 关联。金额字段全部用 decimal(18,2)禁止用 float 或 double。原因在于二进制浮点累加时会引入误差比如 0.1 加 0.2 在 float 下并不严格等于 0.3财务汇总和税务申报会对不上账。表名关键字段用途SalesOrderId, OrderNo, CustomerId, SalesmanId, OrderTime, Status, TotalAmount, Remark订单主表SalesOrderItemId, OrderId, ProductId, Quantity, UnitPrice, Amount订单明细ProductId, Name, Spec, Unit, Stock, Price商品与库存CustomerId, Name, Phone, Level, SalesmanId客户档案与归属状态字段用 int 存储配合 C# 枚举映射。不要把状态直接存成“待审核”“已完成”这样的中文字符串数据库排序和分组时数字比字符串更高效而且以后调整枚举名不需要改历史数据。每个表都应该加 CreatedAt 和 UpdatedAt 两个 datetime2 字段数据出问题时可以按时间线排查。OrderNo 不要用自增 int建议单独生成保证跨门店不重复具体做法放到第 4 章。2.2 用 ADO.NET 还是 EF Core销售管理系统的数据访问选型老项目通常有一个 SqlHelper 类加拼接 SQL新团队接手后没人敢改。如果从零开始我推荐 EF Core 加仓储模式。销售管理系统的客户资料和商品规格经常加字段EF Core 迁移比手写 ALTER TABLE 更不容易出错。担心 EF Core 性能差的人多半是先把整个表加载到内存再做 LINQ 过滤。正确做法是让 IQueryable 在数据库端完成 WHERE、GROUP BY、SUM 后再取数据。如果只是对单表做简单 CRUDDapper 也完全够用胜在 SQL 可控、查询透明。方案开发效率性能与可控性适合销售管理系统的位置ADO.NET低样板代码多最高但容易手滑写错连接释放遗留系统维护EF Core高模型与迁移一体中高重点是写好查询投影订单、客户、库存主流程Dapper中SQL 全手写高复杂报表、多表 JOIN同一个系统里混用 EF Core 和 Dapper 不丢人。EF Core 负责业务写入和常规查询Dapper 负责财务和销售明细报表。关键是数据访问层不要让 DataTable 到处传递对外只暴露强类型 DTO 或实体。2.3 一个最简 DbContext 与订单仓储代码示例实体模型先画清楚再写上下文。下面是最小可用的 SalesDbContext重点看 OrderNo 唯一索引和主表明细表的导航关系。public class SalesDbContext : DbContext { public DbSetSalesOrder Orders SetSalesOrder(); public DbSetSalesOrderItem OrderItems SetSalesOrderItem(); public DbSetProduct Products SetProduct(); protected override void OnModelCreating(ModelBuilder mb) { mb.EntitySalesOrder(e { e.HasKey(x x.Id); e.Property(x x.OrderNo).HasMaxLength(32).IsUnicode(false); e.HasIndex(x x.OrderNo).IsUnique(); }); mb.EntitySalesOrderItem() .HasOne(i i.Order) .WithMany(o o.Items) .HasForeignKey(i i.OrderId); } }这里指定OrderNo为 unique index等于在数据库层给订单号加了一道保险。明细表的外键 Relation 由 EF Core 自动建立索引但如果你要手动优化可以在明细表的 OrderId 上再增加一个显式索引因为查询销售流水时最常用WHERE OrderId id或按 OrderTime 范围过滤。查询和写入用仓储封装避免在按钮点击事件里直接拼 LINQpublic class OrderRepository { private readonly SalesDbContext _db; public OrderRepository(SalesDbContext db) _db db; public async TaskSalesOrder? GetOrderWithItemsAsync(string orderNo) { return await _db.Orders .AsNoTracking() .Include(o o.Items) .FirstOrDefaultAsync(o o.OrderNo orderNo); } public async Task SaveOrderAsync(SalesOrder order) { await using var tx await _db.Database.BeginTransactionAsync(); try { if (order.Id 0) _db.Orders.Add(order); else _db.Orders.Update(order); await _db.SaveChangesAsync(); await tx.CommitAsync(); } catch { await tx.RollbackAsync(); throw; } } }AsNoTracking()对只读查询很重要销售流水查询量大跟踪实体只会增加不必要的内存开销。BeginTransactionAsync保证订单头和明细要么一起写入要么一起回滚不会出现订单总金额和明细对不上的脏数据。如果后续要并发扣库存事务范围还要包含库存更新不能只包这一个 SaveChanges。3. 在 C# 里把销售流水查询做成可维护的界面DataGridView 与绑定3.1 DataGridView 绑定 BindingList 而不是直接绑 DataTableWinForms 中直接dataGridView1.DataSource dataTable很方便但有一个隐患数据刷新时列会重建用户滚动位置丢失勾选状态也容易错位。销售客服经常开着流水窗口对单刷新一次回到第一行体验非常差。推荐把查询结果投影成视图对象再绑定到BindingListT这样列结构稳定后续排序、汇总、行状态更新都由 BindingList 统一管理。var rows await _orderRepository.SearchOrdersAsync(keyword); var bindings new BindingListOrderRowViewModel( rows.Select(r new OrderRowViewModel { OrderNo r.OrderNo, Customer r.CustomerName, Salesman r.SalesmanName, OrderTime r.OrderTime, StatusText ((OrderStatus)r.Status).ToString() }).ToList()); dataGridView1.DataSource bindings; dataGridView1.AutoGenerateColumns true; dataGridView1.Columns[OrderNo].HeaderText 订单号; dataGridView1.Columns[OrderTime].DefaultCellStyle.Format yyyy-MM-dd HH:mm;AutoGenerateColumns true时列顺序按视图属性声明顺序生成。订单号、客户这些列都不需要手工创建。格式化列显示格式放在 DefaultCellStyle 上比在 SQL 里先转字符串更合理数据源保留 DateTime 类型将来做排序和导出都方便。3.2 DataGridViewComboBoxColumn 处理客户和商品下拉销售明细录入时客户和商品列做成下拉选比较友好。常见做法是使用DataGridViewComboBoxColumn设置 DataSource 为选项列表DisplayMember 指向显示文本ValueMember 指向主键。这里最容易踩的坑是下拉框修改值后当前单元格还处于编辑状态CellValueChanged不触发数据库里的值还是旧值。解决办法是在CurrentCellDirtyStateChanged事件里强制提交编辑。var customerColumn new DataGridViewComboBoxColumn { HeaderText 客户, DataPropertyName CustomerId, DataSource _customerCache, DisplayMember Name, ValueMember Id, FlatStyle FlatStyle.Flat }; dataGridView1.Columns.Add(customerColumn); private void dataGridView1_CurrentCellDirtyStateChanged(object sender, EventArgs e) { if (dataGridView1.IsCurrentCellDirty dataGridView1.CurrentCell is DataGridViewComboBoxCell) { dataGridView1.CommitEdit(DataGridViewDataErrorContexts.Commit); } }_customerCache可以是ListCustomerOption在窗体加载时一次性读取避免每次编辑行都查库。DataPropertyName告诉 DataGridView 当前列绑定到行对象的哪个属性这样提交后可以直接从行数据拿值。下拉框的 ValueMember 类型必须和属性类型一致都是 int否则会触发 DataError。这里与DataGridViewComboBoxCell相关的事件处理都归到这个提交逻辑里。3.3 用 async/await 避免查询数据时界面假死点击“查询”按钮后如果同步执行数据库访问数据量大时整个窗体卡住标题栏显示“未响应”。C# 的事件处理器可以写成 async void在 UI 线程上 await 异步查询等待期间窗体仍然能拖动、关闭没有鼠标转圈但至少不会白屏。不要用Application.DoEvents()强行刷新消息泵它会让同一段按钮逻辑被重入用户连点两下就执行两次查询。private async void btnSearch_Click(object sender, EventArgs e) { btnSearch.Enabled false; try { var keyword txtKeyword.Text.Trim(); var data await _orderRepository.SearchOrdersAsync(keyword); dataGridView1.DataSource new BindingListOrderRowViewModel(data.ToList()); } catch (Exception ex) { MessageBox.Show($查询失败{ex.Message}, 销售管理系统, MessageBoxButtons.OK, MessageBoxIcon.Warning); } finally { btnSearch.Enabled true; } }await返回之后因为 UI 同步上下文存在代码会自动回到 UI 线程所以直接给 DataGridView 赋值不会抛跨线程异常。注意仓储内部不要再包一层Task.Run否则连接池和线程池压力会变大。如果循环采集多个数据源比如逐个查询商品库存状态不要一次性 Task 全开用SemaphoreSlim(5)限制并发否则数据库连接池会被耗尽出现“连接被关闭”的偶发报错。4. 销售管理系统的关键事务库存扣减、订单编号与并发4.1 订单编号的生成要保证不重复订单号用DateTime.Now.ToString(yyyyMMddHHmmss)再加随机数高并发时依然可能重复。如果做过唯一索引重复订单号会让整个保存事务失败业务员不知道是哪里出错。常见做法是单独维护一张 OrderSeq 流水号表按门店和业务日期生成连续编号。事务内先更新序号再读序号保证同一时间只有一个请求能拿到同一个号。BEGIN TRAN; UPDATE OrderSeq SET Seq Seq 1 WHERE BizDate today AND StoreId storeId; SELECT Seq FROM OrderSeq WHERE BizDate today AND StoreId storeId; COMMIT;这段 SQL 的锁粒度比整张订单表小单门店一天几万单足够。多门店场景下StoreId 可以隔离每家的流水合库时不会撞单号。如果未来量级提升到需要高并发取号再换 Redis 的 INCRBY 也不迟但数据库表方案更简单不会引入额外中间件。4.2 扣库存一定不要用先查询再判断很多新人在 C# 里这样写扣库存先查出商品再判断 Stock 是否足够足够就减一然后 SaveChanges。这在单用户时没问题但当两个人同时下单两个事务都读到库存 5都判断可以扣 3最后库存会变成负数。正确做法是把判断条件写进 UPDATE 语句数据库行锁会保证只有一个事务能成功更新。var result await _db.Database.ExecuteSqlInterpolatedAsync( $UPDATE Product SET Stock Stock - {quantity} $WHERE Id {productId} AND Stock {quantity}); if (result 0) { throw new InvalidOperationException($商品 {productId} 库存不足); }ExecuteSqlInterpolatedAsync会把花括号里的变量参数化天然防 SQL 注入。result是受影响行数如果为 0说明库存不满足条件事务回滚订单不能生成。这样校验和更新在一个原子操作内完成不需要应用层加锁。Product.Stock 字段建议用 int 或 decimal不要用 double否则Stock quantity在浮点运算下会有边界问题。4.3 销售报表统计用 LINQ 要注意 N1 和数据精度按销售员汇总销售额、按客户汇总毛利这类报表如果写成 C# 内存循环每个订单再取明细会产生 N1 查询报表一慢就是几百次数据库往返。正确的做法是让 EF Core 把 LINQ 翻译成 SQL 的 GROUP BY只返回聚合结果。var report await _db.Orders .Where(o o.OrderTime start o.OrderTime end.AddDays(1)) .SelectMany(o o.Items) .GroupBy(i i.Product.Category) .Select(g new CategorySummary { Category g.Key, Quantity g.Sum(i i.Quantity), Amount g.Sum(i i.Amount) }) .OrderByDescending(x x.Amount) .ToListAsync();这里需要注意.Where(o o.OrderTime start o.OrderTime end.AddDays(1))使用右开区间避免 end 当天的时间被丢掉。EF Core 会把整条查询翻译成 SQL 的 GROUP BY不会把明细加载到内存。金额字段如果全用 decimalSQL 生成的 SUM 精度是可靠的如果某个库表历史遗留是 float建议在数据库层先CAST(Amount AS decimal(18,2))转换。报表异常现象常见原因定位思路金额差 0.01有字段是 float/double查字段类型统一 decimal查询慢看不到 SQL默认加载整表用 ToQueryString 看生成的 SQL库存超卖应用层先查后扣改为条件 UPDATE5. 销售管理系统的权限与日志设计基于特性反射的拦截实现5.1 用 Attribute 标注菜单和操作权限权限设计如果做成硬编码每加一个功能都要改权限判断逻辑业务上线后被频繁追问“为什么没有权限”。我习惯用 C# 特性加反射的方式把功能码和方法绑定在一起。销售管理系统的菜单、按钮、接口都可以用同一个特性驱动权限数据表只存功能码和角色关系。[AttributeUsage(AttributeTargets.Method, AllowMultiple false)] public class SalesPermissionAttribute : Attribute { public string ModuleCode { get; } public string ActionName { get; } public SalesPermissionAttribute(string moduleCode, string actionName) { ModuleCode moduleCode; ActionName actionName; } } public class OrderService { [SalesPermission(SALE_ORDER, 导出)] public void ExportOrders(DateTime start, DateTime end) { } }特性本身不包含逻辑它只负责标记。AllowMultiple false表示一个方法只能挂一个权限点防止同一个功能被重复标记导致权限树出现两份相同菜单。ActionName 是“导出”“审核”“作废”这类操作名ModuleCode 是模块编码用来做菜单分类。5.2 用反射遍历程序集生成权限菜单权限管理页面需要把系统所有功能列出来手动写菜单要人肉同步容易漏。反射可以从程序集里把所有标了SalesPermissionAttribute的方法找出来自动生成权限列表。这个操作在系统启动和打开权限管理页时各做一次即可不需要每次登录都扫程序集。var permissions new ListPermissionDto(); var assembly typeof(OrderService).Assembly; foreach (var type in assembly.GetTypes()) { foreach (var method in type.GetMethods(BindingFlags.Public | BindingFlags.Instance)) { var attr method.GetCustomAttributeSalesPermissionAttribute(); if (attr null) continue; permissions.Add(new PermissionDto { ModuleCode attr.ModuleCode, ActionName attr.ActionName, MethodName method.Name }); } }BindingFlags.Public | BindingFlags.Instance限定只扫描公开的实例方法避免把内部辅助方法也暴露给权限配置。代码里的assembly.GetTypes()在启动时会被 JIT 加载如果事后用 Only 模式逻辑上有一点性能消耗但权限配置页不是高频入口完全可接受。这个方案最大的好处是新写一个导出功能贴一行特性权限树自动出现“导出”按钮。5.3 操作日志用队列异步落库不阻塞主流程销售管理系统里最容易被砍掉的需求是操作日志等到真出了问题业务方会问“这张单谁改的”。如果每保存一次订单就同步插一条日志数据库压力翻倍保存接口响应变慢。常见做法是写一个内存队列后台线程批量落库。下面是最简单的消费者模型主流程只往队列写后台任务负责持久化。public class AuditLogger { private readonly BlockingCollectionAuditLog _queue new(); private readonly Task _flushTask; public AuditLogger() { _flushTask Task.Run(() FlushLoop()); } public void Write(string userId, string action, string detail) { _queue.Add(new AuditLog { UserId userId, Action action, Detail detail, LogTime DateTime.Now }); } private async Task FlushLoop() { foreach (var item in _queue.GetConsumingEnumerable()) { try { await using var db new SalesDbContext(); db.AuditLogs.Add(item); await db.SaveChangesAsync(); } catch { _queue.Add(item); } } } }这个实现有两个注意点进程意外退出时队列里还没落库的日志会丢因此核心单据的修改日志就不能只走内存队列最好在同一个数据库事务里写入日志表重试时直接把 item 放回队列尾部可能导致日志顺序变化但不至于完全丢失。Detail 字段要限制长度比如数据库设计 varchar(500)代码里再做一次截断防止“其他说明”框被用户填满后插入失败。6. 上线前必调好的 C# 系统配置项和验证方法6.1 连接字符串和超时参数销售管理系统上线后门店网络不稳定时最容易报“连接超时”。连接字符串和 EF Core 的命令超时要分开设置连接超时控制的是建立 TCP 连接命令超时控制的是 SQL 执行时间。{ ConnectionStrings: { SalesDb: Server.;DatabaseSalesDB;Integrated SecurityTrue;TrustServerCertificateTrue;Connect Timeout15;PoolingTrue;Max Pool Size100 } }长报表耗时可能超过 30 秒默认 30 秒命令超时不够把 EF Core 的 CommandTimeout 调整到 60 秒具体在UseSqlServer里配置。批量删除和更新不要循环 SaveChanges用ExecuteDelete()直接生成一条 DELETE 语句既能减少往返又能避免超时。6.2 从 DataGridView 到 Excel 导出的编码坑销售管理系统的“导出 Excel”功能很多是导出 CSV 文件。直接用File.WriteAllLines默认使用 UTF-8 无 BOMExcel 打开时中文会乱码。必须使用带 BOM 的 UTF-8 编码File.WriteAllLines(销售流水.csv, lines, new UTF8Encoding(true));new UTF8Encoding(true)的第一个参数 true 表示写入 BOMExcel 看到 BOM 会识别为 UTF-8中文正常显示。如果客户非要 .xlsx建议用 NPOI 或 ClosedXML不要自己在 CSV 里拼逗号和引号数据里有逗号时导出文件会裂列。6.3 对接串口扫码枪时的 UI 多线程门店收银端偶尔需要连接串口扫码枪或电子秤这是典型的 C# 串口通信场景。SerialPort.DataReceived事件运行在后台线程直接操作 TextBox 会抛跨线程异常。正确做法是用BeginInvoke把刷新逻辑调度回 UI 线程。private void sp_DataReceived(object sender, SerialDataReceivedEventArgs e) { string data sp.ReadExisting(); BeginInvoke(new Action(() txtScan.Text data)); }串口接收数据并不保证一帧到达可能一个条码分两次触发如果直接把 TextBox 内容当作完整条码会出现解析错误。正确做法是拼接缓冲区遇到换行符再判断完整条码。6.4 压测验证清单检查项操作预期结果并发下单用 JMeter 开 50 个线程直压下单接口库存不超卖订单号无重复大查询查询 30 万行销售流水UI 不假死5 秒内返回导出文件查看 CSV 文件前三个字节EF BB BF串口扫码连续扫码 100 次条码无截断无跨线程异常操作日志作废一单后查看 AuditLog 表有记录且不阻塞主流程这些配置全部检查一遍再交付给业务试用。本文还有配套的精品资源点击获取 
简介这是一套基于C#语言开发的销售管理系统完整项目适用于刚接触WinForms与SQL Server的初学者帮助理解商品、进货、销售、库存、报表及用户权限等业务的实现方式。压缩包共93个文件大小约15.53MB其中包含C#源代码文件.cs、SQL Server数据库文件.mdf与日志 .ldf、界面图标及按钮素材.ico/.bmp、可执行程序.exe以及解决方案和配置文件展开后可直接用Visual Studio打开运行并跟踪调试。项目内置了登录窗体与进销存主窗体的设计源码数据库文件中预置了商品、供应商等基础数据并演示了如何通过ADO.NET或Entity Framework完成数据库连接与查询。同时提供系统界面预览图片便于快速确认效果。目前已有296人学习。对希望借真实项目掌握C#桌面开发与数据库编程的初学者而言这份资料结构完整、代码可读、运行方便是很好的实践范例。1. 销售管理系统为什么值得用 C# 重写一套很多公司一开始用 Excel 记录销售订单等到要查“上周每个业务员的回款”时就崩溃了。销售管理系统本质是数据管理系统围绕订单、客户、商品、员工权限把散落的表格变成一套可追溯的流程。C# 在这个领域有一个优势WinForms/WPF 做门店收银前端ASP.NET Core 做后台 API数据库访问和实体模型可以共用一套类库业务规则只写一遍。适合的业务场景是门店直营、多店连锁或中小型批发贸易不需要重型 ERP又要能对接扫码枪、电子秤和连续打印小票。下面这套思路不是某个现成系统的说明书而是从零搭一个可维护的 C# 销售管理系统时我会按顺序考虑的问题。2. 数据管理系统的核心订单表结构与 C# 数据访问层建模2.1 订单主表、明细表和库存表的字段设计要点销售管理系统的第一张蓝图不是界面原型而是表结构。只要订单主表和明细表关系清楚后续的报表、盘点、对账都会顺。用 SQL Server 举例最少的四张核心表是 SalesOrder、SalesOrderItem、Product、Customer。主表保存订单头信息明细表保存商品行两张表通过 OrderId 关联。金额字段全部用 decimal(18,2)禁止用 float 或 double。原因在于二进制浮点累加时会引入误差比如 0.1 加 0.2 在 float 下并不严格等于 0.3财务汇总和税务申报会对不上账。表名关键字段用途SalesOrderId, OrderNo, CustomerId, SalesmanId, OrderTime, Status, TotalAmount, Remark订单主表SalesOrderItemId, OrderId, ProductId, Quantity, UnitPrice, Amount订单明细ProductId, Name, Spec, Unit, Stock, Price商品与库存CustomerId, Name, Phone, Level, SalesmanId客户档案与归属状态字段用 int 存储配合 C# 枚举映射。不要把状态直接存成“待审核”“已完成”这样的中文字符串数据库排序和分组时数字比字符串更高效而且以后调整枚举名不需要改历史数据。每个表都应该加 CreatedAt 和 UpdatedAt 两个 datetime2 字段数据出问题时可以按时间线排查。OrderNo 不要用自增 int建议单独生成保证跨门店不重复具体做法放到第 4 章。2.2 用 ADO.NET 还是 EF Core销售管理系统的数据访问选型老项目通常有一个 SqlHelper 类加拼接 SQL新团队接手后没人敢改。如果从零开始我推荐 EF Core 加仓储模式。销售管理系统的客户资料和商品规格经常加字段EF Core 迁移比手写 ALTER TABLE 更不容易出错。担心 EF Core 性能差的人多半是先把整个表加载到内存再做 LINQ 过滤。正确做法是让 IQueryable 在数据库端完成 WHERE、GROUP BY、SUM 后再取数据。如果只是对单表做简单 CRUDDapper 也完全够用胜在 SQL 可控、查询透明。方案开发效率性能与可控性适合销售管理系统的位置ADO.NET低样板代码多最高但容易手滑写错连接释放遗留系统维护EF Core高模型与迁移一体中高重点是写好查询投影订单、客户、库存主流程Dapper中SQL 全手写高复杂报表、多表 JOIN同一个系统里混用 EF Core 和 Dapper 不丢人。EF Core 负责业务写入和常规查询Dapper 负责财务和销售明细报表。关键是数据访问层不要让 DataTable 到处传递对外只暴露强类型 DTO 或实体。2.3 一个最简 DbContext 与订单仓储代码示例实体模型先画清楚再写上下文。下面是最小可用的 SalesDbContext重点看 OrderNo 唯一索引和主表明细表的导航关系。public class SalesDbContext : DbContext { public DbSetSalesOrder Orders SetSalesOrder(); public DbSetSalesOrderItem OrderItems SetSalesOrderItem(); public DbSetProduct Products SetProduct(); protected override void OnModelCreating(ModelBuilder mb) { mb.EntitySalesOrder(e { e.HasKey(x x.Id); e.Property(x x.OrderNo).HasMaxLength(32).IsUnicode(false); e.HasIndex(x x.OrderNo).IsUnique(); }); mb.EntitySalesOrderItem() .HasOne(i i.Order) .WithMany(o o.Items) .HasForeignKey(i i.OrderId); } }这里指定OrderNo为 unique index等于在数据库层给订单号加了一道保险。明细表的外键 Relation 由 EF Core 自动建立索引但如果你要手动优化可以在明细表的 OrderId 上再增加一个显式索引因为查询销售流水时最常用WHERE OrderId id或按 OrderTime 范围过滤。查询和写入用仓储封装避免在按钮点击事件里直接拼 LINQpublic class OrderRepository { private readonly SalesDbContext _db; public OrderRepository(SalesDbContext db) _db db; public async TaskSalesOrder? GetOrderWithItemsAsync(string orderNo) { return await _db.Orders .AsNoTracking() .Include(o o.Items) .FirstOrDefaultAsync(o o.OrderNo orderNo); } public async Task SaveOrderAsync(SalesOrder order) { await using var tx await _db.Database.BeginTransactionAsync(); try { if (order.Id 0) _db.Orders.Add(order); else _db.Orders.Update(order); await _db.SaveChangesAsync(); await tx.CommitAsync(); } catch { await tx.RollbackAsync(); throw; } } }AsNoTracking()对只读查询很重要销售流水查询量大跟踪实体只会增加不必要的内存开销。BeginTransactionAsync保证订单头和明细要么一起写入要么一起回滚不会出现订单总金额和明细对不上的脏数据。如果后续要并发扣库存事务范围还要包含库存更新不能只包这一个 SaveChanges。3. 在 C# 里把销售流水查询做成可维护的界面DataGridView 与绑定3.1 DataGridView 绑定 BindingList 而不是直接绑 DataTableWinForms 中直接dataGridView1.DataSource dataTable很方便但有一个隐患数据刷新时列会重建用户滚动位置丢失勾选状态也容易错位。销售客服经常开着流水窗口对单刷新一次回到第一行体验非常差。推荐把查询结果投影成视图对象再绑定到BindingListT这样列结构稳定后续排序、汇总、行状态更新都由 BindingList 统一管理。var rows await _orderRepository.SearchOrdersAsync(keyword); var bindings new BindingListOrderRowViewModel( rows.Select(r new OrderRowViewModel { OrderNo r.OrderNo, Customer r.CustomerName, Salesman r.SalesmanName, OrderTime r.OrderTime, StatusText ((OrderStatus)r.Status).ToString() }).ToList()); dataGridView1.DataSource bindings; dataGridView1.AutoGenerateColumns true; dataGridView1.Columns[OrderNo].HeaderText 订单号; dataGridView1.Columns[OrderTime].DefaultCellStyle.Format yyyy-MM-dd HH:mm;AutoGenerateColumns true时列顺序按视图属性声明顺序生成。订单号、客户这些列都不需要手工创建。格式化列显示格式放在 DefaultCellStyle 上比在 SQL 里先转字符串更合理数据源保留 DateTime 类型将来做排序和导出都方便。3.2 DataGridViewComboBoxColumn 处理客户和商品下拉销售明细录入时客户和商品列做成下拉选比较友好。常见做法是使用DataGridViewComboBoxColumn设置 DataSource 为选项列表DisplayMember 指向显示文本ValueMember 指向主键。这里最容易踩的坑是下拉框修改值后当前单元格还处于编辑状态CellValueChanged不触发数据库里的值还是旧值。解决办法是在CurrentCellDirtyStateChanged事件里强制提交编辑。var customerColumn new DataGridViewComboBoxColumn { HeaderText 客户, DataPropertyName CustomerId, DataSource _customerCache, DisplayMember Name, ValueMember Id, FlatStyle FlatStyle.Flat }; dataGridView1.Columns.Add(customerColumn); private void dataGridView1_CurrentCellDirtyStateChanged(object sender, EventArgs e) { if (dataGridView1.IsCurrentCellDirty dataGridView1.CurrentCell is DataGridViewComboBoxCell) { dataGridView1.CommitEdit(DataGridViewDataErrorContexts.Commit); } }_customerCache可以是ListCustomerOption在窗体加载时一次性读取避免每次编辑行都查库。DataPropertyName告诉 DataGridView 当前列绑定到行对象的哪个属性这样提交后可以直接从行数据拿值。下拉框的 ValueMember 类型必须和属性类型一致都是 int否则会触发 DataError。这里与DataGridViewComboBoxCell相关的事件处理都归到这个提交逻辑里。3.3 用 async/await 避免查询数据时界面假死点击“查询”按钮后如果同步执行数据库访问数据量大时整个窗体卡住标题栏显示“未响应”。C# 的事件处理器可以写成 async void在 UI 线程上 await 异步查询等待期间窗体仍然能拖动、关闭没有鼠标转圈但至少不会白屏。不要用Application.DoEvents()强行刷新消息泵它会让同一段按钮逻辑被重入用户连点两下就执行两次查询。private async void btnSearch_Click(object sender, EventArgs e) { btnSearch.Enabled false; try { var keyword txtKeyword.Text.Trim(); var data await _orderRepository.SearchOrdersAsync(keyword); dataGridView1.DataSource new BindingListOrderRowViewModel(data.ToList()); } catch (Exception ex) { MessageBox.Show($查询失败{ex.Message}, 销售管理系统, MessageBoxButtons.OK, MessageBoxIcon.Warning); } finally { btnSearch.Enabled true; } }await返回之后因为 UI 同步上下文存在代码会自动回到 UI 线程所以直接给 DataGridView 赋值不会抛跨线程异常。注意仓储内部不要再包一层Task.Run否则连接池和线程池压力会变大。如果循环采集多个数据源比如逐个查询商品库存状态不要一次性 Task 全开用SemaphoreSlim(5)限制并发否则数据库连接池会被耗尽出现“连接被关闭”的偶发报错。4. 销售管理系统的关键事务库存扣减、订单编号与并发4.1 订单编号的生成要保证不重复订单号用DateTime.Now.ToString(yyyyMMddHHmmss)再加随机数高并发时依然可能重复。如果做过唯一索引重复订单号会让整个保存事务失败业务员不知道是哪里出错。常见做法是单独维护一张 OrderSeq 流水号表按门店和业务日期生成连续编号。事务内先更新序号再读序号保证同一时间只有一个请求能拿到同一个号。BEGIN TRAN; UPDATE OrderSeq SET Seq Seq 1 WHERE BizDate today AND StoreId storeId; SELECT Seq FROM OrderSeq WHERE BizDate today AND StoreId storeId; COMMIT;这段 SQL 的锁粒度比整张订单表小单门店一天几万单足够。多门店场景下StoreId 可以隔离每家的流水合库时不会撞单号。如果未来量级提升到需要高并发取号再换 Redis 的 INCRBY 也不迟但数据库表方案更简单不会引入额外中间件。4.2 扣库存一定不要用先查询再判断很多新人在 C# 里这样写扣库存先查出商品再判断 Stock 是否足够足够就减一然后 SaveChanges。这在单用户时没问题但当两个人同时下单两个事务都读到库存 5都判断可以扣 3最后库存会变成负数。正确做法是把判断条件写进 UPDATE 语句数据库行锁会保证只有一个事务能成功更新。var result await _db.Database.ExecuteSqlInterpolatedAsync( $UPDATE Product SET Stock Stock - {quantity} $WHERE Id {productId} AND Stock {quantity}); if (result 0) { throw new InvalidOperationException($商品 {productId} 库存不足); }ExecuteSqlInterpolatedAsync会把花括号里的变量参数化天然防 SQL 注入。result是受影响行数如果为 0说明库存不满足条件事务回滚订单不能生成。这样校验和更新在一个原子操作内完成不需要应用层加锁。Product.Stock 字段建议用 int 或 decimal不要用 double否则Stock quantity在浮点运算下会有边界问题。4.3 销售报表统计用 LINQ 要注意 N1 和数据精度按销售员汇总销售额、按客户汇总毛利这类报表如果写成 C# 内存循环每个订单再取明细会产生 N1 查询报表一慢就是几百次数据库往返。正确的做法是让 EF Core 把 LINQ 翻译成 SQL 的 GROUP BY只返回聚合结果。var report await _db.Orders .Where(o o.OrderTime start o.OrderTime end.AddDays(1)) .SelectMany(o o.Items) .GroupBy(i i.Product.Category) .Select(g new CategorySummary { Category g.Key, Quantity g.Sum(i i.Quantity), Amount g.Sum(i i.Amount) }) .OrderByDescending(x x.Amount) .ToListAsync();这里需要注意.Where(o o.OrderTime start o.OrderTime end.AddDays(1))使用右开区间避免 end 当天的时间被丢掉。EF Core 会把整条查询翻译成 SQL 的 GROUP BY不会把明细加载到内存。金额字段如果全用 decimalSQL 生成的 SUM 精度是可靠的如果某个库表历史遗留是 float建议在数据库层先CAST(Amount AS decimal(18,2))转换。报表异常现象常见原因定位思路金额差 0.01有字段是 float/double查字段类型统一 decimal查询慢看不到 SQL默认加载整表用 ToQueryString 看生成的 SQL库存超卖应用层先查后扣改为条件 UPDATE5. 销售管理系统的权限与日志设计基于特性反射的拦截实现5.1 用 Attribute 标注菜单和操作权限权限设计如果做成硬编码每加一个功能都要改权限判断逻辑业务上线后被频繁追问“为什么没有权限”。我习惯用 C# 特性加反射的方式把功能码和方法绑定在一起。销售管理系统的菜单、按钮、接口都可以用同一个特性驱动权限数据表只存功能码和角色关系。[AttributeUsage(AttributeTargets.Method, AllowMultiple false)] public class SalesPermissionAttribute : Attribute { public string ModuleCode { get; } public string ActionName { get; } public SalesPermissionAttribute(string moduleCode, string actionName) { ModuleCode moduleCode; ActionName actionName; } } public class OrderService { [SalesPermission(SALE_ORDER, 导出)] public void ExportOrders(DateTime start, DateTime end) { } }特性本身不包含逻辑它只负责标记。AllowMultiple false表示一个方法只能挂一个权限点防止同一个功能被重复标记导致权限树出现两份相同菜单。ActionName 是“导出”“审核”“作废”这类操作名ModuleCode 是模块编码用来做菜单分类。5.2 用反射遍历程序集生成权限菜单权限管理页面需要把系统所有功能列出来手动写菜单要人肉同步容易漏。反射可以从程序集里把所有标了SalesPermissionAttribute的方法找出来自动生成权限列表。这个操作在系统启动和打开权限管理页时各做一次即可不需要每次登录都扫程序集。var permissions new ListPermissionDto(); var assembly typeof(OrderService).Assembly; foreach (var type in assembly.GetTypes()) { foreach (var method in type.GetMethods(BindingFlags.Public | BindingFlags.Instance)) { var attr method.GetCustomAttributeSalesPermissionAttribute(); if (attr null) continue; permissions.Add(new PermissionDto { ModuleCode attr.ModuleCode, ActionName attr.ActionName, MethodName method.Name }); } }BindingFlags.Public | BindingFlags.Instance限定只扫描公开的实例方法避免把内部辅助方法也暴露给权限配置。代码里的assembly.GetTypes()在启动时会被 JIT 加载如果事后用 Only 模式逻辑上有一点性能消耗但权限配置页不是高频入口完全可接受。这个方案最大的好处是新写一个导出功能贴一行特性权限树自动出现“导出”按钮。5.3 操作日志用队列异步落库不阻塞主流程销售管理系统里最容易被砍掉的需求是操作日志等到真出了问题业务方会问“这张单谁改的”。如果每保存一次订单就同步插一条日志数据库压力翻倍保存接口响应变慢。常见做法是写一个内存队列后台线程批量落库。下面是最简单的消费者模型主流程只往队列写后台任务负责持久化。public class AuditLogger { private readonly BlockingCollectionAuditLog _queue new(); private readonly Task _flushTask; public AuditLogger() { _flushTask Task.Run(() FlushLoop()); } public void Write(string userId, string action, string detail) { _queue.Add(new AuditLog { UserId userId, Action action, Detail detail, LogTime DateTime.Now }); } private async Task FlushLoop() { foreach (var item in _queue.GetConsumingEnumerable()) { try { await using var db new SalesDbContext(); db.AuditLogs.Add(item); await db.SaveChangesAsync(); } catch { _queue.Add(item); } } } }这个实现有两个注意点进程意外退出时队列里还没落库的日志会丢因此核心单据的修改日志就不能只走内存队列最好在同一个数据库事务里写入日志表重试时直接把 item 放回队列尾部可能导致日志顺序变化但不至于完全丢失。Detail 字段要限制长度比如数据库设计 varchar(500)代码里再做一次截断防止“其他说明”框被用户填满后插入失败。6. 上线前必调好的 C# 系统配置项和验证方法6.1 连接字符串和超时参数销售管理系统上线后门店网络不稳定时最容易报“连接超时”。连接字符串和 EF Core 的命令超时要分开设置连接超时控制的是建立 TCP 连接命令超时控制的是 SQL 执行时间。{ ConnectionStrings: { SalesDb: Server.;DatabaseSalesDB;Integrated SecurityTrue;TrustServerCertificateTrue;Connect Timeout15;PoolingTrue;Max Pool Size100 } }长报表耗时可能超过 30 秒默认 30 秒命令超时不够把 EF Core 的 CommandTimeout 调整到 60 秒具体在UseSqlServer里配置。批量删除和更新不要循环 SaveChanges用ExecuteDelete()直接生成一条 DELETE 语句既能减少往返又能避免超时。6.2 从 DataGridView 到 Excel 导出的编码坑销售管理系统的“导出 Excel”功能很多是导出 CSV 文件。直接用File.WriteAllLines默认使用 UTF-8 无 BOMExcel 打开时中文会乱码。必须使用带 BOM 的 UTF-8 编码File.WriteAllLines(销售流水.csv, lines, new UTF8Encoding(true));new UTF8Encoding(true)的第一个参数 true 表示写入 BOMExcel 看到 BOM 会识别为 UTF-8中文正常显示。如果客户非要 .xlsx建议用 NPOI 或 ClosedXML不要自己在 CSV 里拼逗号和引号数据里有逗号时导出文件会裂列。6.3 对接串口扫码枪时的 UI 多线程门店收银端偶尔需要连接串口扫码枪或电子秤这是典型的 C# 串口通信场景。SerialPort.DataReceived事件运行在后台线程直接操作 TextBox 会抛跨线程异常。正确做法是用BeginInvoke把刷新逻辑调度回 UI 线程。private void sp_DataReceived(object sender, SerialDataReceivedEventArgs e) { string data sp.ReadExisting(); BeginInvoke(new Action(() txtScan.Text data)); }串口接收数据并不保证一帧到达可能一个条码分两次触发如果直接把 TextBox 内容当作完整条码会出现解析错误。正确做法是拼接缓冲区遇到换行符再判断完整条码。6.4 压测验证清单检查项操作预期结果并发下单用 JMeter 开 50 个线程直压下单接口库存不超卖订单号无重复大查询查询 30 万行销售流水UI 不假死5 秒内返回导出文件查看 CSV 文件前三个字节EF BB BF串口扫码连续扫码 100 次条码无截断无跨线程异常操作日志作废一单后查看 AuditLog 表有记录且不阻塞主流程这些配置全部检查一遍再交付给业务试用。本文还有配套的精品资源点击获取