AWS Cognito adminSetUserPassword报UserNotFoundException问题咨询

看起来你遇到了一个挺棘手的奇怪问题——明明用户确实存在，其他管理员级接口都能正常操作，但唯独adminSetUserPassword报错说用户不存在。我给你梳理几个可能的排查方向和解决方案：

1. 先锁定Username参数的一致性 #

Cognito的用户名在部分场景下是大小写敏感的，虽然adminDeleteUser这类接口可能在处理时兼容了大小写差异，但adminSetUserPassword的校验逻辑可能更严格。建议你：

• 在调用前后打印$email变量的日志，对比和adminDeleteUser等成功接口传入的$email是否完全一致（包括大小写、有没有隐藏的空格或特殊字符）
• 尝试强制统一$email的格式，比如转为小写并去除首尾空格后再调用：

$normalizedEmail = strtolower(trim($email));
$this->client->adminSetUserPassword([
    'Password' => $password,
    'Permanent' => true,
    'UserPoolId' => $this->poolId,
    'Username' => $normalizedEmail,
]);

2. 验证用户池中的实际用户名 #

有时候用户池的用户名可能不是你默认认为的邮箱——比如用户是通过第三方身份提供商注册，或者用户池配置了自动生成UUID作为用户名，邮箱只是用户的附加属性。虽然你其他接口用邮箱能成功，但还是建议去Cognito控制台：

• 找到该用户，查看其Username字段的实际值，确认和你传入的$email完全匹配
• 如果用户名确实不是邮箱，需要改用控制台显示的实际用户名调用adminSetUserPassword

3. 用AWS CLI直接测试，排除代码层面问题 #

试着用AWS CLI直接调用admin-set-user-password命令，用和代码中完全相同的参数：

aws cognito-idp admin-set-user-password --user-pool-id YOUR_POOL_ID --username YOUR_EMAIL --password "NEW_PASSWORD" --permanent

• 如果CLI调用成功，说明问题出在你的代码里（比如$email变量被意外修改、SDK参数传递异常）
• 如果CLI也抛出同样的错误，那可能是用户池配置或用户状态的问题，比如用户存在但处于某种特殊状态（可以去控制台查看用户的状态，比如是否被标记为待验证等）

4. 检查AWS SDK版本和权限 #

• SDK版本：旧版本的AWS PHP SDK可能存在adminSetUserPassword的兼容问题，建议更新到最新版的v3 SDK：

composer require aws/aws-sdk-php:^3.200

• IAM权限：虽然其他接口能成功，但还是确认一下你的IAM角色是否包含cognito-idp:AdminSetUserPassword权限——有时候权限策略可能漏掉了这个动作，导致调用失败

5. 检查用户的特殊状态 #

如果用户是刚创建的，或者曾经被修改过状态（比如处于FORCE_CHANGE_PASSWORD状态），虽然理论上adminSetUserPassword应该能正常设置密码，但还是可以尝试先通过adminInitiateAuth触发一次认证，再设置密码，看看是否能解决问题。

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