企业官网建设流程全解析

做制造业ERP和做通用进销存、做电商后台完全是两码事。我接手过好几套制造业ERP项目，有做机械加工的、有做电子组装的，也做过注塑车间的。说实话，踩过的坑比走过的桥还多——倒不是技术多难，难的是制造业业务本身太复杂：物料要追溯、工单要排产、设备要采集数据、品质要管控批次。这些业务逻辑叠在一起，对系统架构的要求就完全不一样了。这篇内容围绕“制造业ERP系统架构与C#实现思路”展开，把我实际操盘这类项目时的架构决策、技术选型、核心代码思路和常见坑一次性整理出来。适合正在做或准备做制造业ERP的 .NET 工程师、想从传统进销存转型做生产管理的开发者，以及公司内部要上ERP项目的技术负责人参考。

1. 制造业ERP到底在管什么

1.1 和传统进销存软件的本质区别

很多团队一开始会犯同一个错误：把制造业ERP当成一个大号的进销存来做。进销存的核心是“账”——采购单、销售单、库存单，把单据录好，账就平了。但制造业ERP的核心是“物和账的一致性”，管的是物料在整个生产过程中的流动：原材料什么时候到、领出去多少、哪个工单用了、半成品放在哪个工序、成品入了哪个仓位，每一笔和实际动作必须对得上。

举个例子，传统进销存里，“领料”就是一个出库单据。但在制造业ERP里，领料要关联生产工单，要按BOM（物料清单）定额控制，超领要走审批，余料要退回，报废要单独记录，半成品入库要带工序信息。这些业务动作如果只停留在“记账”层面，车间根本不敢用——因为账和实物永远对不上。

所以做这类系统，第一件事不是写代码，而是把业务流程梳理清楚。我一般会先做一轮现场调研，把仓库、车间、品质、采购、计划这几个关键岗位都聊一遍，画出业务流程图，再动架构。这一步省不掉，省了后面返工的成本远大于前期投入。

1.2 制造业ERP的四大核心业务域

制造业ERP虽然模块很多，但真正核心的业务域就四个，其他都是围绕它们展开的：

这四个域之间是强耦合的。BOM不准，MRP排出来的计划就是废纸；工单执行没记录，品质追溯就断链；报工数据不准，成本核算就是一笔糊涂账。架构上如果把这几个域的数据割裂开各自为政，最后一定会有大量跨模块的“手工台账”出现，也就是用户私下用Excel在那补数据。

这也是为什么我一直建议：制造业ERP的架构设计，首要目标是保证核心业务域的数据模型统一和流程闭环，而不是过早追求技术上的花哨拆分。

2. 系统架构选型：为什么我不建议一上来就上微服务

2.1 模块化单体：前两年的最优解

每次聊架构，总有人问“要不要上微服务”。我的回答很直接：如果你的用户规模撑不到上千人同时在线、业务复杂度撑不到几十个独立团队并行开发，微服务只会给你带来痛苦，不会带来收益。

制造业ERP的特点是事务性强、模块间关联紧密。一个领料动作要同时扣库存、登记工单用料、记录批次追溯，这几个操作必须在一个事务里完成。微服务把库存服务和工单服务拆开之后，本地事务就变成了分布式事务，要么引入消息队列做最终一致性，要么做Saga，复杂度直线上升。我见过一个项目，硬上微服务拆了十几个服务，结果最核心的“报工+库存扣减”接口因为要在两个服务之间协调，定义了一堆补偿逻辑，最后生产一上线，数据对不上，天天在补单。

所以我现在操盘这类项目，前两年一律推荐“模块化单体”架构：整个系统一个应用，但在代码层做好模块边界，将来真要拆微服务，可以按模块一个包一个包地拆出去。这样既保证了事务的强一致性，又保留了后续演进的余地。

2.2 分层架构与项目结构

模块化单体内部的分层，我的习惯是标准的四层，外加一个共享内核：

ERP.Web 表示层（ASP.NET Core Web API + Blazor WebAssembly） ERP.Application 应用层（用例编排、DTO、命令/查询处理） ERP.Domain 领域层（实体、领域服务、仓储接口） ERP.Infrastructure 基础设施层（EF Core、Redis、第三方对接） ERP.Shared 共享内核（通用工具、枚举、扩展方法）

