我帮你梳理下这个问题的核心原因和解决办法，你遇到的情况大概率是配置冲突导致的：

关键问题点：profile参数优先级高于硬编码凭证 #

当你在初始化S3Client时同时指定了'profile' => 'default'和硬编码的credentials，AWS SDK会优先加载凭证文件中default配置的凭证，完全忽略你硬编码的内容——这就是为什么之前用凭证文件正常，硬编码却失效的原因。

修正后的配置方案 #

方案1：移除profile参数，使用数组形式硬编码凭证

直接删掉profile配置项，确保SDK使用你提供的硬编码密钥：

use Aws\S3\S3Client;

$s3Client = new S3Client([
    'region' => 'us-west-2',
    'version' => '2006-03-01',
    'scheme' => 'http',
    'credentials' => [
        'key' => '你的AWS Access Key ID', // 替换为实际密钥
        'secret' => '你的AWS Secret Access Key' // 替换为实际密钥
    ]
]);

方案2：使用Credentials类显式初始化凭证（更明确）

如果你想更清晰地控制凭证来源，可以直接实例化Credentials类传入：

use Aws\S3\S3Client;
use Aws\Credentials\Credentials;

// 先创建凭证实例
$credentials = new Credentials(
    '你的AWS Access Key ID',
    '你的AWS Secret Access Key'
);

// 初始化S3客户端
$s3Client = new S3Client([
    'region' => 'us-west-2',
    'version' => '2006-03-01',
    'scheme' => 'http',
    'credentials' => $credentials
]);

额外注意事项 #

• 确保生产服务器上的.aws/credentials文件已经被移除或重命名，避免SDK意外读取旧凭证。
• 强烈不推荐在生产环境硬编码凭证——这种方式会把敏感密钥暴露在代码中，存在极大安全风险。后续建议改用：
  • 运行在AWS服务（如EC2、EKS）上的服务器：使用IAM角色自动获取凭证
  • 其他环境：通过环境变量AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY传递凭证

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