纯C#自研生产级工作流引擎不现实，应选用WorkflowCore；它支持持久化、重试补偿、定时触发，可宿主于WorkerService等环境，但必须配置SQL Server等持久化提供程序，且人工任务需自行实现前端与状态回调。

纯 C# 实现一个生产可用的工作流引擎不现实——它不是写几个 State 类或 WorkflowRunner 就能跑起来的；真正落地时，你得面对持久化、并发调度、版本兼容、人工任务分配、超时补偿、事件监听这些硬需求。直接手撸等于重造 Windows Workflow Foundation（已废弃）+ Camunda .NET SDK 的轮子，且大概率更不稳定。

用 WorkflowCore 是当前最务实的选择

它专为 .NET Core/.NET 5+ 设计，轻量、可扩展、支持持久化（SQL Server/PostgreSQL/MongoDB）、内置重试/补偿/定时触发，API 清晰。不是“玩具”，已在中小规模业务中验证过稳定性。

• 不依赖 Windows 服务或 IIS：可宿主在 WorkerService、ASP.NET Core 或控制台中
• 流程定义用 C# 代码（非 XML/YAML），类型安全、IDE 可跳转、调试友好
• 状态迁移自动持久化，崩溃重启后能从断点继续，无需手动恢复上下文
• 自定义 IStepBody 可注入 IServiceProvider，天然支持 DI 和 Entity Framework Core

示例：一个审批流程的步骤定义

public class ApprovalStep : StepBody
{
    public override async Task<executionresult> RunAsync(IStepExecutionContext context)
    {
        var data = context.Workflow.Data as ApprovalData;
        // 调用审批服务、发邮件、更新 DB...
        await _approvalService.ApproveAsync(data.UserId, data.DocId);
        return ExecutionResult.Next();
    }
}</executionresult>

WorkflowCore 持久化必须配对使用，否则重启即丢状态

默认内存模式只适合 demo，一重启所有运行中流程全丢，且无法支持集群部署。上线前必须配置持久化提供程序。

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

• SQL Server：安装 WorkflowCore.Persistence.SqlServer 包，调用 UseSqlServer 并传入连接字符串
• 注意数据库需提前执行初始化脚本（包里带 scripts 文件夹），否则首次启动报 Invalid object name 'Workflow'
• 表名带 schema（如 [wfc].[Workflow]），若改 schema 必须同步改 UseSqlServer(..., schema: "wfc")
• 不要共用业务库：工作流表高频读写，混用易引发死锁或拖慢主业务

人工任务（UserTask）得自己搭前端 + 状态回调，引擎不提供 UI

WorkflowCore 本身没有“待办列表”“驳回按钮”这类功能——它只负责把流程推到某个 WaitFor 或自定义 StepBody，然后挂起。后续交互完全由你掌控。

• 典型做法：在步骤中保存待办人 ID 到 context.Workflow.Data，同时发消息（RabbitMQ/Kafka）或写通知表
• 前端查“我的待办” → 查你自己的 UserTask 表（含 WorkflowId、StepId、Assignee、Status）
• 用户操作后，调用你写的 API 接口，内部用 IWorkflowController.ResumeWorkflow(workflowId) 唤醒流程
• 别在 Resume 前修改 Data：并发下可能被其他线程覆盖，应先 GetWorkflowInstance 再 UpdateWorkflowData

完整源码不等于“拿来就能上线”。哪怕基于 WorkflowCore 的开源实例，你也得替换掉它的内存存储、补全异常日志埋点、加流程版本灰度开关、对接你的权限中心——工作流最难的从来不是“怎么走”，而是“走错时怎么捞、谁来兜底、审计留痕在哪”。