go语言无内置2pc支持，需手动组合rpc、超时、日志持久化与状态机；database/sql和sqlx仅支持单库事务，缺乏跨节点prepare接口与协调器控制能力，无法保证原子性。
Go 语言本身不提供两阶段提交（2PC）的内置实现，也没有标准库支持分布式事务协调器；你必须自己组合 net/rpc、context、超时控制、日志持久化和状态机逻辑来构建一个可用的 2PC 参与者或协调者。
为什么不能直接用 database/sql 或 sqlx 做 2PC
因为 database/sql 的 Begin()、Commit()、Rollback() 是单数据库事务语义，无法跨多个独立 DB 实例或微服务达成原子性。一旦某个参与者提交成功而其他失败，就出现数据不一致 —— 这正是 2PC 要解决的问题，而不是绕过它。
-
sql.Tx不会自动传播到其他节点，也无法被外部协调器控制 prepare/commit 阶段 - 没有
Prepare()接口暴露给上层，无法在“预提交”阶段让 DB 持有锁并返回 yes/no - 即使手动调用
SAVEPOINT，也无法保证跨节点的持久化可见性与崩溃恢复能力
协调者必须持久化事务状态（否则一崩就丢状态）
协调者不是无状态服务 —— 它必须把每个全局事务的 ID、当前阶段（init → prepare → commit/abort）、各参与者的响应结果写入本地可靠存储（如 BoltDB、SQLite 或 WAL 日志文件），否则进程重启后无法继续推进或回滚。
- 推荐用
os.OpenFile(..., os.O_CREATE|os.O_APPEND)写结构化日志行，每行 JSON 记录一次状态变更 - 避免内存中只存
map[string]*TxState：crash 后所有进行中的事务变成“幽灵事务”，既不能确认也不能清理 - 如果用 SQLite，需开启
PRAGMA synchronous = FULL和PRAGMA journal_mode = WAL确保 fsync 安全
参与者要实现幂等的 prepare/commit/rollback 接口
网络可能重传请求，所以每个接口都得能安全重入。例如 Prepare(txID string) 返回 YES 后，再次收到相同 txID 的 Prepare 必须返回相同结果，且不能二次加锁或写临时表。
- 用本地磁盘文件记录已 prepare 的
txID（如/var/run/2pc/prepare/tx_abc123），存在即 YES，不存在才真正执行业务检查 -
Commit(txID string)和Rollback(txID string)都要先查该txID是否已终态（committed/aborted），是则直接返回 - 不要在
Prepare中做耗时操作（如远程调用、大事务查询），它必须快，否则拖慢整个 2PC 流程
Go 的 context.WithTimeout 是协调者推进流程的生命线
每个 RPC 调用（尤其是 Prepare）必须带超时，否则一个卡住的参与者会让整个事务无限挂起。但超时 ≠ 立即 abort：协调者需进入“不确定状态”，先记日志，再异步轮询该参与者最终结果。
- 对每个参与者调用
participant.Prepare(ctx, txID)，其中ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 若超时，协调者记录 “participant-A timeout at prepare”，然后发
Commit或Abort给其他已响应节点，最后单独重试 A - 不能因为一个节点超时就立刻全局 abort —— 它可能只是网络抖动，实际已 prepare 成功
真正难的不是写通流程，而是处理 coordinator crash + participant crash + 网络分区三者任意组合下的状态收敛。日志格式设计、本地状态机跃迁规则、以及“如何判断一个参与者是否还活着”——这些细节没写进任何 Go 教程里，但决定了你的 2PC 是玩具还是能上线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
