The provided starting key is invalid

TL;DR — 你的 ExclusiveStartKey 與你正在分頁的物件的鍵模式不匹配。它必須恰好包含 DynamoDB 在 LastEvaluatedKey 中返回的鍵屬性——完整的主索引鍵，加上你查詢 GSI/LSI 時的索引鍵——名稱和型別都相同。把 LastEvaluatedKey 原樣傳回；手工拼裝它正是這出錯的地方。

這是什麼意思

ValidationException: The provided starting key is invalid

ValidationException: Exclusive Start Key must have same size as table's key schema

ExclusiveStartKey 告訴一個 Query/Scan 從哪裡恢復。DynamoDB 會根據表的鍵模式——或者對於索引查詢，LastEvaluatedKey 攜帶的組合索引鍵加表鍵——來驗證它。缺少屬性、多餘屬性、名稱錯誤或型別錯誤都會在讀取任何資料之前失敗。

為什麼會發生

只用分割區索引鍵手工構建鍵——一個複合鍵表在起始鍵中需要分割槽_和_排序索引鍵。
只用表鍵對索引分頁——GSI/LSI 查詢上的 LastEvaluatedKey 同時包含索引鍵屬性和表的主索引鍵；它們全都必須傳回。
型別或名稱漂移——鍵被序列化了（JSON、URL 引數、快取）並帶著 "42" 回來，而 LastEvaluatedKey 裡是一個數字，或者帶著一個改了名的欄位。
跨查詢複用鍵——把來自一張表/索引的 LastEvaluatedKey 傳給了針對另一個的查詢，或者在鍵模式假設改變之後傳給了同一個查詢。
一個封裝注入了預設值——一個 ODM 填入它以為屬於鍵的屬性，會把起始鍵撐過模式大小。

如何修正

原封不動地往返 LastEvaluatedKey：

let ExclusiveStartKey;
do {
  const page = await docClient.send(
    new QueryCommand({
      TableName,
      KeyConditionExpression,
      ExpressionAttributeValues,
      ExclusiveStartKey
    })
  );
  items.push(...(page.Items ?? []));
  ExclusiveStartKey = page.LastEvaluatedKey; // verbatim — no rebuild
} while (ExclusiveStartKey);

如果它跨越請求邊界就無損地序列化它——當分頁遊標去往瀏覽器又回來時，編碼整個 LastEvaluatedKey 物件（例如其 JSON 的 base64），而不是從項目欄位重建它，並保持數字型別仍為數字。
為索引分頁包含每個鍵屬性——索引分割區索引鍵/排序索引鍵_和_表分割區索引鍵/排序索引鍵，與返回的完全一致。
不要捏造一個起始點——DynamoDB 分頁沒有偏移量；如果你需要"從 X 附近開始"，就在 KeyConditionExpression（sk > :x）中表達它，而不是手工製作一個 ExclusiveStartKey。

檢查你的表或索引的 LastEvaluatedKey 實際包含什麼，能免去猜測——DynoTable 桌面應用會翻頁瀏覽查詢並顯示原始遊標，而 DynamoDB Expression Builder 會圍繞它組合查詢請求。

在 DynoTable 中查詢

翻閱 DynoTable 中的 Query 並檢查頁面之間的原始 LastEvaluatedKey 遊標 — 使用 ⌘K 開啟表，執行 Query，然後將分頁標記逐字複製到 SDK 迴圈中。查詢面板準確顯示 DynamoDB 期望的關鍵屬性。使用 Query Builder 生成具有正確 ExclusiveStartKey 處理的分頁 Query 程式。使用 ⌘P 切換設定檔案； 在“設定”→“設定檔案”上測試連線。參見連線 AWS和安裝。

來源

Paginating table query results in DynamoDB（2026-07-13 驗證）
Query — Amazon DynamoDB API Reference（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。