DynamoDB 表達式建構器
挑選一個操作，以視覺化方式建構請求，然後複製一個正確、不受保留字影響的表達式 — 連同其 ExpressionAttributeNames 與 Values — 成為 AWS SDK v3、CLI、boto3 或 PartiQL。
為何手寫 DynamoDB 表達式容易出錯
DynamoDB 請求很少在明顯的部分失敗。它失敗的原因往往是 status 是保留字而需要 #-別名、是數字 id 被當成字串送出而比對不到任何項目，或是 FilterExpression 與 ConditionExpression 重用了同一個 :v0 佔位符。每一個都是小失誤，卻會產生一個能執行卻傳回錯誤列的請求 — 是最難除錯的那種。
本建構器從一個帶類型的模型組裝出整個請求。每個屬性名稱都會別名化、每個值都帶有明確的 DynamoDB 類型，而鍵、Filter、條件與更新的佔位符各自存放在獨立的命名空間，因此在結構上就不可能發生衝突。輸出是依類型標記建構，而非從你的文字猜測 — 數字維持為數字，base64 字串維持為二進位。
更新表達式與條件式寫入也比照辦理：原子式計數器、if_not_exists、list_append、對 list 索引的 REMOVE、對 set 的 ADD/DELETE，以及樂觀鎖定條件，全都組裝成一個正確的 UpdateExpression 與 ConditionExpression。PartiQL 分頁誠實以對 — 當某個原語沒有 PartiQL 形式時，它會告訴你是哪一個，而非產生一個會悄悄出錯的陳述式。
還在 Query 與 Scan 之間抉擇嗎？ Query 與 Scan 的比較 說明兩者差異，而 PartiQL 範例 深入介紹這種 SQL 風格的語法。
常見問題
什麼是 ExpressionAttributeName，以及為何要用 # 與 : 前綴？
DynamoDB 表達式無法直接引用屬於保留字的屬性名稱（例如 name、status 或 size），而值的佔位符則能讓實際資料不出現在表達式字串中。因此每個屬性名稱都會在 ExpressionAttributeNames 中以 #-佔位符別名化，每個值都會在 ExpressionAttributeValues 中以 :-佔位符別名化。本建構器會為你產生這些映射，因此保留字絕不會破壞你的請求。
為什麼我必須為每個值選擇一個類型（S、N、B…）？
DynamoDB 在屬性層級就有類型之分：數字 5 是 { "N": "5" }，而字串 "5" 是 { "S": "5" } — 是會比對到不同項目的不同值。文字輸入無法區分兩者，因此建構器會要求你為每個值標記類型。所產生的 SDK、CLI、boto3 與 PartiQL 輸出都是依該標記建構，絕不從文字猜測，因此數字 id 會維持為數字，base64 blob 會維持為二進位。
它能建構更新表達式與條件式寫入嗎？
可以。更新涵蓋 SET（包含 if_not_exists、原子式 +/- 計數器，以及 list_append）、REMOVE（包含像 #a[2] 這樣的 list 索引）、ADD（數字或 set）與 DELETE（set 成員） — 全部組合成一個 UpdateExpression。條件式寫入會在 Update、Put 或 Delete 加上 ConditionExpression 以進行樂觀鎖定（attribute_not_exists、版本檢查等等）。鍵條件與值條件使用各自獨立的佔位符命名空間，因此絕不會衝突。
為什麼 PartiQL 有時「無法表示」？
PartiQL 涵蓋大多數的讀取與寫入，但少數 DynamoDB 原語沒有 PartiQL 形式：條件式 INSERT、set 類型的 ADD/DELETE 更新動作，以及 size()、list_append 與 if_not_exists 之類的函式。當你的請求用到其中之一時，PartiQL 分頁會明確告訴你哪項功能無法表示，而非產生一個會默默做錯事的陳述式 — 那些情況請改用 SDK、CLI 或 boto3 輸出。
我的資料會離開瀏覽器嗎？
不會。建構器完全在用戶端執行 — 它在你的瀏覽器中產生表達式與程式碼片段，你輸入的任何內容都不會傳送到伺服器。URL 的「複製連結」功能會將你的請求序列化進連結本身，方便你分享或加入書籤，但那仍掌握在你自己手中。