AWS Go SDK V2：并发扮演不同角色的技术疑问

问题1：是否每个请求都需要重新加载AWS配置？ #

绝对不能修改全局共享的aws.Config变量。Gin每个请求运行在独立协程中，修改全局cfg的Credentials会直接导致并发请求的状态污染——比如请求A刚把凭证换成角色X，请求B就改成角色Y，后续请求拿到的凭证会完全混乱，无法正常工作。

正确做法是：

• 全局仅保留基础AWS配置（不带角色扮演凭证，比如区域、默认端点这类通用配置）
• 每个请求处理时，复制这份全局配置生成当前请求专属的aws.Config，再给新配置设置对应的角色扮演凭证：

// 全局初始化的基础配置（无角色扮演逻辑）
var globalAwsCfg aws.Config

// Gin请求处理函数
func roleBasedResourceHandler(c *gin.Context) {
    roleARN := c.Param("roleArn") // 从请求参数获取目标角色ARN
    
    // 复制全局配置，生成当前请求专属的配置实例
    reqSpecificCfg := globalAwsCfg
    // 基于专属配置创建STS客户端
    stsClient := sts.NewFromConfig(reqSpecificCfg)
    // 创建当前请求对应的角色凭证提供者
    roleProvider := stscreds.NewAssumeRoleProvider(stsClient, roleARN)
    // 用缓存封装提供者，优化凭证复用
    reqSpecificCfg.Credentials = aws.NewCredentialsCache(roleProvider)
    
    // 用专属配置创建业务需要的AWS客户端（比如S3、DynamoDB）
    s3Client := s3.NewFromConfig(reqSpecificCfg)
    // ... 后续业务逻辑处理
}

这种方式不需要重新加载完整的AWS配置，只是复用全局的基础配置，给每个请求生成独立的凭证配置，完全不会有状态污染的问题。

问题2：角色扮演操作是否具备线程安全性？ #

• stscreds.NewAssumeRoleProvider生成的提供者本身不是线程安全的，如果多个协程共享同一个实例，会出现竞态条件（比如同时刷新凭证时的冲突）。
• 但你用到的aws.NewCredentialsCache会对提供者做线程安全封装，CredentialsCache是完全线程安全的——它会自动处理凭证的缓存、过期刷新逻辑，保证多协程访问时的安全性。

不过要注意：每个请求必须创建自己的AssumeRoleProvider和CredentialsCache实例（就像上面代码那样），绝对不能在多个请求之间共享这些实例，这样既能彻底避免并发问题，也能保证每个请求用的是自己角色的凭证。

内容的提问来源于stack exchange，提问作者Amit