C# 中无法原生实现分布式事务，System.Transactions 仅包装 Windows 的 MSDTC，受限于平台与网络配置；跨平台场景应采用 Saga 模式等应用层一致性方案。
分布式事务在 C# 中根本不能“原生实现”
别被标题误导——C# 语言本身不提供分布式事务的底层实现，System.Transactions 只是包装了 Windows 的 MSDTC（Microsoft Distributed Transaction Coordinator）服务，而 MSDTC 仅限 Windows Server / Windows Desktop 环境，且默认禁用、依赖网络端口（如 135、动态 RPC 端口）、要求域环境或复杂防火墙配置。跨 Linux 容器、K8s、云函数、HTTP 微服务等场景下，TransactionScope 直接抛 TransactionManagerCommunicationException 或静默降级为本地事务。
TransactionScope + MSDTC 的启用与踩坑点
如果你确实在单机或多台 Windows 服务器上跑 SQL Server + WCF/NetTcp 服务，并想走传统 DTC 路线，必须手动开启并调校：
- Windows 服务
MSDTC必须设为自动启动并运行（非“已禁用”） - 控制面板 → 管理工具 → 组件服务 → 计算机 → 我的电脑 → 右键“属性” → “MSDTC”选项卡 → 点“安全配置”：勾选
允许远程客户端、允许远程管理、允许入站/出站；取消勾选要求验证（否则跨机器需 Kerberos 配置） - SQL Server 连接字符串中必须显式包含
Enlist=true（默认值是true，但显式写更保险）；若用 Entity Framework Core，需确保DbContext构造时传入的DbConnection未提前打开（否则无法 enlist） -
TransactionScope必须用TransactionScopeOption.Required，且嵌套时注意IsolationLevel一致，否则抛InvalidOperationException：“The transaction manager has disabled its support for remote/network transactions.”
替代方案：Sagas 模式才是现代 C# 微服务的务实选择
真正跨平台、可观测、能补偿的分布式一致性，靠的是应用层编排，不是 DTC。常见组合：
- 使用
MassTransit+RabbitMQ或Apache Kafka实现基于消息的 Saga：每个服务提交本地事务后发命令，失败时发补偿命令（如CancelOrderCommand），状态机由SagaRepository持久化到数据库 - 手写轻量 Saga：用一张
SagaInstance表存当前步骤、业务 ID、状态、重试次数；每步执行前查表判断是否已成功，避免重复；超时未完成则触发定时任务扫表补偿 - 避免“两阶段提交幻想”：不要试图用
TransactionScope包裹 HTTP 调用（如调HttpClient.PostAsync），它对非DbConnection或MessageQueue资源无效，只会让事务范围空转
EF Core 中“伪分布式”常见误用
很多人以为 SaveChangesAsync 提交多个 DbSet 就是分布式事务——其实只是单数据库内的本地事务。真正陷阱在于：
- 跨 DbContext 实例（哪怕连同一库）：
new DbContext()默认不共享事务，需手动传入DbTransaction - 混合数据库类型（SQL Server + PostgreSQL）：EF Core 不支持跨 Provider 事务，
TransactionScope在此场景下会静默回退为各自本地事务，数据不一致风险极高 - 异步操作混用：在
TransactionScope内调用未 await 的 async 方法，或用了ConfigureAwait(false)，可能造成上下文丢失，事务提前提交
跨库一致性只能靠最终一致性+幂等+重试，没有银弹。Saga 的复杂度藏在状态流转和异常分支里，而不是代码行数上。
