简介一份面向C#毕业设计的仓库条码管理系统源码选用.NET WinForms/WPF结合SQL Server/MySQL覆盖入库、出库、库存查询、条码扫描和报表生成等仓库管理核心环节适合需要掌握C#桌面开发与数据库联调的开发者借鉴。压缩包共132个文件以47个cs源码文件为主辅以resx/resources界面资源和jpg图片素材同时含sln解决方案、config项目配置、SQL脚本以及mdf/ldf数据库文件整体约9.96MB。目前已有204人学习下载。源码中包含出入库、库存等核心窗体的Designer设计器代码并将条码解析与商品信息关联便于理解窗体布局、数据访问和条码在仓储流程中的落地方式。通过阅读项目结构与关键模块可以掌握从数据库设计到界面交互的完整开发路径对完成毕业设计或仓库类项目有直接参考价值。1. 仓库条码管理系统为什么C#仍是首选一线做仓储软件这些年我接触过不少扫码枪、PDA和后台管理程序。仓库条码管理系统的核心就三件事条码得能生成和打印扫码枪得能把条码内容干净地交给程序库存账在入库出库盘点的瞬间必须保持一致。C#在这三件事上都有成熟路径ZXing.Net负责条码渲染SerialPort接串口枪或接收键盘模拟输入SqlClient配合事务把库存操作做成原子更新。这套源码.zip解压后是典型的三层结构WinForm界面、BLL业务层、DAL数据层外加数据库脚本只要环境有.NET Framework 4.6.1以上和SQL Server就能跑。下面按数据模型设计、条码读写实现、业务事务、部署与排错四步拆开讲透。2. 数据模型先行条码编码规则与库存表结构仓储系统的稳定性七成在数据模型上。条码怎么编、库存怎么存、流水怎么记这三件事没想清楚之前先别写业务代码。2.1 条码按前缀SKU批次流水号编码常见的做法是把条码编成有意义的结构而不是随机的无意义串。比如一张入库标签的编码WH-IN-20240715-0001拆开看字段示例长度说明仓库前缀WH2-4位多仓库时用于区分物理位置作业类型IN/OUT/PD2-3位入库、出库、盘点日期码202407158位按业务发生日期而不是系统日期流水号00014位以上当天内自增跨天重置这种编码的好处是扫码枪扫到后程序不需要回表就能先在内存里判断出这是一张入库单。如果做成不透明随机串每次扫描就得查作业单表PDA在弱网环境下会明显卡顿。有个细节容易被忽略条码长度超过20位后Code128虽然能承载但打印小标签时密度过高低端扫码枪误读率会上升。所以流水号一般不超过4-6位日期码尽量用8位而不是14位时间戳。批次号我通常直接用日期码加两位序号这样FIFO出库时ORDER BY字符串就是时间顺序。2.2 五张核心表商品、批次、库存、流水、作业单我再怎么强调都不过分库存必须拆成批次表和汇总表而不是一个简单的数量字段。因为仓库条码系统里同一个SKU对应多个批次每个批次的供应商、有效期和进价都不同出库要做先进先出就必须以批次为粒度。CREATE TABLE Product ( ProductId INT IDENTITY(1,1) PRIMARY KEY, SkuCode VARCHAR(32) NOT NULL, ProductName NVARCHAR(128) NOT NULL, Unit NVARCHAR(8) DEFAULT N件, Barcode VARCHAR(32) NULL, -- 商品自带条码无需程序生成 CreatedAt DATETIME2 DEFAULT SYSDATETIME() ); CREATE UNIQUE INDEX UX_Product_Sku ON Product(SkuCode); CREATE TABLE ProductBatch ( BatchId INT IDENTITY(1,1) PRIMARY KEY, ProductId INT NOT NULL REFERENCES Product(ProductId), BatchNo VARCHAR(32) NOT NULL, -- 批次号通常沿用条码中的日期段 Location VARCHAR(16) NULL, -- 物理库位编码 ExpireDate DATE NULL, Qty DECIMAL(12,3) NOT NULL DEFAULT 0, CONSTRAINT UX_Batch UNIQUE (ProductId, BatchNo, Location) ); CREATE TABLE Stock ( ProductId INT NOT NULL PRIMARY KEY, Qty DECIMAL(12,3) NOT NULL DEFAULT 0 ); CREATE TABLE StockLog ( LogId BIGINT IDENTITY(1,1) PRIMARY KEY, ProductId INT NOT NULL, BatchId INT NULL, OpType TINYINT NOT NULL, -- 1入库 2出库 3盘点调整 ChangeQty DECIMAL(12,3) NOT NULL, -- 正数增加负数减少 RefCode VARCHAR(64) NULL, -- 关联的作业单号 Operator NVARCHAR(32) NULL, CreatedAt DATETIME2 DEFAULT SYSDATETIME() ); CREATE INDEX IX_Log_Product_Time ON StockLog(ProductId, CreatedAt); CREATE TABLE Operation ( OperationId INT IDENTITY(1,1) PRIMARY KEY, OpCode VARCHAR(32) NOT NULL, -- 对外单据号如 IN202407150001 OpType TINYINT NOT NULL, Status TINYINT NOT NULL DEFAULT 0, -- 0新建 1完成 2取消 ProductId INT NULL, Qty DECIMAL(12,3) NOT NULL DEFAULT 0, CreatedAt DATETIME2 DEFAULT SYSDATETIME() );这段SQL里有几个设计点值得说明。Product和ProductBatch分离同一个SkuCode可以持有多个批次批次表把Location纳入唯一约束是为了支持同一批次拆到两个库位的场景。StockLog只记录变更量正数入、负数出期末对账时只需要重放流水就能还原任意时点的库存。Operation表字段很少但它承担审计职能扫码类系统最怕的就是出了问题查不到执行记录。还有一个不在DDL里的约定所有数量字段用DECIMAL(12,3)不用FLOAT。条码系统里会出现按重量计价入库的场景浮点累加误差到月底盘点时会让账实差异说不清楚。DECIMAL也许写起来啰嗦但它值得。2.3 索引策略与两个并发瓶颈这套模型的并发瓶颈集中在两处。一是同一个SKU同时入库时Stock表的行锁竞争二是盘点高峰时StockLog增长过快。对第一处我的建议是不要给Stock表堆索引主键聚合索引就够了。真正的并发控制放在事务层面靠SQL Server的UPDLOCK提示详细写法见第4章。对第二处StockLog保留3-6个月更早的用后台归档作业迁到StockLogArchive避免单表过大拖慢查询。如果仓库没有库位管理需求把Location字段去掉唯一索引用(ProductId, BatchNo)就够了。加了这个字段等于引入了新的业务约束没想清楚前不要留。3. C#条码生成与扫码解析的落地写法3.1 使用ZXing.Net生成Code128标签生成条码选ZXing.NetNuGet一条命令装完兼容.NET Framework 4.6.1和.NET 6及以上。dotnet add package ZXing.Net生成标签的核心代码只有几行var writer new BarcodeWriterBitmap { Format BarcodeFormat.CODE_128, Options new EncodingOptions { Height 80, // 像素高度打印高度建议不低于60 Width 300, // 像素宽度按标签纸宽度调整 Margin 2, // 左右白边太小时部分枪识别失败 PureBarcode true // 只画条码不画下方文字 } }; using var bmp writer.Write(WH-IN-20240715-0001); bmp.Save(label.png, ImageFormat.Png);参数有三个容易翻车的点。Margin太大会导致小标签打不全太小会让扫码枪把边缘内容读进结果Height低于40时很多低端枪无法识别也尽量别超过120否则连续打印时每张标签的间隔时间会变长PureBarcode为true时不渲染人类可读的文字实际打印建议改为false并手动在条码下方补一行SKU名称方便人工复核。编码格式的选择也有讲究。仓库内部标签用Code128就够它能覆盖ASCII全字符连字符和数字混排没问题。如果商品本身有GTIN-13条码外箱上的EAN13必须原样保留不能重新编码。两种情况并存时BarcodeWriter的Format不能写死要在生成方法里根据传入对象的产品类型分支选择。3.2 串口扫码枪的数据接收与拼接扫码枪接入有两种方式。USB键盘仿真模式最简单扫码内容等效于键盘输入焦点在哪个文本框就输入到哪里适合一个操作员一台PC的场景。RS232串口模式需要程序自己收数据工业流水线上更常见也是这套源码里SerialPort组件的用途。串口数据接收这段逻辑本质上就是C#上位机写法的标准形态。我的接收循环长这样private readonly StringBuilder _buffer new(); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { var sp (SerialPort)sender; var bytes new byte[sp.BytesToRead]; sp.Read(bytes, 0, bytes.Length); var chunk Encoding.ASCII.GetString(bytes); lock (_buffer) { _buffer.Append(chunk); var content _buffer.ToString(); var idx content.IndexOf(\r); // 枪默认以回车结尾 if (idx 0) { var barcode content[..idx].Trim(); _buffer.Clear(); Task.Run(() ProcessScannedCode(barcode)); } } }这里两个关键点要说清楚。第一缓冲区必须有串口是流式协议一次DataReceived事件拿到的字节数不保证是完整的一帧几毫秒的干扰就可能把一条码拆成两段直接Read并解析会得到残缺数据。第二以\r作为帧结束符是主流扫码枪的出厂默认值但品牌不同可能有差异有的用\n有的用\r\n建议在配置文件中把EndChar做成可选项避免换设备就改代码重编译。波特率方面绝大多数工业枪默认9600数据位8无校验停止位1。如果收到的内容是乱码先改枪的配置工具把波特率统一而不是在代码里适配多套速率。3.3 条码解析逐段拆解并容错拿到完整条码之后用一个静态解析类把它映射成业务对象public record BarcodeInfo( string Warehouse, string OpType, string Date, string Serial); public static BarcodeInfo Parse(string raw) { if (string.IsNullOrWhiteSpace(raw)) throw new FormatException(空条码); if (!raw.StartsWith(WH-)) throw new FormatException($未知前缀: {raw}); var parts raw.Split(-); if (parts.Length ! 4) throw new FormatException($条码段数不对: {raw}); return new BarcodeInfo( Warehouse: parts[0], OpType: parts[1], Date: parts[2], Serial: parts[3]); }这里用Split而不是按位Substring是因为日期段可能从8位演变为10位用分隔符解析能兼容这种变化。解析失败的条码不要静默丢弃我一般会在界面上弹出非模态警告并同时写入ParseErrorLog表记录原始字符串、扫码枪编号和时间。等到现场反馈有几把枪偶尔扫不上查这张表就能定位到是哪台设备出了问题。串口模式下偶尔混入的不可见字符也在这一步被过滤掉可以顺带计数连续超过5次就提示检查线缆。4. 核心业务入库、出库、盘点的C#事务实现4.1 入库一次扫描要完成三个动作扫码枪扫到条码后入库流程涉及三处写操作更新ProductBatch数量、更新Stock汇总、插入StockLog。这三步必须在同一个事务里完成否则任何一个应用层异常都会造成账面数量和明细流水不一致。public void ExecuteInbound(string barcode, string operatorName) { using var conn new SqlConnection(_connStr); conn.Open(); using var tx conn.BeginTransaction(IsolationLevel.ReadCommitted); try { var info BarcodeParser.Parse(barcode); var productId GetProductId(conn, tx, info); // 查SKU // 1. 锁批次行防止同SKU并发入库时写丢失 SqlCommand lockBatch new SqlCommand( SELECT BatchId FROM ProductBatch WITH (UPDLOCK, ROWLOCK) WHERE ProductId pid AND BatchNo batch, conn, tx); lockBatch.Parameters.Add(pid, SqlDbType.Int).Value productId; lockBatch.Parameters.Add(batch, SqlDbType.VarChar, 32).Value info.Date; int batchId (int)lockBatch.ExecuteScalar(); // 2. 累加批次数量 SqlCommand updBatch new SqlCommand( UPDATE ProductBatch SET Qty Qty qty WHERE BatchId id, conn, tx); updBatch.Parameters.Add(qty, SqlDbType.Decimal).Value 1m; updBatch.Parameters.Add(id, SqlDbType.Int).Value batchId; updBatch.ExecuteNonQuery(); // 3. UPSERT汇总库存并插入流水 SqlCommand upsertStock new SqlCommand( UPDATE Stock SET Qty Qty qty WHERE ProductId pid; IF ROWCOUNT 0 INSERT INTO Stock(ProductId, Qty) VALUES(pid, qty);, conn, tx); // 参数同前略 upsertStock.ExecuteNonQuery(); tx.Commit(); } catch { tx.Rollback(); throw; } }这段代码有四个细节。UPDLOCK提示让SQL Server锁定这一行直到事务结束两个扫码终端同时扫同一个批次时后到的那个事务会等前一个提交不会出现两边都读到旧数量再各自覆盖的脏写。第二步和第三步顺序不能颠倒先批次后汇总所有事务按这个固定顺序加锁就能避免死锁。AddWithValue在传入decimal时可能被推断成int导致精度丢失所以参数都显式指定了SqlDbType。最后锁批次时如果ExecuteScalar返回null说明ProductBatch中还没有这个批次正常业务逻辑此时应该先插入批次再继续。4.2 出库先进先出批次选择出库的核心不是UPDATE怎么写而是选哪批货先出。规范仓库默认FIFO同SKU多批次时先入库的那批优先扣减防止过期库存积压。SELECT TOP 10 B.BatchId, B.BatchNo, B.Qty FROM ProductBatch B WITH (READPAST) WHERE B.ProductId pid AND B.Qty 0 ORDER BY B.ExpireDate, B.BatchNo ASC;READPAST提示很关键。它让查询自动跳过那些正被其他事务锁定的批次行而不是阻塞等待这样多台PDA同时出库时不会互相卡死。程序拿到候选批次后逐行扣减每次UPDATE都检查剩余需求数量需求归零就结束如果所有批次数量加总都不够整个事务回滚并提示库存不足缺X件。批次选择还有一个业务判断要做有没有冻结批次。比如质量部门发现某批抽检不合格应该加一个IsFrozen字段在WHERE条件里排除掉。这个字段经常被遗漏一旦上了冻结批次功能所有涉及批次选择的SQL都要同步修改。4.3 盘点实盘数调整账面盘点逻辑相对简单但有一个常见的坑必须在盘点开始时冻结账面数量而不是扫一个改一个。否则盘点过程中刚入的库会被算成盘盈差异盘点结果永远不平。盘点结果差异单类型处理方式实盘 账面无记录盘点时间不做库存调整实盘 账面盘盈单增加批次和汇总数量实盘 账面盘亏单需主管二次确认后才调整库存差异单在C#里是一个带Status字段的实体待确认和已确认分开未确认前不写库存。这个规则换个角度说就是出库单可以直接更新库存盘亏单必须经过审批流。很多新人在第二周就把这条规则改没了等到审计时翻流水才发现盘亏没有审批记录。盘点的C#代码不需要特殊事务它就是生成差异单、审批后再走一次类似入库的事务。注意盘点时重扫同一条码应该只记一次界面上用最近已扫列表做去重误操作时可以反选删除。5. 从源码到运行首次配置、验证与性能调优5.1 修改连接串并初始化数据库解压源码后先打开App.config设置连接串。开发环境用LocalDB可以直接跑生产库建议只为SQL Server保留TCP/IP协议connectionStrings add nameWarehouseDb connectionStringServer.;DatabaseWarehouse;User Idsa;Password****;EncryptTrue;TrustServerCertificateTrue; providerNameSystem.Data.SqlClient / /connectionStrings首次运行前按顺序执行SQL脚本Product、ProductBatch、Stock、StockLog、Operation。注意TrustServerCertificateTrue只适用于局域网内部部署如果程序要访问公网数据库这个参数必须设为False并配置合法证书否则会触发连接加密回退的安全警告。5.2 扫码枪工作模式与焦点陷阱USB键盘仿真模式下扫码内容会进入当前焦点控件。如果焦点停在DataGridView上扫码内容可能被当成快捷键触发复制粘贴甚至衍生出空行。我一般会在扫描框GotFocus时把全局焦点强制定位并禁止用户用鼠标点击表格区域。串口模式没有焦点问题但要多做一步写一个ConnectionWatcher定时检测COM口断开仓库里员工踩掉USB线是高频故障程序要能在托盘图标上直接显示扫码枪离线。5.3 端到端自测清单与批量入库提速我用这张清单验收这套系统生成标签打印后扫描端到端耗时不超过2秒扫码识别成功率100%连续快速扫描50个条码无丢帧、无重复入库两台扫码终端同时对同一个SKU入库最终数量正确且无死锁报错批量入库时逐条ExecuteNonQuery的性能很差几千条数据会卡到用户怀疑人生。我一般先用SqlBulkCopy把数据打进临时表再用一条存储过程JOIN临时表完成批次插入和流水生成整体耗时能从十几秒降到一两秒。SqlBulkCopy的表结构要和目标临时表完全一致列顺序不同也会报错。最后补一个验证技巧断网测试。把扫码枪的USB线拔掉再插回程序应能自动重连把数据库服务停掉扫码应提示服务不可用而不是静默丢数据。这两条过了系统才算真正能落地。本文还有配套的精品资源点击获取 
长河君 · 2026/9/14 13:27:26 · 阅读 1.2k C#仓库条码管理系统实战：条码生成、扫码解析与SQL Server事务实现
简介一份面向C#毕业设计的仓库条码管理系统源码选用.NET WinForms/WPF结合SQL Server/MySQL覆盖入库、出库、库存查询、条码扫描和报表生成等仓库管理核心环节适合需要掌握C#桌面开发与数据库联调的开发者借鉴。压缩包共132个文件以47个cs源码文件为主辅以resx/resources界面资源和jpg图片素材同时含sln解决方案、config项目配置、SQL脚本以及mdf/ldf数据库文件整体约9.96MB。目前已有204人学习下载。源码中包含出入库、库存等核心窗体的Designer设计器代码并将条码解析与商品信息关联便于理解窗体布局、数据访问和条码在仓储流程中的落地方式。通过阅读项目结构与关键模块可以掌握从数据库设计到界面交互的完整开发路径对完成毕业设计或仓库类项目有直接参考价值。1. 仓库条码管理系统为什么C#仍是首选一线做仓储软件这些年我接触过不少扫码枪、PDA和后台管理程序。仓库条码管理系统的核心就三件事条码得能生成和打印扫码枪得能把条码内容干净地交给程序库存账在入库出库盘点的瞬间必须保持一致。C#在这三件事上都有成熟路径ZXing.Net负责条码渲染SerialPort接串口枪或接收键盘模拟输入SqlClient配合事务把库存操作做成原子更新。这套源码.zip解压后是典型的三层结构WinForm界面、BLL业务层、DAL数据层外加数据库脚本只要环境有.NET Framework 4.6.1以上和SQL Server就能跑。下面按数据模型设计、条码读写实现、业务事务、部署与排错四步拆开讲透。2. 数据模型先行条码编码规则与库存表结构仓储系统的稳定性七成在数据模型上。条码怎么编、库存怎么存、流水怎么记这三件事没想清楚之前先别写业务代码。2.1 条码按前缀SKU批次流水号编码常见的做法是把条码编成有意义的结构而不是随机的无意义串。比如一张入库标签的编码WH-IN-20240715-0001拆开看字段示例长度说明仓库前缀WH2-4位多仓库时用于区分物理位置作业类型IN/OUT/PD2-3位入库、出库、盘点日期码202407158位按业务发生日期而不是系统日期流水号00014位以上当天内自增跨天重置这种编码的好处是扫码枪扫到后程序不需要回表就能先在内存里判断出这是一张入库单。如果做成不透明随机串每次扫描就得查作业单表PDA在弱网环境下会明显卡顿。有个细节容易被忽略条码长度超过20位后Code128虽然能承载但打印小标签时密度过高低端扫码枪误读率会上升。所以流水号一般不超过4-6位日期码尽量用8位而不是14位时间戳。批次号我通常直接用日期码加两位序号这样FIFO出库时ORDER BY字符串就是时间顺序。2.2 五张核心表商品、批次、库存、流水、作业单我再怎么强调都不过分库存必须拆成批次表和汇总表而不是一个简单的数量字段。因为仓库条码系统里同一个SKU对应多个批次每个批次的供应商、有效期和进价都不同出库要做先进先出就必须以批次为粒度。CREATE TABLE Product ( ProductId INT IDENTITY(1,1) PRIMARY KEY, SkuCode VARCHAR(32) NOT NULL, ProductName NVARCHAR(128) NOT NULL, Unit NVARCHAR(8) DEFAULT N件, Barcode VARCHAR(32) NULL, -- 商品自带条码无需程序生成 CreatedAt DATETIME2 DEFAULT SYSDATETIME() ); CREATE UNIQUE INDEX UX_Product_Sku ON Product(SkuCode); CREATE TABLE ProductBatch ( BatchId INT IDENTITY(1,1) PRIMARY KEY, ProductId INT NOT NULL REFERENCES Product(ProductId), BatchNo VARCHAR(32) NOT NULL, -- 批次号通常沿用条码中的日期段 Location VARCHAR(16) NULL, -- 物理库位编码 ExpireDate DATE NULL, Qty DECIMAL(12,3) NOT NULL DEFAULT 0, CONSTRAINT UX_Batch UNIQUE (ProductId, BatchNo, Location) ); CREATE TABLE Stock ( ProductId INT NOT NULL PRIMARY KEY, Qty DECIMAL(12,3) NOT NULL DEFAULT 0 ); CREATE TABLE StockLog ( LogId BIGINT IDENTITY(1,1) PRIMARY KEY, ProductId INT NOT NULL, BatchId INT NULL, OpType TINYINT NOT NULL, -- 1入库 2出库 3盘点调整 ChangeQty DECIMAL(12,3) NOT NULL, -- 正数增加负数减少 RefCode VARCHAR(64) NULL, -- 关联的作业单号 Operator NVARCHAR(32) NULL, CreatedAt DATETIME2 DEFAULT SYSDATETIME() ); CREATE INDEX IX_Log_Product_Time ON StockLog(ProductId, CreatedAt); CREATE TABLE Operation ( OperationId INT IDENTITY(1,1) PRIMARY KEY, OpCode VARCHAR(32) NOT NULL, -- 对外单据号如 IN202407150001 OpType TINYINT NOT NULL, Status TINYINT NOT NULL DEFAULT 0, -- 0新建 1完成 2取消 ProductId INT NULL, Qty DECIMAL(12,3) NOT NULL DEFAULT 0, CreatedAt DATETIME2 DEFAULT SYSDATETIME() );这段SQL里有几个设计点值得说明。Product和ProductBatch分离同一个SkuCode可以持有多个批次批次表把Location纳入唯一约束是为了支持同一批次拆到两个库位的场景。StockLog只记录变更量正数入、负数出期末对账时只需要重放流水就能还原任意时点的库存。Operation表字段很少但它承担审计职能扫码类系统最怕的就是出了问题查不到执行记录。还有一个不在DDL里的约定所有数量字段用DECIMAL(12,3)不用FLOAT。条码系统里会出现按重量计价入库的场景浮点累加误差到月底盘点时会让账实差异说不清楚。DECIMAL也许写起来啰嗦但它值得。2.3 索引策略与两个并发瓶颈这套模型的并发瓶颈集中在两处。一是同一个SKU同时入库时Stock表的行锁竞争二是盘点高峰时StockLog增长过快。对第一处我的建议是不要给Stock表堆索引主键聚合索引就够了。真正的并发控制放在事务层面靠SQL Server的UPDLOCK提示详细写法见第4章。对第二处StockLog保留3-6个月更早的用后台归档作业迁到StockLogArchive避免单表过大拖慢查询。如果仓库没有库位管理需求把Location字段去掉唯一索引用(ProductId, BatchNo)就够了。加了这个字段等于引入了新的业务约束没想清楚前不要留。3. C#条码生成与扫码解析的落地写法3.1 使用ZXing.Net生成Code128标签生成条码选ZXing.NetNuGet一条命令装完兼容.NET Framework 4.6.1和.NET 6及以上。dotnet add package ZXing.Net生成标签的核心代码只有几行var writer new BarcodeWriterBitmap { Format BarcodeFormat.CODE_128, Options new EncodingOptions { Height 80, // 像素高度打印高度建议不低于60 Width 300, // 像素宽度按标签纸宽度调整 Margin 2, // 左右白边太小时部分枪识别失败 PureBarcode true // 只画条码不画下方文字 } }; using var bmp writer.Write(WH-IN-20240715-0001); bmp.Save(label.png, ImageFormat.Png);参数有三个容易翻车的点。Margin太大会导致小标签打不全太小会让扫码枪把边缘内容读进结果Height低于40时很多低端枪无法识别也尽量别超过120否则连续打印时每张标签的间隔时间会变长PureBarcode为true时不渲染人类可读的文字实际打印建议改为false并手动在条码下方补一行SKU名称方便人工复核。编码格式的选择也有讲究。仓库内部标签用Code128就够它能覆盖ASCII全字符连字符和数字混排没问题。如果商品本身有GTIN-13条码外箱上的EAN13必须原样保留不能重新编码。两种情况并存时BarcodeWriter的Format不能写死要在生成方法里根据传入对象的产品类型分支选择。3.2 串口扫码枪的数据接收与拼接扫码枪接入有两种方式。USB键盘仿真模式最简单扫码内容等效于键盘输入焦点在哪个文本框就输入到哪里适合一个操作员一台PC的场景。RS232串口模式需要程序自己收数据工业流水线上更常见也是这套源码里SerialPort组件的用途。串口数据接收这段逻辑本质上就是C#上位机写法的标准形态。我的接收循环长这样private readonly StringBuilder _buffer new(); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { var sp (SerialPort)sender; var bytes new byte[sp.BytesToRead]; sp.Read(bytes, 0, bytes.Length); var chunk Encoding.ASCII.GetString(bytes); lock (_buffer) { _buffer.Append(chunk); var content _buffer.ToString(); var idx content.IndexOf(\r); // 枪默认以回车结尾 if (idx 0) { var barcode content[..idx].Trim(); _buffer.Clear(); Task.Run(() ProcessScannedCode(barcode)); } } }这里两个关键点要说清楚。第一缓冲区必须有串口是流式协议一次DataReceived事件拿到的字节数不保证是完整的一帧几毫秒的干扰就可能把一条码拆成两段直接Read并解析会得到残缺数据。第二以\r作为帧结束符是主流扫码枪的出厂默认值但品牌不同可能有差异有的用\n有的用\r\n建议在配置文件中把EndChar做成可选项避免换设备就改代码重编译。波特率方面绝大多数工业枪默认9600数据位8无校验停止位1。如果收到的内容是乱码先改枪的配置工具把波特率统一而不是在代码里适配多套速率。3.3 条码解析逐段拆解并容错拿到完整条码之后用一个静态解析类把它映射成业务对象public record BarcodeInfo( string Warehouse, string OpType, string Date, string Serial); public static BarcodeInfo Parse(string raw) { if (string.IsNullOrWhiteSpace(raw)) throw new FormatException(空条码); if (!raw.StartsWith(WH-)) throw new FormatException($未知前缀: {raw}); var parts raw.Split(-); if (parts.Length ! 4) throw new FormatException($条码段数不对: {raw}); return new BarcodeInfo( Warehouse: parts[0], OpType: parts[1], Date: parts[2], Serial: parts[3]); }这里用Split而不是按位Substring是因为日期段可能从8位演变为10位用分隔符解析能兼容这种变化。解析失败的条码不要静默丢弃我一般会在界面上弹出非模态警告并同时写入ParseErrorLog表记录原始字符串、扫码枪编号和时间。等到现场反馈有几把枪偶尔扫不上查这张表就能定位到是哪台设备出了问题。串口模式下偶尔混入的不可见字符也在这一步被过滤掉可以顺带计数连续超过5次就提示检查线缆。4. 核心业务入库、出库、盘点的C#事务实现4.1 入库一次扫描要完成三个动作扫码枪扫到条码后入库流程涉及三处写操作更新ProductBatch数量、更新Stock汇总、插入StockLog。这三步必须在同一个事务里完成否则任何一个应用层异常都会造成账面数量和明细流水不一致。public void ExecuteInbound(string barcode, string operatorName) { using var conn new SqlConnection(_connStr); conn.Open(); using var tx conn.BeginTransaction(IsolationLevel.ReadCommitted); try { var info BarcodeParser.Parse(barcode); var productId GetProductId(conn, tx, info); // 查SKU // 1. 锁批次行防止同SKU并发入库时写丢失 SqlCommand lockBatch new SqlCommand( SELECT BatchId FROM ProductBatch WITH (UPDLOCK, ROWLOCK) WHERE ProductId pid AND BatchNo batch, conn, tx); lockBatch.Parameters.Add(pid, SqlDbType.Int).Value productId; lockBatch.Parameters.Add(batch, SqlDbType.VarChar, 32).Value info.Date; int batchId (int)lockBatch.ExecuteScalar(); // 2. 累加批次数量 SqlCommand updBatch new SqlCommand( UPDATE ProductBatch SET Qty Qty qty WHERE BatchId id, conn, tx); updBatch.Parameters.Add(qty, SqlDbType.Decimal).Value 1m; updBatch.Parameters.Add(id, SqlDbType.Int).Value batchId; updBatch.ExecuteNonQuery(); // 3. UPSERT汇总库存并插入流水 SqlCommand upsertStock new SqlCommand( UPDATE Stock SET Qty Qty qty WHERE ProductId pid; IF ROWCOUNT 0 INSERT INTO Stock(ProductId, Qty) VALUES(pid, qty);, conn, tx); // 参数同前略 upsertStock.ExecuteNonQuery(); tx.Commit(); } catch { tx.Rollback(); throw; } }这段代码有四个细节。UPDLOCK提示让SQL Server锁定这一行直到事务结束两个扫码终端同时扫同一个批次时后到的那个事务会等前一个提交不会出现两边都读到旧数量再各自覆盖的脏写。第二步和第三步顺序不能颠倒先批次后汇总所有事务按这个固定顺序加锁就能避免死锁。AddWithValue在传入decimal时可能被推断成int导致精度丢失所以参数都显式指定了SqlDbType。最后锁批次时如果ExecuteScalar返回null说明ProductBatch中还没有这个批次正常业务逻辑此时应该先插入批次再继续。4.2 出库先进先出批次选择出库的核心不是UPDATE怎么写而是选哪批货先出。规范仓库默认FIFO同SKU多批次时先入库的那批优先扣减防止过期库存积压。SELECT TOP 10 B.BatchId, B.BatchNo, B.Qty FROM ProductBatch B WITH (READPAST) WHERE B.ProductId pid AND B.Qty 0 ORDER BY B.ExpireDate, B.BatchNo ASC;READPAST提示很关键。它让查询自动跳过那些正被其他事务锁定的批次行而不是阻塞等待这样多台PDA同时出库时不会互相卡死。程序拿到候选批次后逐行扣减每次UPDATE都检查剩余需求数量需求归零就结束如果所有批次数量加总都不够整个事务回滚并提示库存不足缺X件。批次选择还有一个业务判断要做有没有冻结批次。比如质量部门发现某批抽检不合格应该加一个IsFrozen字段在WHERE条件里排除掉。这个字段经常被遗漏一旦上了冻结批次功能所有涉及批次选择的SQL都要同步修改。4.3 盘点实盘数调整账面盘点逻辑相对简单但有一个常见的坑必须在盘点开始时冻结账面数量而不是扫一个改一个。否则盘点过程中刚入的库会被算成盘盈差异盘点结果永远不平。盘点结果差异单类型处理方式实盘 账面无记录盘点时间不做库存调整实盘 账面盘盈单增加批次和汇总数量实盘 账面盘亏单需主管二次确认后才调整库存差异单在C#里是一个带Status字段的实体待确认和已确认分开未确认前不写库存。这个规则换个角度说就是出库单可以直接更新库存盘亏单必须经过审批流。很多新人在第二周就把这条规则改没了等到审计时翻流水才发现盘亏没有审批记录。盘点的C#代码不需要特殊事务它就是生成差异单、审批后再走一次类似入库的事务。注意盘点时重扫同一条码应该只记一次界面上用最近已扫列表做去重误操作时可以反选删除。5. 从源码到运行首次配置、验证与性能调优5.1 修改连接串并初始化数据库解压源码后先打开App.config设置连接串。开发环境用LocalDB可以直接跑生产库建议只为SQL Server保留TCP/IP协议connectionStrings add nameWarehouseDb connectionStringServer.;DatabaseWarehouse;User Idsa;Password****;EncryptTrue;TrustServerCertificateTrue; providerNameSystem.Data.SqlClient / /connectionStrings首次运行前按顺序执行SQL脚本Product、ProductBatch、Stock、StockLog、Operation。注意TrustServerCertificateTrue只适用于局域网内部部署如果程序要访问公网数据库这个参数必须设为False并配置合法证书否则会触发连接加密回退的安全警告。5.2 扫码枪工作模式与焦点陷阱USB键盘仿真模式下扫码内容会进入当前焦点控件。如果焦点停在DataGridView上扫码内容可能被当成快捷键触发复制粘贴甚至衍生出空行。我一般会在扫描框GotFocus时把全局焦点强制定位并禁止用户用鼠标点击表格区域。串口模式没有焦点问题但要多做一步写一个ConnectionWatcher定时检测COM口断开仓库里员工踩掉USB线是高频故障程序要能在托盘图标上直接显示扫码枪离线。5.3 端到端自测清单与批量入库提速我用这张清单验收这套系统生成标签打印后扫描端到端耗时不超过2秒扫码识别成功率100%连续快速扫描50个条码无丢帧、无重复入库两台扫码终端同时对同一个SKU入库最终数量正确且无死锁报错批量入库时逐条ExecuteNonQuery的性能很差几千条数据会卡到用户怀疑人生。我一般先用SqlBulkCopy把数据打进临时表再用一条存储过程JOIN临时表完成批次插入和流水生成整体耗时能从十几秒降到一两秒。SqlBulkCopy的表结构要和目标临时表完全一致列顺序不同也会报错。最后补一个验证技巧断网测试。把扫码枪的USB线拔掉再插回程序应能自动重连把数据库服务停掉扫码应提示服务不可用而不是静默丢数据。这两条过了系统才算真正能落地。本文还有配套的精品资源点击获取