简介：一套C# MES系统源码包，基于三层架构完整呈现制造执行系统的核心设计，适合学习C#工业软件开发或需要搭建MES原型系统的开发者，尤其对生产流程管理、设备数据采集、报表可视化感兴趣的人群。压缩包共95个文件，含54个cs源码文件、24个resx界面资源、5个DLL组件（NPOI用于Excel导入导出、IrisSkin4用于界面美化）、3个SQL脚本（基础资料、查询、产线数据采集建表），另有Markdown说明文档和VS工程配置，整体仅1.81MB，目录划分明确，主控制板、数据采集、数据报表、基础资料等模块一目了然。目前已有3217人学习，源码中可以看到生产订单、工序、设备状态的实体建模，以及ADO.NET/ORM操作数据库、串口或网络通信采集PLC数据、报表生成与权限校验的具体实现，配合数据表结构可直接二次开发，是兼顾理论讲解与工程实践的C# MES参考资料。
1. 车间里最缺的不是自动化，是能看懂工单的MES：这套C#源码如何打通从排产到追溯
某个工厂车间里，计划员每天把工单从ERP导成Excel，再打印出来贴到产线上；操作工干完活再往纸质单据上填数量，质检员拿同一张单子记录抽检结果。这套C# MES系统源码就是来解决这件事的：它把工单、工艺路线、报工、质检、设备数据串在一条主线上，扫码开工、完工即报工、异常自动推送到看板。整个项目采用三层架构，前端是可直接改的MVC页面，后台是Web API和独立设备采集服务，适合想快速搭出生产管理后台的.NET开发者，也适合实施人员拿来做二次开发底子。
2. 技术架构：三层架构 + SQL Server + Redis，不复杂但够稳的组合
MES这类系统表面上是流程管理，本质上是一堆数据录入、状态变更和报表查询。用微服务反而会因为事务和管理复杂度拖慢进度。这套源码选了经典的三层架构：表现层负责页面和API入口，业务层专注工单、报工、质检等规则，数据层用仓储模式统一访问数据库，另外单独部署一个设备采集服务来对接PLC和传感器。Redis在这里不是缓存主力，主要用来存放登录会话、菜单权限和短时队列，避免频繁访问数据库。
2.1 源码目录结构：从解决方案到车间看板
拿到压缩包之后，先别急着双击 .sln，先看目录。常见的结构大致是这样：
MesSolution/ ├── Mes.Web # 表现层：MVC页面 + Web API │ ├── Controllers/ # 登录、工单、报工、大屏接口 │ ├── Views/ # 车间看板、终端操作页 │ ├── wwwroot/ # 静态资源和前端脚本 │ └── Startup.cs # 依赖注入、鉴权、SignalR配置 ├── Mes.Application # 业务层：Service和DTO │ ├── Services/ # 派工、报工、质检等业务逻辑 │ ├── Dtos/ # 接口入参和出参对象 │ └── AutoMapperProfile.cs # 实体转DTO的映射 ├── Mes.Domain # 实体类和领域逻辑 ├── Mes.Repository # EF Core DbContext、仓储、种子数据 │ ├── EntityConfigurations/ # 表映射配置 │ └── SeedData/ # 初始用户、菜单、角色 ├── Mes.DeviceCollector # 独立设备采集服务（OPC UA / Modbus） └── Mes.Shared # 日志、异常、通用工具Mes.Web是使用者直接面对的部分，车间大屏和PDA页面都在这层；Mes.Application中一个Service对应一个业务域，比如DispatchService管派工，ReportService管报工；Mes.DeviceCollector是独立进程，因为它要长时间连设备，如果和设备业务混在一起，一旦设备断开会拖垮主流程。这个结构的好处是，你改前端不碰业务层，改采集逻辑不碰数据库。
2.2 数据模型：工单、工序、报工和质量追溯怎么建表
MES的表设计围绕“一个产品走哪些工序，每道工序干了多少，是谁干的，设备和物料批次是什么”展开。最基本的是工单主表和工序明细表，工单记录计划数量、交期和状态，工序明细记录工艺路线。报工表则记录每一笔实际完工数量。下面是工单建表的精简范本：
CREATE TABLE MES_Order ( Id INT IDENTITY PRIMARY KEY, OrderNo NVARCHAR(32) NOT NULL UNIQUE, ProductCode NVARCHAR(32) NOT NULL, PlanQty INT NOT NULL, Status TINYINT NOT NULL DEFAULT 0, -- 0待派工 1生产中 2完工 PlanStartTime DATETIME, PlanEndTime DATETIME, CreatedAt DATETIME DEFAULT GETDATE() );OrderNo设计成唯一字段，是为了让扫码枪和看板都能直接定位工单。Status只有三个值，但真实项目里通常会有“已暂停”“已取消”等更多状态，这里用TINYINT而不是BIT，就是给后续扩展留空间。PlanStartTime和PlanEndTime由计划员维护，派工和看板都依赖这两个时间字段。
报工表是整条追溯链的关键，它记录哪道工序在什么时间、由谁、在什么设备上完成了多少数量，并且要关联到物料批次，这样才能在出现质量问题时反向追踪原材料来源。
CREATE TABLE MES_Report ( Id BIGINT IDENTITY PRIMARY KEY, OrderId INT NOT NULL, ProcessId INT NOT NULL, Operator NVARCHAR(50) NOT NULL, Qty INT NOT NULL, ReportTime DATETIME NOT NULL, EquipmentId INT NULL, MaterialLotCode NVARCHAR(64) NULL, FOREIGN KEY (OrderId) REFERENCES MES_Order(Id), FOREIGN KEY (ProcessId) REFERENCES MES_OrderProcess(Id) );注意ReportId用BIGINT，因为生产数据一年可积累到千万级，INT不够用。报工表里冗余了OrderId，看起来违反规范，但实际查询“某工单所有报工记录”时能省一次JOIN，这是MES报表场景下常见的取舍。质量记录表则是另一组，它保存检验结果、缺陷代码和判定结论，通常还会挂附件图片，所以图片路径或者文件Id单独放一列。
2.3 设备数据对接：OPC UA采集器和Web API的取舍
设备数据在MES里属于“锦上添花”的部分，但也是二次开发中最麻烦的部分。很多老设备只支持Modbus TCP，新设备才支持OPC UA。这套源码的处理方式是用Mes.DeviceCollector独立采集：对于支持OPC UA的设备，采集服务每隔几秒读取设备状态和产量计数；对于旧PLC，通过Modbus轮询。采集到的数据不直接写主库，而是发到Redis队列，由主API异步落库。
public async Task ReadAndPublishAsync(CancellationToken token) { var data = await _opcClient.ReadNodesAsync(new[] { "ns=2;s=Device.Count", "ns=2;s=Device.Status" }); await _redis.ListRightPushAsync("mes:device:01", JsonSerializer.Serialize(data)); }这段代码里读的节点地址是OPC UA标准的命名空间格式，ns=2是服务器索引，s=Device.Count是节点标识。实际使用时必须根据设备手册改成对应值。写入Redis而不是直接插表，是因为采集服务要保证写入的实时性，如果主库有慢查询，直接插表会阻塞采集循环，而Redis队列可以让主API按自己的节奏慢慢处理，数据丢失了也能从设备端重新读取。
3. 核心模块拆解：从扫码开工到报工入库的完整链路
前面讲清楚了整体结构，这一章把“登录-派工-报工”这条路走一遍。用户最常用的流程是：产线终端登录后看到待加工任务，点击开工，完成时扫码报工，质检通过后工单状态自动推进。这套流程里最有价值的是报工模块，因为它直接影响产量统计和工资核算，所以会对报工接口做详细拆解。
3.1 登录与权限：基于角色的菜单和按钮权限
登录不是随便校验一下用户名密码，而是要通过用户角色动态生成菜单，否则不同岗位会看到不该看的页面。源码里在登录Service里做了这样几件事：先查用户，再算密码哈希，然后加载角色对应的菜单树，最后签发JWT。
public async Task<LoginResult> LoginAsync(string username, string password) { var user = await _userRepository.FirstOrDefaultAsync(u => u.LoginName == username); if (user == null || user.PasswordHash != HashPassword(password)) return new LoginResult { Success = false, Message = "用户名或密码错误" }; var roles = await _userRepository.GetRolesAsync(user.Id); var token = GenerateJwt(user, roles); var menus = BuildMenu(roles); return new LoginResult { Success = true, Token = token, Menus = menus }; }代码里有几个容易被忽略的地方。HashPassword通常不是直接用MD5，而是加盐后用SHA256循环计算，源码里可能在加密辅助类中实现，你读代码时重点看盐值存到哪去了。BuildMenu是根据角色的菜单编号列表去数据库查菜单表，并按层级组装成树形结构，它的返回值直接给前端渲染侧边栏。很多二次开发翻车是因为只看Token是否生成，却忽略了Menus为空也会导致页面白屏。
3.2 工单下发与看板刷新：为什么用SignalR而不是轮询
车间大屏如果每秒轮询一次工单状态，几十个大屏会把数据库拖垮。这套源码用了SignalR做实时推送，工单被派工后，服务端立刻向对应车间组推送消息。下面这段是从Controller里摘出来的派工接口：
[HttpPost("Dispatch")] public async Task<IActionResult> Dispatch(int orderId) { var order = await _dispatchService.DispatchAsync(orderId); if (order == null) return NotFound(); await _hubContext.Clients.Group($"workshop:{order.WorkshopId}") .SendAsync("OrderDispatched", new { OrderNo = order.OrderNo, Status = order.Status, ProcessName = order.CurrentProcessName }); return Ok(); }SendAsync的第一个参数是前端订阅的事件名，前后端约定为“OrderDispatched”。组名设计成了workshop:{车间ID}，这样看板只需要加入自己车间的组，其他车间的推送不会干扰。选择SignalR而不是大规模引入消息队列，是因为车间大屏这种实时场景频率不高，WebSocket长连接足够支撑上千客户端，而且SignalR自带断线重连，比手写WebSocket稳定得多。
3.3 报工接口的实际代码：Controller、Service、仓储
报工是整个MES里最容易写错的部分，因为它涉及多表变更：插入报工记录、更新工单进度、判断是否完工。源码在Controller里只做参数接收，真实逻辑全部放在Service层。先看Controller入口：
[HttpPost("api/report")] public async Task<IActionResult> Report(ReportRequest request) { if (request.Qty <= 0) return BadRequest("报工数量必须大于0"); var result = await _reportService.CreateReportAsync(request); return Ok(result); }Controller只做模型绑定和基本校验，避免把业务规则堆在API层。然后看Service里的核心逻辑：
public async Task<ReportResult> CreateReportAsync(ReportRequest request) { using var tx = await _db.Database.BeginTransactionAsync(); try { var process = await _processRepository.GetByIdAsync(request.ProcessId); if (process == null) throw new BusinessException("工序不存在"); var order = await _orderRepository.GetByIdAsync(process.OrderId); if (order.Status == OrderStatus.Finished) throw new BusinessException("工单已完工，不能继续报工"); var report = new Report { OrderId = order.Id, ProcessId = process.Id, Operator = request.Operator, Qty = request.Qty, ReportTime = DateTime.Now, EquipmentId = request.EquipmentId, MaterialLotCode = request.MaterialLotCode }; await _reportRepository.AddAsync(report); var progress = _orderRepository.GetDoneQty(order.Id) + request.Qty; if (progress >= order.PlanQty) order.Status = OrderStatus.Finished; else order.Status = OrderStatus.Producing; await _orderRepository.UpdateAsync(order); await _db.SaveChangesAsync(); await tx.CommitAsync(); return new ReportResult { ReportId = report.Id, Finished = order.Status == OrderStatus.Finished }; } catch { await tx.RollbackAsync(); throw; } }这段代码是MES报工的标准写法，有几个细节值得注意。首先用了显式事务，因为插入报工和更新工单状态必须保证同生共死，否则会出现数量对不上。其次是先查工序再查工单，这个顺序很重要，它让数据库锁定顺序固定，能有效降低并发死锁。最后是完工判定直接用累加的完工数量和计划数量比较，而不是用报工次数，因为允许超额报工的项目需要使用不同的判断逻辑。在实际运行中，如果发现报工非常频繁，可以在这里加一个内存缓存或者Redis锁，但最简单的还是让SQL Server行锁去处理。
4. 本地跑起来：环境准备、数据库初始化和启动顺序
从源码到能浏览，中间隔着环境配置、数据库脚本和几个配置文件。这一章按照实际操作顺序走一遍，每一步都说明为什么这么做，遇到问题优先看哪个日志。
4.1 开发环境：VS、SQL Server、Redis，一个都不能少
这套源码的目标框架是.NET 6或更高版本，用Visual Studio 2022打开最省事，如果没有完整版，用.NET SDK加VS Code也能编译，但调试API还是VS顺手。数据库方面需要SQL Server 2019以上版本，Express版也可以，但Express默认实例名带LOCALDB，连接串要对应改。Redis在Windows下建议用官方移植版或者Memurai，如果实在不想装，也可以先跳过，登录会慢一点，但不会崩溃，源码里通常会有启用Redis的开关。
环境准备清单可以简化为：VS 2022、SQL Server、Redis、可选安装SQL Server Management Studio。我一般会先把SQL Server的混合认证打开，因为源码的默认连接串写的是sa账号，如果你不会改连接串，这一步能帮你省掉后续一堆问题。
4.2 数据库脚本：建库、初始化表和种子数据
数据库初始化是这套源码能否跑起来的关键。压缩包里通常会有database/init.sql文件，里面包含CREATE DATABASE建库语句、所有表结构以及初始菜单和账号。用SSMS打开脚本后，先别直接按F5，确认当前连接的不是某个正式环境数据库。正确做法是新建查询窗口，执行前先选中master库，让脚本自己建库并切换，这样无论执行多少次都不会污染已有数据。
sqlcmd -S . -U sa -P your_password -d master -i database/init.sql上面这条命令在命令行也能执行，-d master表示先连到master库，脚本内部会创建MesDb并切换。执行完后打开SSMS刷新一下，应该能看到MesDb和几十张MES_开头的表。种子数据里一般包含一个管理员账号，用户名和密码通常在README或者init.sql注释里，常见的是admin/123456。如果脚本执行报错，不要立刻改脚本，先看是不是权限问题，或者某张表已经在数据库里存在。
4.3 配置文件：连接字符串和Redis
源码里最常改的文件是Mes.Web/appsettings.json。默认配置可能是针对开发机写的，你要改成自己本机实际的数据库密码和Redis地址。下面是精简后的模板：
{ "ConnectionStrings": { "Default": "Server=.;Database=MesDb;User Id=sa;Password=your_password;TrustServerCertificate=True;" }, "Redis": { "ConnectionString": "127.0.0.1:6379,password=,defaultDatabase=0" }, "Jwt": { "Key": "replace-with-your-own-key", "ExpireDays": 7 } }Server=.表示本机默认SQL Server实例，如果你用的是命名实例，要写成Server=你的机器名\实例名。TrustServerCertificate=True是SQL Server 2019之后比较需要的项，否则本地自签名证书会报错。Redis的ConnectionString如果本机没设密码，password后面留空就行。Jwt的Key如果带着默认值，生产环境有被伪造的风险，本地跑可以不管，但上生产必须改掉。
4.4 启动顺序与验证：先API后Web，还是先采集器
启动顺序有讲究。如果解决方案里同时有Mes.Web和Mes.DeviceCollector两个项目，先把Mes.Web设为启动项目，因为它会启动MVC页面、API和SignalR服务。等浏览器能打开登录页再启动采集器，否则采集器连接不到数据库会频繁写错误日志。
具体验证步骤是：启动后打开首页，如果跳转到登录页说明前端和应用都正常；用种子账号登录后，应该能看到工单管理、报工管理、看板等菜单。随便新建一张工单，派工后打开看板页面，能看到工单卡片出现，说明JWT认证和SignalR链路都通。最后再启动Mes.DeviceCollector，如果设备模拟器没开，它会尝试重连但不影响主功能。这一步验证完毕后，整个系统才算真正跑起来。
5. 避坑与排查：跑MES源码最容易翻车的5个位置
从实操经验看，跑这种完整源码项目，80%的问题出在环境配置，而不是代码逻辑。下面这5个坑是我在复现时最常遇到的，每一条都按现象、原因、解决的结构说明。
5.1 初始化脚本报“对象名无效”
现象是执行init.sql时，前面的建表语句失败，提示“对象名无效”或者“数据库中已存在名为XXX的对象”。原因通常是脚本里用了USE MesDb，但直连的数据库不对，导致后续建表跑到其他地方。解决方法是执行前在SSMS工具栏把当前数据库切到master，然后检查脚本开头是否有IF DB_ID('MesDb') IS NULL CREATE DATABASE。如果脚本多次重复执行，要先在脚本顶部加一句处理旧库的判断，或者手动删除MesDb再执行。
5.2 登录成功后页面白屏，接口返回403
现象是登录接口返回Token成功，但跳转后菜单加载不出来，打开浏览器开发者工具能看到多个API请求返回403。原因是JWT密钥或者用户角色缓存对不上。常见的情况是Redis里缓存了旧数据，而数据库种子数据里的菜单ID已经变了，导致构建菜单树时引用为空。解决办法是登录接口里把Menus逻辑走一遍，看返回的菜单树是否为空；同时清空Redis缓存键，比如删除以“mes:user:”开头的所有键，然后重新登录。
5.3 SignalR一直重连，看板不刷新
现象是页面其他功能正常，只有看板区域在浏览器Console里反复打印SignalR连接失败。原因基本是跨域策略没有放行SignalR地址，或者反向代理不转发WebSocket请求。如果是本地跑，确认Startup.cs里CORS配置的AllowAnyHeader、AllowAnyMethod，并且AllowCredentials()开了；如果用了IIS或Nginx，要在代理配置里加上Upgrade和Connection头的转发。这个坑最大的特点是现象比问题难定位，因为浏览器不会把WebSocket握手失败直接显示出来。
5.4 报工时偶发死锁，数据库日志报“事务死锁”
现象是产线同时在多个终端报工时，有一两个请求会等十几秒然后报错。原因是报工逻辑中不同SQL的执行顺序不一致，或者说某个事务更新了多个表却各自持锁。解决办法是把报工Service里的查询顺序固定成“先查工序表、再查工单表、最后插入报工”，并且在查询工单时使用WITH (UPDLOCK)来提前加锁，这样并发事务会排队而不是互相等待。另外检查是否在事务里调用了外部API或大量查询，事务时间越长锁竞争越剧烈。
5.5 设备采集服务一启动就退出
现象是Mes.DeviceCollector启动后日志停在“正在连接OPC UA服务器”，几秒后进程退出。原因多半是OPC UA证书信任或者模拟器地址错误。如果源码自带模拟器，先启动模拟器，再启动采集器；如果连真实设备，要检查安全策略是否设置为None，匿名连接是否开启。解决方法是把采集服务配置里的EndpointUrl改成模拟器实际地址，比如opc.tcp://127.0.0.1:48010，并把SecurityPolicy设置为None，暂时绕开证书问题，跑通后再谈安全。
6. 二次开发思路：加一个设备报修模块，从建表、API到前端页面
把现有源码跑通之后，下一步通常就是加功能。这里以“设备报修”为例，完整走一遍从数据库到接口再到页面的改造路径，这也是MES二开中最常见的需求。整个过程不需要修改原有核心表，新增表加新接口即可，风险很小。
6.1 先加表和种子数据
设备报修需要记录报修设备、报修原因、状态和创建时间。在数据库里新建一张表，遵循现有MES_前缀命名习惯：
CREATE TABLE MES_RepairOrder ( Id INT IDENTITY PRIMARY KEY, EquipmentId INT NOT NULL, Reporter NVARCHAR(50) NOT NULL, Description NVARCHAR(500) NOT NULL, Status TINYINT NOT NULL DEFAULT 0, -- 0待处理 1处理中 2已完成 CreatedAt DATETIME DEFAULT GETDATE() );建表时不加外键约束到MES_Equipment，因为报修单需要保留历史快照，即使设备后来被删除，维修记录还要能查出来。这也是为什么这里只存EquipmentId，不强制外键。
6.2 写一个Service和Controller
参考现有模块，新建一个RepairOrderService，构造函数注入仓储，业务方法保持简单：
public class RepairOrderService { private readonly IRepository<RepairOrder> _repository; public RepairOrderService(IRepository<RepairOrder> repository) { _repository = repository; } public async Task<RepairOrder> CreateAsync(RepairCreateDto dto) { var repair = new RepairOrder { EquipmentId = dto.EquipmentId, Reporter = dto.Reporter, Description = dto.Description, Status = 0, CreatedAt = DateTime.Now }; await _repository.AddAsync(repair); return repair; } }Service构造函数只依赖仓储接口，没有直接依赖DbContext，这样后续要加缓存或消息通知，不用改调用方。然后Controller只需要一个POST方法：
[HttpPost("api/repair")] public async Task<IActionResult> CreateRepair(RepairCreateDto dto) { var result = await _repairService.CreateAsync(dto); return Ok(result); }如果项目里用了反射批量注册，Service构造函数会自动被DI容器扫描到，不需要在Startup手动注册。我一般会把这套约定用起来，因为每次加模块只需要写类，不用到处改配置。
6.3 复用现有页面模板
前端不用从零写一套，现有工单列表页的表格和弹窗模板可以直接复用。步骤是先看Views里哪个页面结构最简单，比如报工记录页，复制它的cshtml到Repair文件夹，替换表格列和表单字段。然后去菜单表里增加一条记录，父级指向设备管理，权限菜单树会自动通过角色关联显示出来。如果登录后看不到新菜单，记得清掉Redis缓存重新登录。整个过程改完，刷新页面就能看到一个可用的报修列表，剩下要补的是通知和看板角标，这两个逻辑可以挂到SignalR已有通道上。
从那以后我每次拿到新源码，都会先泡在数据库脚本和配置文件里，把初始化、启动顺序、Redis缓存这三步跑通，确认一切脱离文档也能复现，再开始动业务代码。报修模块就是这么一点点加出来的，这套思路无论换到哪个MES源码都能套，希望帮到你。
本文还有配套的精品资源，点击获取