这四层之间有严格的依赖规则：Web只引用Application，Application只引用Domain，Infrastructure引用Domain并实现仓储接口。Domain层不依赖任何框架和基础设施，这样才能保证核心业务逻辑的稳定。

有人觉得四层架构老土，但ERP这种业务密集型系统要的就是稳定和可测试性。领域层把BOM展开、MRP运算、工单状态流转这些核心逻辑写清楚，用单元测试把边界条件都测到位，比你用什么花哨的架构模式都管用。

2.3 领域划分与核心表设计

在模块化单体里，模块之间的边界通过代码上的命名空间和禁止跨模块引用（除了Shared）来控制。我会在Application层按模块分文件夹，但数据库层面是共用一个库的，这样事务还能保住。

核心表设计有几个关键点必须提前定下来：

• 所有表必须有主键、创建时间、更新时间、创建人、更新人，制造业ERP的数据审计需求很重，后面的追溯全依赖这些字段。
• 涉及数量的字段全部用decimal，禁止用float。BOM用量、库存数量、工单数量如果用浮点数，累计误差经过几个月就会大到离谱。
• 状态字段用int枚举，比varchar更可控、更省空间，结合状态机统一管理。
• 物料主数据、BOM等需要带生效版本，用“生效日期+版本号”的复合条件查询，避免后期做历史追溯时抓瞎。

举个具体例子，BOM表我当时的设计是：

BOM_Header（BOM单头）：BOM编号、物料ID、版本号、生效日期、失效日期、状态 BOM_Detail（BOM单行）：BOM编号、子件物料ID、用量、损耗率、工序序号

这样一份BOM就是一个头加多行明细，版本靠“物料ID+版本号”唯一约束来管。后续做MRP展开或者做成本核算，直接用物料ID关联到对应生效版本即可。

3. C#实现中的几个核心环节

3.1 物料清单的递归展开与成本汇总

BOM展开是制造业ERP最经典的算法题，没有之一。一个成品经过多级加工，每一级都有子件，子件下面还有子件，展开时要按层级把所有物料汇总，还要带上每层的数量系数。

比如产品A由1个部件B和2个零件C组成，部件B又由3个零件D组成，那展开结果就是：需要1个B、2个C、3个D。如果BOM有几十层，中间还有损耗率，手工算就疯了。

在C#里实现，我一般用递归方法加字典缓存，避免重复计算：

