用途
该技能提供一份面向 AI 的完整迁移手册，用于将 Motoko 项目从 mo:base 迁移到 mo:core。它按阶段组织迁移流程，并给出重命名映射、数据结构变更、验证脚本与代理策略，帮助在大量文件的项目中系统化完成迁移。
主要能力
- 版本与依赖准备：要求 dfx 0.31+，在 mops.toml 中添加 core = "2.2.0"，将 moc 更新为 "1.3.0"，若存在 wasmtime 则升级到至少 "42.0.1"；在 Phase 5 完成前不要移除 base 依赖。
- dfx.json 配置：每个 canister 设置 wasm_memory_persistence: keep。
- 机械重命名（Phase 1–2）：导入 mo:base/* → mo:core/*（含例外），类型专用导入优先使用 mo:core/Types，方法重命名如 .vals() → .values()、Debug.trap → Runtime.trap 等。
- 数据结构迁移（Phase 3）：Buffer → List（可变，add() 返回 void）、HashMap/TrieMap → Map（可变，add() 返回 void，Map.size(map)）、TrieSet → Set（可变，add() 返回 void），并消除所有 “:= Map.add/List.add/Set.add”。
- persistent actor（Phase 4）：actor → persistent actor（包括 actor class）。
- 移除 mo:base（Phase 5）：仅在零引用且所有 canister 构建通过后执行。
- 稳定布局与升级（Phase 6）：保持稳定序列化数组兼容，或使用 with migration = 语法；使用 wasm_memory_persistence keep 测试本地升级。
- 验证与签收：逐个构建 canister、运行正则审计、比较 DID 接口、执行本地升级测试。
使用方式
按 6 个阶段推进：Phase 1 导入重命名（含 mo:base/ExperimentalCycles → mo:core/Cycles、mo:base/List → mo:core/pure/List 等特殊情形）；Phase 2 函数重命名（如 Array.append → Array.concat、Array.init(size, val) → VarArray.repeat(val, size) 参数顺序反转、Iter.range(a, b) → Nat.range(a, b + 1) 等）；Phase 3 数据结构迁移；Phase 4 转换为 persistent actor；Phase 5 移除 mo:base；Phase 6 稳定变量迁移。
验证使用 grep 审计，例如： grep -rn "mo:base" . --include=".mo" | grep -v .mops | wc -l grep -rn ":= Map.add|:= List.add|:= Set.add" . --include=".mo" | wc -l
本地升级测试需确保 .most 文件就位，升级时使用 --wasm-memory-persistence keep，验证模块哈希变化，并在旧版本填充状态后升级验证状态持久与 API 可用。
主网部署采用金丝雀策略：先部署低风险 canister，再部署代表性 canister，最后部署高价值/复杂 canister；每次部署后做 API 兼容性检查与领域特定验证。
适用场景
适用于需要将 Motoko 项目从 mo:base 迁移到 mo:core 的开发者，尤其是文件数量多、需要 AI 辅助批量迁移的场景。手册提供了代理策略：Phase 1、Phase 2 及工具类中的简单 Buffer→List 可安全自动化；Phase 3 中 actor 主文件的 Map 迁移、preupgrade/postupgrade 文件、Cycles.add 用法及第三方 .mops 包需要人工仔细审查。
限制
- 部分模块被移除且无直接替代（AssocList、Buffer、Hash、HashMap、Heap、IterType、None、Prelude、RBTree、Trie、TrieMap、TrieSet），需手动修复。
- 第三方 .mops 依赖可能仍使用 mo:base，需跳过或手动修补。
- 本地升级需要 .most 文件与 --wasm-memory-persistence keep。
- 文档建议在存疑时直接阅读 mo:core 源码，公开文档可能滞后。
- 关于收费、价格、平台支持范围等信息，资料中暂未提供。