Angular11使用aws-amplify认证后无法获取CognitoUser对象的用户属性

你遇到的所有异常表现，都是两个核心问题叠加导致的：

对应异常的底层原因 #

• Auth.currentAuthenticatedUser() 返回的对象 session 为 null、没有 attributes 字段
  这是 aws-amplify v3.3.x 版本的缓存机制设计：该方法默认优先读取本地缓存的 CognitoUser 对象，默认不会主动调用远端接口拉取用户属性填充到 attributes 字段。当本地判定 accessToken 接近过期阈值、但 idToken 仍在有效期时，会主动将 session 字段置空，等待后续触发 token 刷新流程；此时你只能从嵌套路径 signInUserSession.idToken.payload 读到残留的 token 内容，根本拿不到完整的 attributes 集合。
• Auth.currentUserInfo() 返回空对象、idToken 里读不到 name 属性
  这是对 Cognito 配置逻辑的认知偏差：你在用户池层面开启的属性读写权限，只是允许客户端调用接口读写这些属性，不代表这些属性会被自动注入到 idToken 的 payload 中。哪些属性会进入 token，完全由「用户池客户端配置-属性读取范围」的勾选列表决定。你能读到 email，说明它已经被勾选进读范围；读不到 name，就是因为它没有被加入这个列表——哪怕把 name 设为必填，只要不在读范围里，就不会自动注入到 token 中。

实际修正操作步骤 #

1. 绕过本地缓存强制拉取完整远端用户对象
   调用 Auth.currentAuthenticatedUser() 时传入配置参数 { bypassCache: true }，强制 Amplify 跳过本地缓存，实时调用 Cognito 的 getUser 接口拉取完整的用户属性，自动填充到返回对象的 attributes 字段中，同时会把置空的 session 字段恢复正常。
2. 校验客户端的属性读范围配置
   进入用户池的客户端配置页，确认 name 属性已经被勾选到「可读属性」列表里：只有被勾选的属性，才会同时被包含在 attributes 集合和 idToken 的 payload 中。
3. 验证 currentUserInfo 的返回结果
   这个方法在 v3 版本的实现逻辑非常简单：直接提取 CognitoUser 对象里的 attributes 字段返回。只要上一步正确拉取到了带完整 attributes 的用户对象，调用该方法就会返回包含全量用户属性的非空对象，不会再出现返回空的问题。

修正后的参考代码 #

Auth.currentAuthenticatedUser({ bypassCache: true })
  .then(async (currentUser) => {
    // 此时返回的对象会包含完整的 attributes 字段，session 字段也会恢复正常
    console.log('完整用户属性集', currentUser.attributes);
    // 同步调用 currentUserInfo 可正常返回非空结果
    const userProfile = await Auth.currentUserInfo();
    console.log('整理后的用户信息', userProfile);
  })
  .catch((err) => {
    console.error('用户信息获取异常', err);
  });

注意：开启 bypassCache 会让每次调用都发送一次网络请求拉取用户属性，如果对性能敏感，可以根据业务场景选择合适的缓存刷新时机，不需要每次调用都强制绕过缓存。

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