能力：key (Ability: Key)

在 Move 基礎 章節中，我們介紹了四種能力中的兩種——Drop 與 Copy。它們影響一個值在作用域內的行為，與儲存無關。現在該來談談 key 能力了——這是讓一個結構體能夠成為儲存單位的能力。

從歷史上看，key 能力最初是用來標記一個型別為_全域儲存中的鍵值_。擁有 key 能力的型別可以被儲存在頂層，並可以被某個帳戶或地址_擁有_。隨著 物件模型 的引入，key 能力成為定義_物件_的關鍵能力。

在本書中，我們將任何擁有 key 能力的結構體稱為_物件_。

物件定義 (Object Definition)

擁有 key 能力的結構體即為物件，可用於儲存函式。其定義受兩層規則約束：

• Move 語言要求 key 結構體的每個欄位都必須具備 store 能力——我們會在下一頁探討 store；
• Sui 驗證器另外要求該結構體的第一個欄位必須命名為 id，且型別為 UID。

/// An object: a struct with the `key` ability and an `id: UID` field.
public struct User has key {
    id: UID, // required by the Sui Verifier, always the first field
    name: String, // all other fields must have `store`
}

/// Creates a new `User` object. The fresh `UID` is derived from the
/// transaction context `ctx`.
public fun new(name: String, ctx: &mut TxContext): User {
    User {
        id: object::new(ctx),
        name,
    }
}

new 函式會建立該物件。全新的 UID 只能由 object::new 產生，此函式需要傳入 交易上下文 的可變參考——因此每個新建立的物件都會取得一個網路上前所未有的識別碼。我們會在 UID 與 ID 小節中更深入探討 UID 型別及其保證。

與 copy 及 drop 的關係 (Relation to copy and drop)

UID 是一個既沒有 drop 也沒有 copy 的型別。由於每個物件都必須具備 UID 欄位，而結構體只能擁有其欄位所支援的能力，這意味著物件永遠不能擁有 drop 或 copy。每個物件在結構上都是不可捨棄且不可複製的——這正是數位資產屬性所要求的。

這項特性可以在能力約束中被善加利用：要求 drop 或 copy 會自動排除物件，反過來說，要求 key 則會排除擁有 drop 或 copy 的型別。

擁有 key 能力的型別 (Types with the key Ability)

由於 UID 的要求，Move 中沒有任何原生型別能擁有 key 能力，標準函式庫中的型別也不例外。key 能力只存在於部分 Sui 框架型別以及自訂型別之中。

總結 (Summary)

• key 能力定義了一個物件。
• Sui 驗證器要求物件的第一個欄位必須是型別為 UID 的 id。
• Move 語言要求 key 結構體的所有欄位都必須具備 store。
• 物件永遠不能擁有 drop 或 copy。

下一步 (Next Steps)

key 能力定義了物件，並強制所有欄位都必須具備 store。在下一節中，我們將探討 store 能力本身——以及它對物件而言所扮演的第二種、較不明顯的角色。

延伸閱讀 (Further Reading)

• Move 參考手冊中的型別能力。