public class BomExpander { private readonly Dictionary<string, List<BomDetail>> _bomCache; private readonly Dictionary<string, decimal> _resultCache = new(); public BomExpander(Dictionary<string, List<BomDetail>> bomCache) { _bomCache = bomCache; } // 返回物料ID -> 总用量 public Dictionary<string, decimal> Expand(string parentMaterialId, decimal quantity = 1m) { var result = new Dictionary<string, decimal>(); ExpandLevel(parentMaterialId, quantity, result, new HashSet<string>()); return result; } private void ExpandLevel(string parentId, decimal qty, Dictionary<string, decimal> result, HashSet<string> visited) { if (!_bomCache.TryGetValue(parentId, out var details)) return; foreach (var det in details) { // 考虑损耗率：实际用量 = 理论用量 * (1 + 损耗率) decimal required = qty * det.UsagePerParent * (1m + det.ScrapRate); if (!result.ContainsKey(det.ChildMaterialId)) result[det.ChildMaterialId] = 0m; result[det.ChildMaterialId] += required; // 防止循环BOM（A包含B，B又包含A）导致的死循环 if (visited.Contains(det.ChildMaterialId)) continue; visited.Add(det.ChildMaterialId); ExpandLevel(det.ChildMaterialId, required, result, visited); visited.Remove(det.ChildMaterialId); } } }

这里有两个关键点，是我踩过坑之后才明白的：

第一，损耗率不是只在最底层加，而是每一层都要按数量系数累乘。很多新手只算最后汇总时加一次，结果采购的数永远差一截。

第二，循环BOM一定存在。设计上虽然不允许，但老系统导过来的数据经常有环。所以递归里必须用visited集合防止死循环，否则一个接口就能把IIS打挂。

3.2 工单状态机设计

制造业工单从创建到关闭，状态流转非常严格。最常见的一条主线是：

已创建 → 已排产 → 已下达 → 生产中 → 已完工 → 已关闭

但中间还有一堆分支：下达后可能被暂停，生产中可能被部分完工，品质检验不合格可能被冻结。如果这些状态流转在代码里散着写，用一堆 if/else 判断，后期加一个状态，所有相关接口都要翻一遍。

我的做法是用一个简单状态机把这些流转统一管理起来。不夸张地说，状态机是制造业ERP里性价比最高的设计模式之一。

public enum WorkOrderStatus { Created = 1, Scheduled = 2, Released = 3, InProduction = 4, Completed = 5, Closed = 6, Suspended = 7, Frozen = 8 } public class WorkOrderStateMachine { private static readonly Dictionary<(WorkOrderStatus, WorkOrderEvent), WorkOrderStatus> _transitions = new() { [(WorkOrderStatus.Created, WorkOrderEvent.Schedule)] = WorkOrderStatus.Scheduled, [(WorkOrderStatus.Scheduled, WorkOrderEvent.Release)] = WorkOrderStatus.Released, [(WorkOrderStatus.Released, WorkOrderEvent.Start)] = WorkOrderStatus.InProduction, [(WorkOrderStatus.InProduction, WorkOrderEvent.ReportFinish)] = WorkOrderStatus.Completed, [(WorkOrderStatus.Completed, WorkOrderEvent.Close)] = WorkOrderStatus.Closed, [(WorkOrderStatus.Released, WorkOrderEvent.Suspend)] = WorkOrderStatus.Suspended, [(WorkOrderStatus.Released, WorkOrderEvent.Freeze)] = WorkOrderStatus.Frozen, // 恢复等更多流转... }; public static WorkOrderStatus Next(WorkOrderStatus current, WorkOrderEvent evt) { if (_transitions.TryGetValue((current, evt), out var next)) return next; throw new InvalidOperationException($"非法状态流转: {current} -> {evt}"); } }

这个方案的妙处在于：所有合法流转集中在一个表里，新增状态只需要改这一个字典，而且非法流转会在第一时间抛异常暴露问题，而不是默默地在某个角落被忽略。后来做权限控制，也是基于这个状态机做扩展的：某个操作只允许该状态下的用户执行，判断逻辑清晰多了。

3.3 车间报工的高并发与乐观锁

制造业ERP里并发冲突最严重的场景就是车间报工。几十个工人同时用扫码枪报工，同一张工单、同一道工序，好几台设备同时提交产量数据。如果直接用UPDATE WorkOrder SET FinishedQty = FinishedQty + @qty WHERE Id = @id，并发是没问题，但数据库行锁会激烈竞争，高峰期甚至会把工单表打爆。

更麻烦的是，报工不只是更新工单，还要扣减在制库存、记录工序流转日志、算工时。这四五个操作必须保证一致性。我的方案是两步走：

第一步，使用rowversion（时间戳）做乐观锁。每次读取工单时带上当前版本号，更新时在 WHERE 条件里带上版本号，如果影响行数是0，说明被别的线程抢先改了，让用户重新刷新再提交。

// Entity public class WorkOrder { public long Id { get; set; } public decimal FinishedQty { get; set; } public byte[] RowVersion { get; set; } // SQL Server rowversion } // Update var result = await db.WorkOrders .Where(w => w.Id == cmd.Id && w.RowVersion == cmd.OriginalVersion) .ExecuteUpdateAsync(s => s .SetProperty(w => w.FinishedQty, w => w.FinishedQty + cmd.Qty) .SetProperty(w => w.RowVersion, w => SqlServerDbFunctionsExtensions.NewRowVersion()));

第二步，报工接口在数据库层面用存储过程或一个单独的事务包裹，保证工单更新、库存扣减、日志写入在同一次数据库事务里完成。如果其中任何一步失败，整个事务回滚，不会出现“工单更新了但库存没扣”这种数据不一致。

这里有一点要提醒：虽然C#的TransactionScope很方便，但如果你用的是EF Core，多张表更新时要注意它默认开启的隐式事务。高并发场景下事务持有时间越长，锁冲突概率越大。实际操作中我会把事务范围控制在“读到的数据尽量少、更新的数据尽量直接”，不要在一个事务里再去查其它表，查了就加锁，加了锁别人就得等。

3.4 与设备数据采集的对接

制造业ERP和纯软件项目最大的不同，就是它要跟车间里五花八门的设备打交道。

工单在某个工序开工时，常常需要从设备上读取加工参数或产量数据。常见的对接方式有几种：PLC通过Modbus TCP把数据吐出来、设备自带OPC UA服务、或者设备厂商提供专用的DLL/SDK。我做过的项目里，Modbus TCP 和 TCP Socket 裸协议对接的情况最多。

以 Modbus TCP 为例，用 C# 实现一个简单的读取方法并不复杂：

public class ModbusTcpClient : IDisposable { private readonly TcpClient _client; private ushort _transactionId = 0; public ModbusTcpClient(string ip, int port) { _client = new TcpClient(); _client.Connect(ip, port); } // 读取保持寄存器 public ushort[] ReadHoldingRegisters(byte unitId, ushort startAddress, ushort count) { var request = BuildReadRequest(unitId, startAddress, count); _client.GetStream().Write(request, 0, request.Length); var response = ReadResponse(); // 解析返回值（实际项目中还要校验事务ID、功能码错误标志等） var result = new ushort[count]; for (int i = 0; i < count; i++) { result[i] = (ushort)((response[9 + i * 2] << 8) | response[10 + i * 2]); } return result; } }

但这里有个很深的坑：TCP 长连接读取设备数据，如果用同步的Read方法，一个设备卡住（不响应）就能把整个后台线程拖死。所以生产环境我用的是异步回调模式（参考那篇关于C# Socket BeginReceive回调的文章）——设备在线就正常收数据，设备离线了一段时间就自动标记状态，不阻塞主流程。

另一个经验是：设备采集服务不要和ERP主程序放在同一个进程里。我在架构里一直把设备采集拆成独立的 Windows 服务或后台 Worker Service，通过消息队列（简单场景用阻塞队列或Channel）把数据推给ERP主程序。这样设备端的抖动不会拖垮主系统的API。

4. 数据导入、缓存与日志的实战方案

4.1 大批量BOM导入：SqlBulkCopy的正确用法

制造业ERP上线初期，最大的数据迁移工作量往往就是BOM导入。几千上万条BOM明细，用EF Core一条条Add+SaveChanges，那速度能让你怀疑人生——每一行都会有实体追踪、状态检测、SQL生成，一万条数据能跑十几分钟。

正确做法是用SqlBulkCopy直接走数据库的批量导入通道。我在项目里的一个封装如下：

public async Task BulkInsertAsync(DataTable table, string destinationTableName) { using var bulk = new SqlBulkCopy(_connection) { DestinationTableName = destinationTableName }; bulk.BulkCopyTimeout = 300; bulk.BatchSize = 1000; foreach (DataColumn col in table.Columns) { bulk.ColumnMappings.Add(col.ColumnName, col.ColumnName); } await bulk.WriteToServerAsync(table); }

用的时候，先把BOM数据组装成一个DataTable（列名和目标表一致），然后一次性导入。一万条明细导入时间通常在几秒到十几秒之间，比EF Core快两个数量级。

但要注意几个细节：

• SqlBulkCopy默认不触发触发器和外键约束，所以目标表的业务校验要在写入前完成。比如子件不存在、用量为负数这些，必须在DataTable组装阶段就过滤掉。
• 如果BOM表有自增主键，SqlBulkCopy时主键列不要带上，或者用KeepIdentity = false。
• 大批量写入会造成日志文件暴涨，测试环境你可能没感觉，生产环境要把恢复模式设为简单模式，或者导入完成后做一次日志收缩。这个我吃过亏——一次导入把生产库日志文件干到几十GB，磁盘直接满了。

4.2 缓存策略：哪些数据值得缓存

ERP系统的特点是读多写少的数据特别多。物料主数据、BOM定义、工艺路线、单位换算率，这些数据一天变不了一次，但每次报工、排产、算成本都要查。如果每次都打数据库，再好的硬件也扛不住。

我常用的缓存策略分三层：

• 第一层：静态字典类数据（物料单位、仓库列表、状态枚举），启动时一次性加载到内存，用ConcurrentDictionary维护。
• 第二层：BOM、工艺路线这类变化不频繁但量大的，用IMemoryCache加过期时间缓存，过期时间一般设30分钟到1小时。
• 第三层：报表统计、看板数据，用Redis做分布式缓存，因为这类数据多个API节点可能需要共享。

重点说一下IMemoryCache在工厂环境里的一个坑：车间现场网络环境不稳定的情况很常见，API节点可能有多个（负载均衡部署）。如果一台API节点更新了物料数据，另一台节点的内存缓存还是旧的，就会出现“明明改了价格，那边还是老价格”的诡异问题。所以我后来统一建议：凡是会跨节点修改的数据，一律用Redis做缓存，内存缓存只放纯只读的字典数据。取舍很简单——一致性要求高的走Redis，数据准确度要求不高的走MemoryCache。

4.3 日志与异常处理：别把所有日志都塞进文本文件

C#项目里日志框架我推荐 Serilog，因为它可以把结构化日志直接写到数据库、Elasticsearch、文件多种目标。制造业ERP的日志需求比较特别：除了记录系统运行异常，还要记录业务操作日志来做审计。

结构化的关键，是把上下文信息一起记录下来。比如记录一个“报工失败”的日志，光有一句话没用，必须包含：工单号、操作员、报工数量、当前工单状态、错误堆栈。这样排查问题时你才能快速定位，而不是去翻数据库。

Log.Logger = new LoggerConfiguration() .MinimumLevel.Information() .WriteTo.Console() .WriteTo.File("logs/erp-.log", rollingInterval: RollingInterval.Day) .WriteTo.MSSqlServer(_connectionString, sinkOptions: new MSSqlServerSinkOptions { TableName = "Sys_Log", AutoCreateSqlTable = true }) .Enrich.WithProperty("Application", "ERP") .CreateLogger();

我踩过的一个实际教训是：车间报工高峰期日志量非常大，如果把所有Information级日志都写进数据库，数据库很快就会被日志表拖垮。最后我们只把Warning以上级别写到数据库，普通操作日志写文件，关键业务审计（领料、入库、报工）单独写一张独立的审计表。这样既不影响性能，审计用途的数据也不会被系统日志淹没。

5. 常见问题排查实录

5.1 并发死锁：接口突然变慢的元凶

制造业ERP里死锁最常见的场景就是：多个接口同时更新同几张表，但更新顺序不一致。比如接口A先更工单再更库存，接口B先更库存再更工单，并发时就容易互相等锁，SQL Server检测到循环等待后会杀掉其中一条事务，客户端直接报死锁错误。

排查方法很直接：启用 SQL Server 的跟踪标志 1222 来捕获死锁图，然后分析死锁图里两个事务的资源申请顺序。修复方案也很粗暴：统一所有接口的更新顺序，先更工单、再更库存、再更日志，全局一致，死锁概率大幅下降。

实测下来，这个操作解决了我们项目里90%的死锁问题，剩下10%是某些报表的长事务和写事务冲突，后来把报表改成读已提交快照（RCSI）隔离级别就解决了。

5.2 库存数据和实物对不上

这个问题的根源几乎永远是流程没闭环。最常见的是“边角料”处理：一个领料工单定额是100kg，实际用了85kg，剩15kg车间直接扔到料箱里没做退库操作，ERP库存就比实物少了15kg。这种情况系统再强大也没用，必须靠管理动作约束。

我做过的一个有效改进，是在库存事务类型上做强制：所有库存变化必须关联业务单据（领料单、退料单、报工单、请检单），不允许任何“零散调库”的操作入口。盘点时的盈亏也必须走独立的“盘点调整单”流程，带审批。这样库存的每一笔变动都能溯源，账实不一致的排查范围就缩小了。

5.3 报表越跑越慢的优化思路

制造业ERP跑一段时间后，报表慢是必然的。工单明细表、库存流水表动辄几百万行，按日期过滤的月度生产报表用EF Core直接查，一次查询拖到五秒以上，看板页面基本没法用。

我的优化优先级是：

1. 先看执行计划，加索引。绝大多数慢查询是缺索引，不是SQL写法问题。
2. 高频报表用物化视图或者定时任务预计算，把结果集缓存到一张汇总表。
3. 不再被实时查询的旧数据，迁移到历史库。比如超过两年的已完成工单，移到归档表。

这五个是制造业ERP项目里最常见的性能问题，基本按这个表排查一圈，大多数性能投诉都能兜住。

5.4 关于防止反编译的提醒

C# 编译出来的 DLL 很容易被反编译，这在制造业ERP这种会上部署到甲方机房的项目里是个现实问题。如果不想让客户把代码拿走，至少要做两件事：一是用混淆器（比如 ConfuserEx）处理核心业务DLL；二是核心算法和业务规则尽量放在服务端，客户端只做扫码和展示，减少暴露面。但有一点要认清：混淆只能提高门槛，不能完全阻止逆向。真正值钱的是业务逻辑和行业经验，代码本身反而没那么容易被同行直接抄走，因为它揉合了你们对制造流程的理解。

6. 验收上线前别忘的几件事

6.1 数据迁移验证

上线前一定要做一次完整的数据迁移演练，而且要用生产环境的数据量来测，不要用测试库里那几千条数据。我见过最惨的一次：迁移脚本在测试库跑5分钟，生产库跑完用了一个半小时，直接在切换窗口内把上线流程拖崩了。

BOM、库存余额、未完工工单这些核心数据的迁移，要做到“迁移后唯一性校验”和“总量对账”。比如库存迁移完，要按物料分类汇总和原系统做个对账，差一分钱都不能上线。

6.2 权限与审计

制造业ERP的权限粒度要比普通管理系统细得多。不同车间主管只能看自己车间的工单，采购员只能改自己负责的采购单，质检员只能录入自己工序的检验结果。这些权限如果不在架构阶段预留，后面加会非常痛苦。

我一般会建立一个“角色-权限-数据范围”的三级模型，数据范围决定“能看哪些”，功能权限决定“能做什么”。项目做好后，在后台管理界面上，两种权限要能分别配置，理由很简单——同一个“仓库主管”角色，在不同工厂可能管着不同的仓库。

6.3 验收清单：照着一条条过

每次上线前，我都会让测试团队拿着下面的清单过一遍，虽然简单但非常有效：

• 每个核心业务动作，在系统里能否找到对应单据和操作日志
• 库存余额在任何业务发生时，是否保持动态一致（不出现负数库存）
• 工单状态是否不可能出现“已完成”又继续报工的非法路径
• BOM变更后，已下达的工单是否按旧版本执行（不能自动用新BOM）
• 断电或网络中断后，系统能否通过日志和事务机制恢复到一致状态

这几条看着简单，但每一条背后都是一个“血泪故事”。比如BOM变更那条，如果按下达时间直接取最新版本，车间可能用新材料做出了客户不要的老产品，报废一批，哭都来不及。

最后的几点体会

做制造业ERP这几年，我最大的体会是：这个领域的技术难点从来不在“怎么写代码”，而在于“怎么把制造业的复杂性装进一个可靠、可维护、可演进的系统里”。C#/.NET 在这个领域其实非常有优势——强类型、成熟生态、EF Core 和性能工具链都很完善，加上 .NET 原生支持 Windows 生态，和车间很多 Windows 工控机对接非常顺。但工具再好，架构决策失误了也白搭。我的建议很朴素：先把业务吃透，再谈技术。先做好模块化单体，再考虑要不要上微服务。先保证事务一致和数据可追溯，再去追求华丽的技术栈。这一套做下来，系统可能不够“炫”，但一定够稳——制造业要的就是稳。最后再分享一个小技巧：C#里部署ERP到客户机房时，用 Costura.Fody 把依赖的DLL合并进主程序，发布就变成一个文件，客户升级的时候直接替换exe，省掉一大堆“少了个DLL跑不起来”的售后工单。这种事看着不起眼，但在项目上线初期能给你省至少几十个技术支持的夜晚。