Go 多云配置管理需避免全局变量和 init() 初始化，应通过结构体字段注入各云客户端，分层隔离配置来源，校验必要字段，明确错误前缀，禁用静默 fallback，并在业务层实现安全降级。
Go 本身不提供“多云配置管理”内置能力，所有云厂商 SDK（AWS、Azure、GCP、阿里云等）都是独立包，必须手动集成、抽象和协调。没有统一的 cloud.Provider 接口，强行封装容易陷入过度设计。
多云配置不能靠 global var 或 init() 加载
常见错误是把所有云客户端塞进全局变量，或在 init() 里硬编码初始化——这会让测试无法 mock、环境切换困难、启动失败时难以定位是哪个云出问题。
- 每个云客户端应作为结构体字段注入，例如
type Service struct { awsClient *aws.Client; gcpClient *gcppb.Service } - 用构造函数（如
NewService(awsCfg, gcpCfg)）按需传入已验证的配置，而不是延迟到第一次调用才初始化 - 配置加载阶段就校验必要字段：AWS 要
region和credentials，GCP 要credentials_file或token_source，缺一不可
配置来源必须分层隔离：环境 > 配置文件 > 默认值
硬编码或只读取一个 config.yaml 会导致开发/测试/生产共用同一份配置，极易误操作。真实场景中，你往往需要：
- 本地开发用 profile 文件（
~/.aws/credentials）+ 环境变量覆盖（AWS_PROFILE=dev） - CI/CD 中禁用本地文件，强制走
AWS_ACCESS_KEY_ID+AWS_SECRET_ACCESS_KEY - GCP 使用
GOOGLE_APPLICATION_CREDENTIALS指向 JSON 密钥文件，但测试时应允许用google.CredentialsFromJSON直接传入 mock token - 所有配置项最终应归一为结构体，例如
type AWSCfg struct { Region string; Endpoint string; DisableSSL bool }，避免字符串拼接或 map 嵌套
SDK 初始化失败必须提前暴露，不能静默 fallback
有些开发者会写“如果 AWS 初始化失败，就尝试用 GCP”，这在多云调度逻辑里是危险的——它掩盖了配置错误、权限缺失或网络策略问题。
