微服务数据同步需用“本地事务+外发事件”和Saga模式，禁用伪分布式事务；配置写入须加锁并保证原子性；增量同步应结合元数据与分块哈希校验。
微服务间数据同步不能靠数据库事务
单体应用里用 sql.Tx 提交多个表更新没问题，但微服务拆开后，订单、库存、用户各在不同进程、不同数据库甚至不同云区域。tx.Commit() 对其他服务完全无效。常见错误是强行封装“伪分布式事务”，结果在网络分区时卡死，或补偿没触发导致状态永久不一致。
实操建议：
• 所有跨服务写操作必须拆成「本地事务 + 外发事件」两步，本地成功后再发消息（推荐 Kafka 事务性 producer 或 pglogrepl）
• 不要手写 2PC 协调器——没有业务价值，只有运维噩梦
• 每个 RPC 调用必须带 context.WithTimeout，避免阻塞整个流程
用 Saga 模式做可追踪、可补偿的同步
Saga 是最贴近 Go 工程实践的方案：每个服务只管自己那部分，失败时按反序执行补偿动作。关键不是“多酷”，而是“每步可查、可逆、可重放”。比如创建订单 → 扣库存 → 减余额 → 发通知，其中任意一步失败，前面已成功的步骤必须回滚。
实操建议：
• 用状态机管理 Saga 流程，把 status、step、compensated_step 存进本地 DB，带 version 字段防并发覆盖
• 补偿接口必须幂等，例如 RefundBalance(ctx, orderID, amount) 内部先查是否已退过
• 不要用内存或 Redis 缓存 Saga 进度——节点重启就丢；必须落库
立即学习“go语言免费学习笔记（深入）”；
备份配置文件时并发写入会丢数据
微服务热更新配置时，多个 goroutine 同时调用 os.WriteFile 写同一个 config.bak.json，可能丢内容或写入损坏。这不是 Go bug，是没加同步控制。
实操建议：
• 用 sync.Mutex 包裹写操作，尤其在配置中心回调函数里——别只在初始化时写一次，热更新也要走同一把锁
• 统一用 os.WriteFile（非已弃用的 ioutil.WriteFile），它原子性更好且不会清空文件权限
• 写前调 os.MkdirAll 确保目录存在，否则 no such file or directory 会静默吞掉备份逻辑
• 写完立刻 os.Chmod 设为 0600，防止敏感配置被其他用户读取
增量同步必须组合元数据与内容哈希判断
只依赖 os.FileInfo.ModTime() 和 Size() 不可靠：编辑器保存延迟、NFS 时间不同步、日志轮转后大小不变等情况都会误判。全量比对又太慢。
实操建议：
• 先检查 ModTime() 和 Size() 是否都未变，若一致则跳过
• 否则对小文件算完整 sha256.Sum256，大文件用分块哈希（如每 1MB 块算一次，再对块哈希序列做最终哈希）
• 把哈希值存到本地状态文件（如 .backup_state.json），键为相对路径，下次备份前读取比对
• 同步前必须拉取目标端 Stat() 信息，若目标时间戳更新且哈希不一致，中断并报错 "target is newer, manual conflict resolution required"
真正难的不是写代码，而是定义清楚「什么算变更」「谁负责校验」「冲突时谁拍板」——这些规则一旦模糊，再多的并发控制和哈希校验都只是给错误加一层缓冲。
