Temporal 适合需要强一致性、跨服务协调的长时工作流
如果你的工作流涉及多个微服务调用、需要精确重试语义、状态持久化到秒级精度，或要求“断电后自动续跑”，
Temporal是更底层也更重的选择。它把工作流逻辑本身当作可恢复的程序（用
Workflow类 +
Activity方法建模），所有暂停/恢复/超时/重试都由服务端调度器保证。比如一个订单履约流程：扣库存 → 调物流API → 等签收回调 → 补发 → 开票，中间任何一步失败都能从断点继续，且历史轨迹完整可查。
实操注意点：
Temporal SDK for .NET要求工作流方法必须是
static、无副作用、只调用
Workflow.Sleep或
Workflow.ExecuteActivity；不能直接写 DB 或发 HTTP 本地开发需启动
temporal-server（Docker 最简），否则
WorkflowClient连不上会抛
ConnectionFailedException调试困难：工作流代码实际在服务端沙箱中执行，
Console.WriteLine不输出到本地终端，得靠
Workflow.GetLogger+ 日志系统聚合
Hangfire 更适合单体或简单分布式场景下的定时/延迟/后台任务
如果你只是想让某个
SendEmailAsync方法在 5 分钟后执行，或每小时跑一次数据清理，且不关心跨节点状态同步、也不需要在任务中途挂起等待外部事件（比如人工审核、第三方 webhook），
Hangfire上手快、集成轻、监控直观。
常见问题与建议：
默认使用 SQL Server 或 Redis 持久化，但SqlServerStorage在高并发写入时可能因锁表导致任务堆积，建议开启
DashboardOptions的
DisplayStorageConnectionString = false防泄漏 延迟任务（
BackgroundJob.Schedule）依赖轮询机制，最小精度约 15 秒，无法做到秒级触发；若需精确到秒，得换
Hangfire.MemoryStorage（仅开发用）或自行扩展 异步方法必须标记为
async Task，但 Hangfire 默认不 await —— 必须显式用
await Task.Run(() => ...)包裹，否则会提前标记为完成
两者不能混用同一个存储后端
Temporal和
Hangfire的元数据结构完全不同：
Temporal存的是工作流执行树、事件日志、任务令牌；
Hangfire存的是
JobJSON、
State变更记录、
Counter统计。强行共用 Redis 或 SQL Server 会导致互相污染甚至崩溃。
正确做法：
用Temporal时，所有协调逻辑走
temporalio/temporal官方后端，业务代码只引用
Temporalio.Client用
Hangfire时，独立配
GlobalConfiguration.Configuration.UseXXXStorage(...)，避免和主业务 DB 共享连接字符串 如果已有 Hangfire 且想渐进迁移部分流程到 Temporal，不要试图桥接两者——用
Hangfire触发
Temporal的
StartWorkflow即可，保持边界清晰
性能与运维成本的真实差异
不是“谁更快”，而是“谁更扛得住复杂度”。
Hangfire单节点每秒能处理几百个短任务，但一旦工作流分支多、等待时间长、失败率高，Dashboard 就会卡顿，重试策略也难定制；
Temporal天然支持水平扩展，百万级工作流实例下仍能维持低延迟，但代价是必须维护
temporal-server集群（至少 3 节点）、理解
Visibility配置对查询性能的影响、以及接受首次部署的陡峭学习曲线。
示例：一个需等待外部支付回调（最长 24 小时）+ 自动取消 + 补单 + 对账的订单流程
public static async Task<OrderResult> ProcessOrder(WorkflowContext context, OrderInput input)
{
var result = await Workflow.ExecuteActivity<PaymentActivity>(
x => x.Charge(input.OrderId),
new ActivityOptions { StartToCloseTimeout = TimeSpan.FromMinutes(2) });
if (result.Status == "pending")
{
await Workflow.Sleep(TimeSpan.FromHours(24)); // 暂停，不占线程
result = await Workflow.ExecuteActivity<CheckPaymentActivity>(x => x.Verify(input.OrderId));
}
if (result.Status != "success")
throw new ApplicationFailure("Payment failed", "PAYMENT_FAILED");
return await Workflow.ExecuteActivity<FulfillActivity>(x => x.Ship(input.OrderId));
}
这段代码在 Temporal 中可运行数天不掉线，在 Hangfire 里只能拆成多个
ContinueWith任务链，中间任意一环失败就得手动修复状态，且无法原子性回滚已发货动作。
真正容易被忽略的点：Temporal 的
Workflow方法不能有静态变量或单例依赖，每次恢复都是新实例；而 Hangfire 的
IJobActivator注入生命周期管理稍宽松，但若用了
AddScoped服务，在延迟任务中会报
Cannot resolve scoped service—— 这类陷阱往往在线上压测时才暴露。
