Go多云管理核心是封装各云SDK+统一资源模型+事件驱动的异步状态同步；需接口化provider、标准化资源ID、用云事件+轮询兜底、显式限流与错误分类处理。
Go 语言本身不提供多云抽象层，必须依赖第三方 SDK 或统一 API 网关；直接用 golang 写多云管理，核心是「封装各云厂商 SDK + 统一资源模型 + 异步状态同步」，不是写个 CLI 就算完成。
用 Terraform Provider 模式组织 Go 代码结构
硬编码 AWS/Azure/GCP 客户端会导致维护爆炸。推荐按 Terraform Provider 的思路分层：一个 provider 接口定义 Create/Read/Update/Delete 方法，每家云实现一个 awsProvider、azureProvider 等。
- 避免在业务逻辑里直接 import
github.com/aws/aws-sdk-go-v2/service/ec2，而是通过接口调用provider.CreateInstance(...) - 各 provider 实现需处理认证差异：AWS 用
credentials.NewStaticCredentialsProvider，Azure 用azidentity.NewClientSecretCredential，GCP 用option.WithCredentialsFile - 资源 ID 命名需统一：比如都用
cloud://aws/us-east-1/i-12345格式，而不是混用i-12345、/subscriptions/xx/resourceGroups/yy/providers/Microsoft.Compute/virtualMachines/zz
资源状态同步必须用事件驱动 + 最终一致性
轮询各云 API 查状态既慢又贵，且无法感知实时变更。真实生产环境必须结合云厂商的事件通知能力（如 AWS EventBridge、Azure Event Grid、GCP Pub/Sub）做异步同步。
- 启动时从各云拉取全量资源快照，写入本地
etcd或 PostgreSQL（带updated_at时间戳） - 监听云事件：AWS 中订阅
EC2 Instance State-change Notification，Azure 中监听Microsoft.Compute.VirtualMachines.Write，GCP 中订阅compute.instances.insert - 事件回调中只更新本地 DB 的
status和updated_at，不执行实际操作 —— 控制流和数据流分离 - 配一个后台 goroutine 每 5 分钟扫一次 DB 中
updated_at < now() - 10m的资源，触发Read回刷，兜底防事件丢失
并发控制与限流必须显式编码
多云 API 对 QPS 极其敏感：AWS EC2 默认 5 req/s，Azure Resource Manager 是 12k req/5min（≈40 req/s），GCP Compute 是 1500 req/h（≈0.4 req/s）。不加限流，go run main.go 一键删 100 台机器可能直接触发账号冻结。
立即学习“go语言免费学习笔记（深入）”；
- 每个 provider 初始化时绑定独立的
rate.Limiter，例如：limiter := rate.NewLimiter(rate.Every(2*time.Second), 1)
- 所有 SDK 调用前加
limiter.Wait(ctx)，不要依赖 SDK 自带重试（它不解决限流问题） - 批量操作（如查 50 个实例状态）必须用
errgroup.Group控制并发数，例如限制最多 5 个 goroutine 同时发请求 - 错误处理要区分：HTTP 429 是限流，401/403 是凭证失效，404 是资源已删 —— 不同错误走不同恢复路径
多云不是把三个云 SDK 并排放一起就叫“统一”，真正的难点在资源生命周期语义对齐（比如 Azure 的 deallocated 和 GCP 的 STOPPED 是否等价）、事件可靠性保障、以及跨云故障隔离。这些没法靠框架自动解决，得在 Go 代码里一行行写判断和 fallback。
