Aptos 上的模块

Aptos 允许在包中进行无需许可的模块发布， 同时也支持对设置了适当兼容性策略的模块进行升级。

模块包含多个结构体和函数，这一点与 Rust 类似。

在包发布时，需要遵守以下约束：

• 结构体和公共函数签名都以不可变的方式发布。

`init_module` 已弃用

init_module 函数已弃用，正在被移除。请勿在新模块中使用它。应改为使用显式的 entry fun initialize 函数，由发布者在发布包之后调用来初始化模块（见下文）。

弃用原因：

• 链接语义不明确 — 升级时，init_module 属于旧代码还是新代码，语义上存在歧义。
• 无初始化顺序 — 当多个模块各自定义 init_module 时，无法保证执行顺序。
• 显著增加 VM 复杂度 — 隐式的发布时执行是 VM 必须跟踪和强制执行的特殊情况。

仍然依赖 init_module 的现有模块目前可以继续工作，但应迁移到显式初始化模式。

旧方式：init_module（已弃用）

以往，模块初始化由 init_module 函数处理：

• 当首次发布模块时（即该模块在链上不存在），VM 会查找并执行 init_module(account: &signer) 函数。
• 当升级已存在于链上的模块时，init_module 不会被调用。
• 发布账户的签名者会被传入该函数。它必须是私有的，最多接受一个 &signer 参数，不能有泛型参数，也不能返回任何值。

由于这种在发布时隐式执行的机制正在被移除，新模块应改用下面的显式模式。

推荐方式：显式的 initialize entry 函数

暴露一个 entry fun initialize，由模块发布者在发布包之后，通过单独的一笔交易调用它。为其加上保护，使它只能被发布者调用，且只能执行一次：

module my_addr::my_module {
    use std::signer;
    use aptos_framework::error;

    /// Caller is not the module publisher.
    const ENOT_AUTHORIZED: u64 = 1;
    /// Module is already initialized.
    const EALREADY_INITIALIZED: u64 = 2;

    struct ModuleData has key { /* fields */ }

    entry fun initialize(publisher: &signer) {
        assert!(signer::address_of(publisher) == @my_addr, error::permission_denied(ENOT_AUTHORIZED));
        assert!(!exists<ModuleData>(@my_addr), error::already_exists(EALREADY_INITIALIZED));
        move_to(publisher, ModuleData { /* ... */ });
    }
}

为什么需要这些保护？

init_module 会自动地、且仅执行一次地以发布者身份运行。entry 函数不会自动获得这些保证，因此需要显式地恢复它们：

• signer::address_of(...) == @my_addr 断言确保只有发布者才能初始化模块。
• !exists<ModuleData>(...) 断言确保初始化只执行一次。

注意一个操作上的差异：现在初始化需要在发布之后再发送单独的一笔交易，因此模块会有一小段“已发布但未初始化”的时间。请在发布后立即发送 initialize 调用，并让依赖它的函数断言初始化已完成。