从订单长事务踩坑复盘：工作流编排到底该上 Temporal 还是自研 DB+MQ 状态机？

聊聊长周期工作流选型：Temporal 还是「老三样」DB + MQ 自研状态机？

最近帮隔壁组看跨日履约和退款清算的架构，又遇到了这个后端绕不开的宿命题：长周期异步工作流，到底该不该上 Temporal / Cadence？

老王当年在支付团队搞跨境结算（流程拉长到 T+7 甚至 T+14）时，也是坚定的「DB 状态表 + MQ + 定时任务扫表」党。结果业务迭代两年的因果链大家都懂： 业务加场景 -> 状态枚举从 5 个膨胀到 30+ 个 -> 补偿分支散落在各个 Consumer 里 -> 遇到网络抖动并发重试，MQ 乱序直接干出 MySQL 行锁竞争超时 -> 最终导致单子卡在幽灵状态，每周五半夜拉群写 SQL 订正数据。

后来尝试用 Go 写 Temporal，它的设计哲学确实击中痛点：

1. 代码即流程：把复杂的异步编排写成直观的同步代码，Saga 补偿逻辑内聚，不用到处埋钩子；
2. 状态自动持久化：重试、超时、Timer 都是 First-class citizen，再也不用自己写 Delay Queue 和状态轮询。

但 Temporal 也绝对不是银弹，我们在预发环境也踩出过新坑： 新人不理解 Event Sourcing 的 Replay 机制 -> 在 Workflow 逻辑里写了非确定性代码（比如直接读系统时间或随机数） -> 灰度发版直接触发 Non-Deterministic Error，工作流全线卡死。更别提底层还要吃一套集群运维的成本。

想听听社区里做交易、计费或复杂履约的兄弟们聊聊： 你们现在是宁可忍受自研状态机的「代码屎山」，还是咬牙上了 Temporal / Cadence？生产环境真的省心了吗，还是多供了一尊随时可能报警的「运维大佛」？