Serverless框架下定义带GlobalSecondaryIndexes的DynamoDB部署及查询报错问题

两个连续报错完全触发于DynamoDB的硬校验规则，不存在逻辑层面的模糊空间：

• 部署阶段ValidationException：DynamoDB对属性名大小写严格敏感，表KeySchema、GSI KeySchema中引用的所有属性，必须在AttributeDefinitions中有完全一致（拼写、大小写完全匹配）的声明。你在KeySchema、GSI KeySchema中引用的属性名是UserId（首字母大写U），但AttributeDefinitions中仅声明了全小写的userId，系统判定存在未定义的键属性，直接阻断表创建流程。
• 查询阶段ValidationException：原有配置本身存在表结构设计逻辑混乱的问题——AttributeDefinitions中声明了id但未将其纳入根表KeySchema，反而引用了大小写不匹配的UserId作为根表HASH键；同时因为部署流程中断，目标GSIuserIdIndex根本没有被成功创建，查询时指定的索引不存在，系统自动回退到根表的键校验逻辑，强制要求传入根表键元素id，最终抛出校验异常。

所有改动严格对齐DynamoDB的校验规则，匹配你原本的业务设计：

documentsTable:
  Type: AWS::DynamoDB::Table
  Properties:
    AttributeDefinitions:
      - AttributeName: id
        AttributeType: S
      - AttributeName: userId
        AttributeType: S
    # 根表HASH键采用文档唯一标识id，匹配原有属性定义逻辑
    KeySchema:
      - AttributeName: id
        KeyType: HASH
    GlobalSecondaryIndexes:
      - IndexName: userIdIndex
        # GSI键属性名和AttributeDefinitions完全匹配，使用全小写userId
        KeySchema:
          - AttributeName: userId
            KeyType: HASH
        Projection:
          ProjectionType: ALL
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
    ProvisionedThroughput:
      ReadCapacityUnits: 1
      WriteCapacityUnits: 1
    TableName: ${self:custom.env}-${self:custom.prefix}-${self:custom.documentDynamoTable2}

小提示：如果业务设计本身就需要把userId作为根表的分区键，直接将根表KeySchema替换为AttributeName: userId即可，此时无需单独创建userIdIndex，直接查询根表即可按userId过滤，减少索引的资源消耗。

• DynamoDB不支持在线修改根表KeySchema、不支持无停机替换已创建的GSI。如果AWS环境中已经存在同名的历史旧表，必须先手动删除旧表再执行Serverless部署，避免新旧配置冲突导致索引创建失败。
• 原有查询代码在表结构修正后可正常运行，不需要做逻辑修改：代码中通过IndexName指定GSI后，系统会按照GSI的键schema做条件校验，不会强制要求传入根表键；代码中ExpressionAttributeNames把#userId映射为实际属性userId的逻辑，也和修正后的GSI键完全匹配。
• 部署完成后必须先到DynamoDB控制台确认userIdIndex的状态为Active，再执行业务查询，避免因为索引创建未完成触发校验异常。

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