Migration Assistant 卡住？如何快速迁移到新 Mac
Migration Assistant 快结束时卡住？为新 Mac 选对传输方式，了解为什么点对点 Wi-Fi 是最糟糕的默认选项，以及什么时候该耐心等待。
安全性更正，2026 年 10 月 18 日： 补充了清理和抹掉数据前的保护措施，更正了个人文件夹选择和 FileVault 指引，并明确说明计数器停滞不能证明迁移失败。迁移后必须恢复临时更改的保护设置。更正依据为下文链接的 Apple 指引，未进行新的实机测试。
设置新 Mac 的整个流程里，Migration Assistant 是最容易出岔子的那一步，而且出岔子的方式非常具体、可重复。包装盒已经拆了，新机器摆在桌上，进度条卡在 45% 两个小时了，上面写着还剩 26 小时。十分钟后它说还剩 4 小时。再过十分钟，它又说 26 小时。屋里没人知道正确的做法是继续等、重启，还是干脆放弃、手动拷贝文件。
出现这种情况的原因不是 Migration Assistant 坏了，而是 Migration Assistant 自己挑传输通道，它偏好一条大多数人根本没意识到正在被使用的无线路径，而几乎每个家庭里的默认状况——两台 Mac 并排放着，都连着同一个 Wi-Fi 网络——恰恰接近这个工具所支持的最糟糕配置。Apple 确实记录了传输通道的选择行为，但写在面向 IT 管理员的 Apple Platform Deployment 指南里，而不是写在一个正在设置笔记本电脑的普通人会去看的消费者支持文章里。
这篇文章要讲清三件事。第一，你实际上应该用哪种传输方式，按优先级排序，并解释这个排序背后的机制。第二，如何理解持续一小时显示「还剩 1 分钟」的估算，而不把它当作成功或失败的证据。第三，大多数指南至今仍然搞错的 Apple 芯片相关细节，包括那条极其常见的「开机时按住 T 键」的说法——自 2023 年以来，Apple 出售的任何一台全新 Mac 都不适用这条指令。
眼下时机很关键。据 MacRumors 和 9to5Mac 2026 年 8 月 11 日的报道，Apple 将美国地区 2026 年返校促销延长至 2026 年 9 月 24 日，而 macOS 27 Golden Gate 预计将于 2026 年 9 月发布，成为首个仅支持 Apple 芯片的版本。未来六周内会有大量用户迁移到新 Mac。
核心要点
- 传输通道由 Migration Assistant 挑，不是你挑 —— Apple 的部署文档明确写道，除非在源 Mac 上关闭了 Wi-Fi，否则两台 Mac 会建立点对点 Wi-Fi 连接，这正是「在旧 Mac 上关掉 Wi-Fi」成为单项收益最高的改动的原因。
- Apple 芯片上不存在 Target Disk Mode —— 在 M 系列 Mac 上按住 T 键毫无作用；对应的功能叫 Share Disk，通过 macOS Recovery 的 Utilities 菜单进入，而且它把宗卷呈现为网络共享，而不是本地磁盘。
- 估算不等于诊断 —— 小文件和元数据处理只是最后阶段缓慢的一种可能原因；Apple 并未公开估算算法。
- 检查进度和两台 Mac —— 仅凭估算值或字节计数器不变，无法判定失败。Apple 提醒，大型传输可能耗时数小时，并可能看起来暂时停止；决定重试前，应检查错误、电源和连接问题。
- 从 Time Machine 备份迁移是最可靠的退路 —— 它把第二台 Mac、网络和交互式会话全都从等式里拿掉了，而且它正是 Apple 自家社区论坛上那起 Tahoe 迁移失败案例的解决办法。
Migration Assistant 究竟是什么
在给方法排序之前，先把这个工具到底做什么说清楚会很有帮助，因为围绕它的很多焦虑都源于人们以为它做的事比实际更多。
Apple 说它会搬运哪些东西
Apple 的支持文章 Transfer to a new Mac with Migration Assistant（最后发布于 2026 年 2 月 10 日）开篇就给出了一句话的范围说明：Migration Assistant 把文稿、应用、用户账户和设置从一台 Mac 传输到另一台，它不会删除旧 Mac 上的信息，也不会替换新 Mac 上的操作系统。
后半句才是重点，也正是迁移远比它的名声安全的原因。Greg Gant 在 2026 年 1 月一篇力挺这个工具的文章中提出了同样的观点：在现代 macOS 上系统宗卷是只读且经过加密封装的，所以你在新 Mac 上得到的操作系统会完全保持 Apple 安装时的样子。Migration Assistant 不可能把一个损坏的旧系统拖过来，因为它根本不碰系统宗卷。它拖过来的是你的数据宗卷：个人文件夹、应用程序和设置。
在 macOS Tahoe 26 的《Mac 使用手册》里，Apple 把选择界面拆成五个类别：
| 类别 | 涵盖内容 |
|---|---|
| 应用程序 | /Applications 里的第三方应用。Apple 指出，不兼容的应用，或者已安装更新版本的应用，可能不会被传输，或者传输后无法使用 |
| 用户账户 | 每个账户及其个人文件夹，带一个展开箭头可以挑选文稿、图片、影片、桌面和下载等具体文件夹 |
| 其他文件与文件夹 | 个人文件夹之外、位于数据宗卷上的文件 |
| 隐私与安全性设置 | 隐私权限及相关设置 |
| 系统与网络 | 系统和网络设置，可展开以选择单项 |
Apple 的 Platform Deployment 指南补充了两个消费者文章没写、但值得知道的细节：用户的 ~/Library 文件夹总是会被迁移，而且迁移包含隐藏文件夹和文件，文中举的具体例子就是 SSH 密钥——除非被管理配置显式排除。如果你曾经好奇 ~/.ssh 目录会不会跟着过来，这就是有文档依据的答案。
The Eclectic Light Company 的 Howard Oakley 描述了同样的四个实用类别——应用程序、包含个人文件夹的用户账户、系统和网络设置，以及其他文件和文件夹——并指出 Migration Assistant 会尝试迁移一些众所周知的隐藏文件夹的内容，包括 /usr/local，不过当这些位置被大幅自定义过时，它可能会力不从心。这一句话就解释了本文后面提到的绝大部分 Homebrew 麻烦。
它不会碰的东西
它不会重装或修改 macOS。它不会抹掉旧 Mac。它不会传输数据的加密形态；正如 Glenn Fleishman 在 Macworld 解释的那样，迁移拷贝的是解密后的内容，因为目标机器需要可读的数据来填充新机器。而且它本身并不处理软件授权。
用 Gant 的话说，它也不是一项保洁服务。它是一个整体搬迁工具。每一个孤立的偏好设置文件、每一个被遗弃的 application support 文件夹、以及每一个自 2019 年起悄悄膨胀的缓存目录，都会跟着你走，除非你先清理干净或者取消勾选。
它在你的 Mac 上的位置
如果新 Mac 还停留在 Setup Assistant——就是那个问你国家和网络的流程——迁移已经内建在该流程里，你不需要单独打开任何东西。
如果你已经完成了初始设置，Migration Assistant 是一个独立应用。Apple 记录了两条路径：Applications 里的 Utilities 文件夹，以及 System Settings → 通用 → 传输或还原 → 打开 Migration Assistant。打开它会退出你所有其他应用并把你注销，所以先保存工作。
这个区别很重要。在 Setup Assistant 阶段迁移，Migration Assistant 可以干净地创建账户。之后再迁移意味着已经存在一个账户，这就会带来后面讲到的短用户名冲突问题。
先做决定：全量迁移、选择性迁移，还是全新开始
最常见的错误不是挑错了传输通道，而是压根没问这个问题，条件反射式地把积累了十五年的状态一股脑拖到一台你专门为了跑得快才买的机器上。
全量迁移的理由
你一次就能回到工作状态。每一项应用偏好设置、每一个邮件账户、每一份浏览器配置、每一个键盘快捷键和访达边栏排列都保留下来。对任何把 Mac 当生产工具而非爱好的人来说，这几乎总是正确的，Gant 的结论——对绝大多数用户在绝大多数时候，你都应该使用 Migration Assistant——是正确的默认建议。
Oakley 补充了一个时机上的理由：如果你打算把旧 Mac 上的大部分内容（包括当前的用户设置）都带过去，那么最佳时机就是你首次配置新 Mac 的时候。在 Setup Assistant 阶段迁移可以完全避开账户冲突的处理。
全新开始的理由
在某些特定情况下，往前迁移是错误的选择：
- 旧 Mac 一直有你从没诊断出来的毛病，尤其是登录时缓慢、反复弹出的权限对话框，或者一个已经变得不可靠的邮件应用。这些问题都住在
~/Library里，而~/Library总是会被迁移。 - 你正在跨越 Intel 到 Apple 芯片的分界线，而且你安装的软件中有相当一部分只有 Intel 版本。迁移带过来的是一批已经进入倒计时的二进制文件。参见下文关于 Rosetta 的章节。
- 你有一个从 Intel Homebrew 时代大幅自定义过的
/usr/local，外加庞大的开发者工具链。迁移的结果往往是一台装着两套半残废 Homebrew 前缀的机器。 - 你的旧机器确实快满了，而其中大部分是你好几年没打开过的东西。
全新开始的真实代价是时间，而且比人们预期的多得多。你要重新验证每一个账户、重装每一个应用、重建每一项偏好设置。Oakley 的警告适用于此：手动迁移要难得多，而且有遗漏必需内容的风险。如果你决定走这条路，我们的完整 Mac 迁移操作指南对手动路径有更详细的说明。
一张决策表
| 你的情况 | 推荐做法 |
|---|---|
| 架构相同，两台都是较新的 macOS，机器运行正常 | 在 Setup Assistant 阶段全量迁移 |
| Intel Mac 迁到 Apple 芯片，主要是 App Store 和主流应用 | 迁移用户账户和文件，取消勾选应用程序，重新安装原生版应用 |
| Intel Mac 迁到 Apple 芯片，有大量开发者工具链 | 只迁移用户账户和文件；从零重建 Homebrew 和各语言运行时 |
| 旧 Mac 有原因不明的登录或权限问题 | 在各用户账户下选择所需的个人文件夹，或从已验证的备份中手动拷贝这些文件夹，再重建设置 |
| 旧 Mac 已经报废或无法启动 | 从最近一次 Time Machine 备份迁移 |
| 处于设备管理下的工作或学校 Mac | 先找 IT；受管理的注册可能改变允许的操作 |
| 你想要一台干净的机器，但承受不起停机时间 | 现在全量迁移，之后再安排一个下午做清理 |
Apple 将「文稿」「图片」等个人文件夹归在用户账户下。只选择其他文件与文件夹不会包含这些账户文件夹。若要避免带入不需要的设置，请手动拷贝所需的个人文件夹，而非整个用户主目录，然后重新设置应用和偏好设置。仅靠选择性迁移，不能诊断旧问题，也不能保证解决它。
大多数人应该走的中间路线
取消勾选应用程序，其余全部保留。你保住了数据、账户、设置和 ~/Library，而应用则从它们当前的安装包重新安装，这样新机器上的每一个二进制文件都是最新的、签名正确的、架构匹配的构建。代价是一个晚上的下载时间，而它消除了迁移后最大的一类怪问题。
如果你选择相反的路线、把应用一起迁过去，那就计划好之后做一次清理。把应用拖进废纸篓删除会留下它的支持文件，而那恰恰就是你原本想避免的沉积物；我们关于彻底卸载应用并清除残留文件的指南讲了怎么正确处理。
传输方式排行榜
这一节决定了你的迁移是花九十分钟还是二十六小时。
Migration Assistant 如何选择传输通道
Apple 记录了这一点，但写在 Apple Platform Deployment 指南的 Managed Migration Assistant for macOS 章节下，发布于 2026 年 3 月 24 日。相关段落写道：Migration Assistant 会根据速度为迁移选择最佳传输方案，可选项包括直接通过 Wi-Fi 连接、基础设施 Wi-Fi、以太网和 Thunderbolt，而且 Migration Assistant 在迁移过程中还会频繁检查是否有更快的选项出现。
请仔细读这段话，因为里面藏着三个各自独立的事实。
第一，有四种传输通道，其中两种是无线的。直接通过 Wi-Fi 连接是两台 Mac 之间的点对点链路。基础设施 Wi-Fi 是两台 Mac 都通过你的路由器通信。这两者不是一回事，性能表现差别很大。
第二，选择是自动的、基于速度的。你没得选。你只能改变它可以从中挑选的选项范围。
第三——这是几乎没人知道的部分——传输通道在迁移过程中可以改变。Migration Assistant 会在传输中途重新评估。这就是时间估算剧烈波动的机制性原因：它用来外推的吞吐量本身就不是稳态的。2024 年 12 月，MacRumors 论坛上一位迁移到 M4 MacBook Pro 的用户报告说亲眼看到了这一幕，传输从以太网开始，中途切换到了点对点连接。
同一个部署页面把前提条件说得很直白：除非在源 Mac 上关闭了 Wi-Fi，否则设备之间会建立点对点 Wi-Fi 连接。这句话是 Apple 关于这个工具的全部文档中最具可操作性的一个事实。
为什么点对点 Wi-Fi 是最糟糕的默认选项
下面是它的机制，值得理解而不是盲信。
Mac 的点对点 Wi-Fi 用的是 Apple Wireless Direct Link，也就是承载 AirDrop 和 AirPlay 发现功能的同一层。正如 Yggdrasil Network 项目关于 AWDL 的技术文章所解释的，一台设备可以用单个 Wi-Fi 射频同时接入普通 Wi-Fi 接入点和一个 AWDL 集群，办法是在两者的无线信道之间快速切换。
一个射频。两个信道。网卡不可能同时待在两边，所以它只能分时。
当你在两台同时也连着家庭网络的 Mac 之间迁移时，这会带来一对具体而令人不快的后果：
- 点对点链路只能拿到可用空口时间的一部分，因为射频不断要离开去维持与路由器的关联。
- 与此同时，你的家庭 Wi-Fi 也因为同样的原因变差，这就是为什么有人开始迁移时全家都会有感觉。
再叠加 2026 年公寓里的日常现实：拥挤的 5 GHz 频段、邻居的网络，以及两台相距不到二十厘米、都在大声发射的 Mac。结果是一条有效吞吐量逐分钟波动的链路，而这恰恰是时间估算器最难处理的输入。
Apple 没有为 Migration Assistant 在任何传输通道上发布过吞吐量数据。流传的数字全都来自用户报告。上文引用的 MacRumors 帖子报告点对点连接大约 40 到 55 MB/s，换上一根正经的 USB-C 数据线后升到约 90 MB/s。这些是一个人在一对机器上的观察，不是基准测试，你应该把它们当作排序而不是预测。
有线以太网
以太网路径是最无聊也最可预测的选项，而无聊正是你在这里想要的。
在现代笔记本上这意味着两端各需要转接器或扩展坞，或者用本身自带端口的 Mac mini 或 Studio。把两台 Mac 接到同一台交换机或路由器上。然后，关键的一步：在源 Mac 上关掉 Wi-Fi，否则按照 Apple 自己记录的行为，Migration Assistant 仍然可能选择点对点路径。
千兆以太网是 1 Gbps 的链路，这是一个硬上限，但是个稳定的上限。稳定性正是时间估算变得可用、以及传输通道不会中途翻转的原因。
两台 Mac 之间的 Thunderbolt 线缆
这是 Mac 对 Mac 直连迁移中最快的受支持路径，也是 Apple 自家的硬件指南推荐的那条。macOS Tahoe 26 的 MacBook Air 使用手册写道：虽然你可以把两台电脑接入同一个 Wi-Fi 网络来无线传输，但用 Thunderbolt 或以太网线缆把新 Mac 直接连到旧 Mac 通常更快。Oakley 的建议更具体：用一根好的 Thunderbolt 4 线缆把两台 Mac 背靠背连起来，或者从 Thunderbolt 3 SSD 上的备份迁移。
这里有两件事容易出错，而且都能避免。
线缆。 USB-C 接头并不能让一根线成为 Thunderbolt 线缆。MacBook 包装盒里附带的充电线是一根只能传输电力和 USB 2 数据的 USB-C 线。这正是 MacRumors 那个帖子的根本原因：发帖者的迁移很慢是因为用了一根充电线，换成真正的数据线后速度大幅提升。找一找接头外壳上模制的闪电图标，或者选购明确标注为 Thunderbolt 3、Thunderbolt 4、Thunderbolt 5 或 USB4 的线缆。
接口。 当两台 Mac 用 Thunderbolt 线缆背靠背连接时，macOS 会创建一个叫 Thunderbolt Bridge 的 IP-over-Thunderbolt 接口。Glenn Fleishman 发表于 2023 年 4 月 7 日的 Macworld 指南讲解了如何通过 Thunderbolt 使用 Migration Assistant，其中演示了在网络设置里确认 Thunderbolt Bridge 存在且显示为已连接，并指出 Migration Assistant 的传输界面上有一个 Connection Details 控件，能告诉你它实际选了哪条链路。用它。它把猜测变成了事实。
在开始之前，你可以在任一台 Mac 的 Terminal 里确认这个接口是否存在：
networksetup -listallnetworkservices在列表里找 Thunderbolt Bridge 这一项。如果没有，就在开始迁移前用 System Settings → 网络 里的省略号菜单把它加上。
从 Time Machine 备份或外置克隆迁移
当直连迁移已经失败过一次时，这是大多数人应该首先想到的方法，而作为首选它也被严重低估了。
Migration Assistant 接受 Time Machine 备份作为源。Apple 的 Restore your Mac from a backup 文章（最后发布于 2025 年 11 月 10 日）记录了流程：连接备份磁盘，打开 Migration Assistant，选择从 Mac、Time Machine 或启动磁盘传输的选项，选择备份磁盘（Apple 提示它可能需要一会儿才出现），然后选择要使用的备份，如果想用更早的备份就点展开箭头。
Oakley 确认源不一定非得是 Time Machine：从备份迁移应该都能正常工作，无论那份备份是由 Time Machine、Carbon Copy Cloner、SuperDuper 还是其他任何优秀工具创建的。关键在于它必须是位于磁盘根目录的宗卷级备份。Carbon Copy Cloner 的开发商 Bombich Software 明确指出，存放在备份宗卷某个文件夹内部的备份不会被 Migration Assistant 接受，并建议直接把启动磁盘重新备份到本地连接的备份磁盘根目录，这样你才有一个 Migration Assistant 兼容的源。
这种方法为什么经常胜出：链路里没有第二台运行中的 Mac，所以没有任何东西需要保持唤醒、保持供电或协商网络。源是一个本地磁盘，所以吞吐量受限于硬盘盒和总线，而这两者都很稳定。如果中途失败，你重新开始就行，完全不用碰旧 Mac。而且反正在做这一切之前，你本来就需要一份最新的备份。
如果你还没有备份策略，那就在迁移之前而不是之后把它补上；我们的 2026 年 Mac 备份策略指南讲了一套站得住脚的方案是什么样子，而 Time Machine 排障指南则涵盖了在依赖备份作为迁移源之前值得先排除的那些故障模式。
从 Windows PC 迁移
Migration Assistant 也能处理这种情况，需要配合一个 Windows 端的辅助工具。Apple 的 Transfer from PC to Mac with Migration Assistant 文章（发布于 2026 年 6 月 23 日）指定使用 Windows Migration Assistant 3.0.2.1 从 Windows 10 或更高版本迁移到 macOS Tahoe 26、Sequoia 15 或 Sonoma 14。更旧的 macOS 版本需要更旧的构建：Ventura 13 和 Monterey 12 用 2.4.5.0，Big Sur 11 用 2.3.1.0。下载错版本是这件事彻底失败的最常见原因。
它的前提条件与 Mac 对 Mac 的情况有一个显著不同：Apple 声明两台电脑必须彼此靠近，并且同时打开 Wi-Fi 和蓝牙，还警告说不支持蓝牙低功耗的 PC 可能需要一个 USB 蓝牙适配器。如果 Mac 运行的是 macOS 13 或更早版本，Apple 还额外要求两台电脑接入同一个网络，或者用以太网线缆直连。
Apple 在那个页面上用一张表格准确记录了什么会落到哪里：Outlook 和 Windows Mail 账户到「邮件」，联系人到「通讯录」，约会到「日历」，Outlook 任务在 macOS 13 或更高版本上到「提醒事项」，媒体文件到对应的 Apple 应用，来自 Chrome、Edge、Firefox、Internet Explorer 和 Safari 的书签进入 Safari。C 盘上的非系统文件会落到你个人文件夹内的「共享」文件夹里，Apple 指出这需要以管理员身份登录 PC 后再运行 Windows Migration Assistant。
有两个限制。Windows 应用程序不会被搬过来，因为没有对等的二进制文件可以搬。另外，根据《Mac 使用手册》，网络设置和密码不会从 PC 传输过来。
对比表
| 方式 | 准备工作量 | 可预测性 | 需要什么 | 什么时候用 |
|---|---|---|---|---|
| Thunderbolt 线缆，源机关闭 Wi-Fi | 中 | 直连方式中最高 | 一根真正的 Thunderbolt 或 USB4 线缆；两台 Mac 保持唤醒并接电 | 两台 Mac 都能用，你想要最快的直连路径 |
| 有线以太网，源机关闭 Wi-Fi | 中 | 高 | 两端的转接器或扩展坞，外加一台交换机或路由器 | 没有 Thunderbolt；你想要稳定无聊的方案 |
| 外置磁盘上的 Time Machine 备份 | 低 | 整体最高 | 位于磁盘根目录的最新宗卷级备份 | 直连迁移已经失败、旧 Mac 已报废，或者你想要最省心的选项 |
| 来自 Carbon Copy Cloner 或 SuperDuper 的克隆 | 低 | 高 | 写入本地连接磁盘根目录的备份 | 你本来就在用这类工具 |
| 基础设施 Wi-Fi，两台 Mac 都连路由器 | 最低 | 低 | 无需额外硬件 | 仅限小规模传输，或者别无选择 |
| 点对点 Wi-Fi，自动默认选项 | 最低 | 最低 | 什么都不需要，这正是问题所在 | 刻意避开；这是你不小心就会落入的选项 |
| 从 Windows PC 迁移 | 中 | 中 | Windows Migration Assistant 3.0.2.1，蓝牙 LE | 从 Windows 转投 Mac |
Share Disk 不是 Target Disk Mode
这里是关于迁移到新 Mac 的多数已发表建议纯属错误的地方，而且已经错了很多年。
为什么在 Apple 芯片 Mac 上按住 T 键毫无作用
Target Disk Mode 是一项 Intel 时代的功能。Apple 的《Mac 使用手册》对应页面在适用范围上毫不含糊，开篇的定义就点明了架构：你可以把一台基于 Intel 的 Mac 连接到另一台 Mac，使这台基于 Intel 的 Mac 显示为一个外置硬盘，这被称为目标磁盘模式。后面的操作说明都是针对 Intel 机器的：如果电脑已关机，按住 T 键开机；如果已开机，使用 System Settings → 通用 → 启动磁盘 → 在目标磁盘模式下重新启动。启动后，另一台电脑的桌面上会出现一个磁盘图标。
同一个 Apple 页面接着在第二段把 Apple 芯片用户引向别处，写道你也可以通过让 Apple 芯片 Mac 启动进入 macOS Recovery，在 Apple 芯片 Mac 与另一台已连接的 Mac 之间传输文件。
Apple 芯片上不存在 T 键路径。Apple 芯片 Mac 根本不读取开机组合键；整套启动选项流程已经改由电源键承担。在 M 系列 Mac 上按住 T 键什么也不会发生。
有一个值得知道的细微之处，因为它正是部分混乱的源头：Apple 自己的 Migration Assistant 说明确实仍然提到了 T 键，但适用范围极其狭窄。《Mac 使用手册》中关于从 Time Machine 备份或其他存储设备传输的章节写道，你可以从另一台运行 OS X 10.8 或更早版本、通过 Thunderbolt 线缆连接的 Mac 传输，也只有在这种情况下才让你在重启源 Mac 时按住 T 键。那条指令针对的是 2012 年及更早的机器。它不是通用建议，而脱离上下文照抄它正是这个迷思传播开来的方式。
Intel 路径上还有一个人们常忽略的线缆限制。Apple 的目标磁盘模式页面指出，如果两台电脑中任何一台安装了 macOS 11 或更高版本，你必须使用 Thunderbolt 线缆连接两台电脑。普通的 USB-C 线缆不够用。
如何真正使用 Share Disk
Apple 芯片上的替代方案叫 Share Disk，它藏在 macOS Recovery 里。Apple 的 macOS Tahoe 26《Mac 使用手册》把它描述为：在一台启动进入 macOS Recovery 的 Mac 和另一台 Mac 之间传输文件，方式是共享一个宗卷并用 USB、USB-C 或 Thunderbolt 线缆连接两台电脑。注意这里接受的线缆范围比 Intel 目标磁盘模式的要求更宽。
按照 Apple 记录的步骤，确切流程是：
- 用 USB、USB-C 或 Thunderbolt 线缆连接两台电脑。
- 在你想共享其磁盘的那台 Mac 上，选择 苹果菜单 → 关机，等它完全关闭。
- 按住电源键直到出现系统宗卷和「选项」按钮，然后点按选项，再点按继续。
- 如果系统询问，选择要恢复的宗卷，点按下一步，然后选择一个管理员账户，输入其密码，点按继续。
- 在「恢复」App 中，选择 实用工具 → Share Disk。
- 选择你要共享的宗卷，然后点按开始共享。
- 在另一台 Mac 上，打开一个访达窗口，在边栏「位置」下点按网络。
- 双击那台共享了磁盘的 Mac，点按连接身份，选择访客，然后点按连接。
- 传输文件。
- 完成后，在另一台 Mac 上推出该宗卷，在 Share Disk App 中点按停止共享，然后选择 Share Disk → 退出 Share Disk。
如果 Apple 针对你的 macOS 版本的文档与这些步骤不一致，以 Apple 的版本为准；此处是从撰稿时已发布的 macOS Tahoe 26 版《Mac 使用手册》转录的。
另一台 Mac 实际看到的是什么，以及为什么这很重要
这是各处都被一笔带过的部分，而它才是全部关键。
Target Disk Mode 呈现的是一个块设备。旧 Mac 真的表现为一个外置硬盘，在另一台电脑的桌面上有磁盘图标，可以被磁盘工具以及任何期待一个真实宗卷的软件寻址。
Share Disk 呈现的是通过线缆传输的网络共享。Apple 自己的步骤就是证据：你在访达边栏的网络下找到它，而不是在桌面上，而且你要用连接身份 → 访客去认证。它是一个文件共享会话，只不过恰好跑在 Thunderbolt 或 USB 链路上而不是以太网上。
这个区别不是学术问题。它决定了哪些工具能够使用它。
为什么 Share Disk 不能作为 Migration Assistant 的源
因为 Share Disk 给你的是一个网络文件共享而不是启动磁盘，Migration Assistant 似乎并不接受它作为迁移源，而且社区里有一份记录了这一情况的报告。
2022 年 1 月 29 日提交的两份 Feedback 报告，在 Open Radar 上以 FB9864910 和 FB9864933 公开镜像，精确描述了这一行为。报告者用一根 0.8 米的 Apple Thunderbolt 3 线缆连接了两台 14 英寸 MacBook Pro，把源机从 Recovery 进入 Share Disk，然后在目标机上运行 Migration Assistant。Migration Assistant 一直显示 Looking for sources…，永远不结束。报告者确认链路本身没问题，因为目标机上的访达能够浏览网络并连接到源机，并观察到共享磁盘是通过 Thunderbolt 连接以 AFP 协议提供的。第二份报告请求 Apple 至少检测并拒绝这种配置，而不是让用户无限期等待。两份在 Open Radar 上的状态都是 Open。
有两点需要诚实说明。这些报告来自 2022 年 1 月、针对 macOS 12.2，我没有找到能证实或推翻其在 macOS 26 上行为的资料。Apple 的《Mac 使用手册》确实把同一网络上的磁盘列入了 Migration Assistant 接受的源之中，这与那份报告之间存在张力。我的推断（明确标注为推断）是：Migration Assistant 的源发现机制寻找的是一个已挂载的启动宗卷，或者一台正在运行 Migration Assistant 的活动 Mac，而由 Recovery 环境提供的 AFP 共享两者都不满足。
无论如何，实际结论都一样。不要围绕 Share Disk 来规划你的迁移。 用它做 Apple 记录的那件事：从一台无法正常启动的 Mac 上手动拷贝文件。如果你想要线缆速度的迁移，就把两台正常运行的 Mac 连起来，让 Migration Assistant 直接使用 Thunderbolt 链路，或者从外置磁盘上的备份迁移。
开始之前：能避免大多数失败的检查清单
大多数迁移失败其实是在有人点「继续」之前就已经存在的配置问题。这份清单综合了 Apple 记录的前提条件以及上文提到的故障模式。
先保留恢复所需的数据： 为源 Mac 和目标机上已有的数据创建最新备份，包括失败尝试后新建的文件。在清理、移除或替换账户前，确认所需的重要文件能够恢复。
来自 Apple 的文档：
- 在两台 Mac 上安装所有可用的 macOS 更新。Apple 明确指出两台 Mac 不需要运行同一个 macOS 版本，只需要各自在其运行的版本上保持最新。
- 如果任何一台 Mac 是笔记本，把它接上电源。《Mac 使用手册》直接写了这一点；消费者支持文章没写，这是人们漏掉它的原因之一。
- Apple 建议临时关闭杀毒软件、防火墙和 VPN 软件，直到传输完成。使用可信连接；迁移完成或停止排查后，在恢复正常使用前重新启用两台 Mac 上的保护措施。受管理的 Mac 应先咨询 IT，不要绕过强制执行的控制措施。
- 如果任何一台 Mac 运行的是 OS X El Capitan 或更早版本，或者你不确定，那就再把两台都接入同一个 Wi-Fi 网络。
来自机制推导，而非 Apple 文档：
- 在有线路径就位之后，在源 Mac 上关闭 Wi-Fi。这是 Apple 自己那句话的直接推论：除非在源 Mac 上关闭了 Wi-Fi，否则会建立点对点 Wi-Fi 连接。
- 确认线缆是数据线，不是充电线。
- 在整个过程中禁用两台 Mac 的睡眠。屏幕方面看 System Settings → 锁定屏幕 和 System Settings → 显示器；笔记本则保持翻盖打开，或者接上电源并外接一台显示器。
- 检查目标机的可用空间。Migration Assistant 会替你计算源的大小，但那是在你已经把整套配置搭好之后才做的。
- 备份后再检查可清理的内容。清空废纸篓前，先恢复其中需要的项目，并将其纳入已验证的备份；不要假定废纸篓已有备份。清空废纸篓会永久删除其中的内容。不确定时，请跳过清理。
- 退出源 Mac 上的所有程序，并在开始前让「照片」或「邮件」的索引建立完成。
- 记下源 Mac 的短用户名。如果目标机上已经存在账户，你会用到它。
一步步运行 Migration Assistant
在新 Mac 上
如果 Mac 正显示 Setup Assistant，迁移就是该流程的一部分，你不需要单独打开任何东西。否则，从 System Settings → 通用 → 传输或还原 → 打开 Migration Assistant 打开它，或者从 Utilities 文件夹打开，然后以管理员身份验证。
当被问到你想如何传输时，选择从 Mac、Time Machine 或启动磁盘传输的选项，然后点按「继续」。
在旧 Mac 上
打开 Migration Assistant，点按「继续」，当被问到你想如何传输时，选择传输到另一台 Mac 的选项，然后点按「继续」。
旧 Mac 现在处于等待状态。为此它已经退出了你的应用并把你注销，这是预期行为。
配对与安全码
在新 Mac 上，从列表中选择旧 Mac 的图标，点按「继续」。两台机器都会显示一个代码。确认代码一致后，在旧 Mac 上点按「继续」。
如果旧 Mac 始终没有出现在新 Mac 的列表里，那是发现问题而不是传输问题，原因几乎总是在上面的检查清单里：防火墙或 VPN 还在运行、两台 Mac 在不同网络上，或者源机已经睡着了。
计算阶段
Migration Assistant 现在会计算你的全部信息占用了多少存储空间，包括应用程序、用户账户、文件、文件夹和设置。Apple 的说明就一句：等待计算完成。
在一台有大型「照片」图库、庞大邮件存储，或者塞满小文件的开发目录的机器上，这个阶段本身就可能耗时很久，而且它不会显示有意义的进度指示。它在遍历文件系统。这不是该恐慌的阶段。
选择要传输的内容
勾选你想要的每个类别旁边的复选框，或者用类别旁的展开箭头选择其中的具体项目。展开各用户账户，选择其中的「文稿」「图片」等个人文件夹；只选其他文件与文件夹不能替代这一步。如果你之前决定走中间路线，就在这里取消勾选应用程序。
密码与授权提示
这里可能出现三种提示，每一种都有特定含义：
- 传输管理员账户。 系统会要求你点按「设定密码」并设置一个安全密码。Apple 的警告值得重复一遍：记住它，因为你需要用它在新 Mac 上登录该账户。
- 传输标准账户。 系统会分配一个临时密码并显示在屏幕上。把它记下来。用户首次登录时输入该密码，然后会被提示设定自己的密码。
- 被要求「授权」。 如果 Migration Assistant 索要一个已在你新 Mac 上获得授权的现有用户的密码，点按「授权」并输入该账户的密码。这是 FileVault 和安全令牌的授权路径，也正是你在开始之前就该知道目标机上已有账户凭据的原因。
运行过程中
Apple 自己设定预期的那句话在 Mac 对 Mac 和 Time Machine 两篇文章中一字不差地出现：大型传输可能需要数小时才能完成，并且可能偶尔看起来像是暂停了。
完成时，《Mac 使用手册》说电脑会重新启动，如果发现问题还会显示一份迁移摘要——例如某些文稿无法传输，或者检测到不兼容的软件。请读那份摘要。它是你能拿到的唯一一份结构化报告，而人们往往条件反射地把它关掉。
诚实地解读进度条
各阶段的一种可能模型
下表是用于解释的模型，并非 Apple 记录的处理顺序，也不能用于诊断某次具体传输。小文件或元数据处理可能是最后阶段缓慢的原因之一。
| 阶段 | 你看到什么 | 实际在发生什么 | 正常时长 |
|---|---|---|---|
| 发现 | 正在查找源 | 两台 Mac 在选定的传输通道上广播和监听 | 几秒到几分钟 |
| 计算 | 正在计算，没有有用的进度指示 | 遍历源文件系统以统计总字节数和项目数 | 干净机器上几分钟；有大型「照片」或邮件库时长得多 |
| 批量传输 | 进度条稳步移动，估算大致稳定 | 大文件以接近链路速率的速度流动 | 大规模传输中占据大部分实际耗时 |
| 小文件尾段 | 进度条接近末尾，估算坍缩成一个很小的数字并卡住 | 数量惊人的小文件正在被逐个创建 | 让人意外的那部分，也是人们出手干预的那部分 |
为什么估算在接近结束时坍缩
Apple 从未记录过 Migration Assistant 如何计算它的时间估算，而且在我能找到的任何支持文章中，Apple 也从未承认过那个具体的「大约还剩 1 分钟」行为。Apple 说得最接近的就是上面引用的那句关于大型传输需要数小时、可能看似暂停的话。接下来的内容全都是我根据文件拷贝的工作原理做出的推断，应当被当作推断而不是有文档依据的行为来阅读。
一种可能的模型是按字节数估算：计算阶段得出总字节数，再根据单位时间内传输的字节数推算剩余时间。这不是经过验证的 Migration Assistant 算法说明。
这个模型在批量阶段效果不错，因为批量阶段由少量大文件主导。一个 4 GB 的磁盘映像、一段视频、一张「照片」图库原片：这些以接近链路速率流动，用「每秒字节数」来描述正在发生的事情是恰当的。
一种可能的后期负载是处理小文件和元数据，涉及 ~/Library/Caches、Mail 文件、「照片」图库元数据、浏览器配置、node_modules 树或 .git 对象。这些内容可能包含大量小文件，但进度界面不能证明当前传输正在处理它们。
它们中的每一个都需要付出一份与其大小无关的固定开销。目标机必须创建文件，拷贝扩展属性和任何 ACL，设置所有者、权限和时间戳，而且——在网络传输通道上——至少完成一次往返。当平均文件只有四千字节时，那份固定的单文件开销就是全部开销。吞吐量不再是带宽问题，而变成了每秒文件数的问题，而每秒文件数换算成有效每秒字节数时要差上一到三个数量级。
在这个模型中，基于字节数的估算可能低估大量小文件操作所需的时间。但它不能说明还剩多少工作，也不能确定某次传输需要多长时间。
还剩 1 分钟的估算持续一小时，既不能证明迁移正常，也不能证明迁移失败。不要仅凭这个显示中断迁移；先检查两台 Mac 是否报错，并确认电源和连接正常。
它真的卡住时，该怎么办
检查进度、电源、连接和错误
仅凭时间估算无法判断迁移是否正常。Apple 未公开计算方法，负载变化只是估算不准确的一种可能解释。
已传输字节数以及可见时的项目计数，可以显示仍有活动。如果它们在变化，且两台 Mac 均未报错，请让传输继续。计数器静止本身不能证明失败。
Apple 没有记录「一小时不变即失败」的阈值。 Apple 表示，大型传输可能耗时数小时，并可能看起来暂时停止。留出充足时间，检查两台 Mac 并排查连接问题，再决定是否重试。
升级处理阶梯
按顺序逐条往下做。不要直接跳到最后。
- 留出充足时间。 大型传输可能耗时数小时，并可能看起来暂时停止。估算值不变或字节计数器静止，即使持续一小时，也不能证明失败。
- 确认两台 Mac 都保持唤醒并接电。 睡着的源 Mac 会让传输停滞，而目标机上不会有任何错误提示。在源机上碰一下触控板，不要点击任何东西。
- 确认链路仍然连通。 如果你用的是线缆，检查它有没有被碰松。如果 Migration Assistant 的传输界面提供 Connection Details，看看它当前用的是哪条传输通道；它可能已经悄悄降级了。
- 查看源 Mac 的屏幕。 源机上的 Migration Assistant 有时会显示一个永远不会传到目标机的错误对话框，包括下面描述的启动网络错误消息。
- 排查后重新评估。 如果修复了电源或连接问题，请给进度恢复留出时间。固定的等待时长无法判定传输是否失败。
- 如果出现明确错误，或排查后决定重试，请在可用时使用 Migration Assistant 的取消或停止控件。 不要把断电作为首选应对方式；取消并不能保证目标账户完整。重试前先保全数据。
- 重试前保全不完整的账户。 如果失败尝试创建了可弃用的账户，仍须先验证源机备份，备份仅存在于目标机上的文件，并确认该账户不含独有数据。之后若在 System Settings → 用户与群组 中移除它，请将该账户的整个主目录（个人文件夹）保存为磁盘映像，或将该目录保留在原位。否则请保留账户，并处理 Migration Assistant 的账户名称提示；删除并非必需。
- 换传输通道再试。 如果无线失败，改走有线。如果有线失败，改走 Time Machine 备份。
- 改从备份迁移。 这是真正管用的退路，也正是解决 Apple 社区论坛上那起 Tahoe 案例的办法。
唯一一种「等待是错的」的情况
如果源 Mac 正在显示一个真实的错误对话框，等待毫无意义。有据可查的例子是 2025 年 9 月 Apple 支持社区上一位用户，从 M1 Mac mini 迁移到 M4 Mac mini，两台都运行 macOS Tahoe。在安全码匹配之后，源机显示：Unable to use this machine for migration. A startup networking error occurred. Please restart this machine and try again later. 发帖者报告说通过以太网、Wi-Fi 和 Thunderbolt 直连都出现了同样的失败。两天后他们发布了解决方案：用 Time Machine 把源 Mac 备份到外置驱动器，然后从那份备份迁移。
那是一份关于一对机器的社区报告，不是有文档修复方案的已确认 Apple bug，我也没找到 Apple 对此的任何承认。但它展示的升级路径是正确的。当直连路径在每一种传输通道上都失败时，别再折腾传输通道了，去改变源。
改从 Time Machine 备份迁移
步骤
按照 Apple 的 Restore your Mac from a backup 文章：
- 如果新 Mac 出于任何原因需要重装 macOS，先做这件事。
- 连接 Time Machine 备份磁盘，确保它已通电。
- 打开 Migration Assistant，或者使用 Setup Assistant 里的迁移步骤。
- 选择从 Mac、Time Machine 或启动磁盘传输的选项。
- 选择备份磁盘。Apple 提示它可能需要一会儿才出现；不要过了十秒就断定它不见了。
- 选择一份备份。如果「继续」是灰的，或者你想用比显示出来的那份更早的备份，点按所显示备份旁边的展开箭头，从列表中挑选。
- 等待计算完成，选择类别，然后按 Mac 对 Mac 迁移的流程继续。
Apple 明确告诉你不要做的一件事
macOS Recovery 里有一个 Time Machine 系统恢复选项，而它是设置新 Mac 时的错误工具。Apple 在《Mac 使用手册》的 macOS Recovery 页面上用一条「重要」提示直接标明了这一点：只应使用你的 Time Machine 备份把信息恢复到作为该备份来源的那台电脑上；如果你想把信息从这台 Mac 传输到一台新电脑，请退出 macOS Recovery，重新启动，然后使用 macOS 中的 Migration Assistant App。
Time Machine 系统恢复是把整个系统恢复回它原本所属的那台机器。Migration Assistant 是把你的数据搬到另一台机器新装好的系统上。用前者去设置新 Mac 属于范畴错误。
之后如何继承备份
迁移完成后，当你把同一块备份磁盘连接到新 Mac 上时，macOS 会提议让新机器继承已有的备份历史。Howard Oakley 对此有详细论述：如果你继承了这些备份，它们会成为新 Mac 备份历史的一部分，但旧机器就不能再用它们了。他还指出，tmutil inheritbackup 命令曾经对 APFS 备份失效，但自 macOS Sequoia 15.1 起又能用了。
如果你打算继续使用旧 Mac 及其备份历史，就不要继承。如果旧 Mac 要卖掉或退役，继承可以省掉一次全新的完整备份。图形界面的提示是受支持的途径；tmutil inheritbackup 的确切参数形式在 APFS 各修订版之间有过变化，所以我不打算印出一条我无法在 macOS 26 上验证的调用命令。
哪些东西搬不过来，以及你的迁移后检查清单
Migration Assistant 搬运文件。它不搬运存在于文件之外的状态，也不搬运与硬件绑定的状态。以下是迁移后必然需要处理的事项。
授权与激活
Migration Assistant 不处理软件授权。凡是把激活状态绑定到硬件标识符、机器指纹，或者厂商服务器上按设备计的激活名额的应用，都会把新 Mac 当作一次全新安装。视厂商而定，这意味着重新输入密钥、重新登录，或者先在旧机器上取消激活以腾出一个名额。
实用的指令很无聊：在你抹掉或卖掉旧 Mac 之前，把它上面的所有软件都取消激活。 Adobe、Microsoft、大多数音视频插件厂商，以及大多数专业 CAD 和统计软件包都有取消激活或退出登录的步骤，而在机器已经不在手上之后再做这件事要难得多。
邮件
Apple 直接记录了这一点：Migration Assistant 会传输你的电子邮件，但要访问它，你可能需要先在邮件应用中重新设置邮件账户。预期你需要重新验证账户，也预期一次可能持续数小时的重建索引过程，在它完成之前 Spotlight 和「邮件」搜索都不可靠。
Homebrew 与命令行工具
这是开发者迁移后最大的单一困惑来源，而原因是架构性的。
Homebrew 在 Apple 芯片上的前缀是 /opt/homebrew。在 Intel 上曾是 /usr/local。按照 Oakley 的描述，Migration Assistant 会尝试迁移一些众所周知的隐藏文件夹，其中包括 /usr/local。于是从 Intel 迁到 Apple 芯片可能让你在一台原生前缀为 /opt/homebrew 的机器上得到一整棵位于 /usr/local 的 Intel Homebrew 树，而且从迁移过来的 shell 配置里 /usr/local/bin 还留在你的 PATH 上。
Homebrew 自己的 Common Issues 文档处理了这个症状，指示你在重新安装前先删掉从旧 Mac 残留下来的 /usr/local/bin/brew。
Apple 芯片迁到 Apple 芯片的情况好得多。Homebrew 维护者 Gromgit 在该项目的讨论论坛中回应说，这类 Homebrew 及其已安装 formula 和 cask 的迁移通常是无缝的，但有几点要注意：macOS 版本跨度很大时可能需要重装部分 formula；你应该检查配置为登录时启动的服务是否仍然会启动；以及像 macFUSE 这样对安全性至关重要的 cask 应该手动重装，好让新机器能授予它们所需的权限。
干净的做法——也是值得花那二十分钟的做法——是在迁移之前先在旧 Mac 上生成一份清单：
brew bundle dump --describe --file=~/Brewfile然后在新 Mac 上原生安装 Homebrew 并重放它：
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
brew bundle install --file=~/Brewfile这样每一个二进制文件都是针对正确架构的最新原生构建，而不是你旧机器上碰巧有的那些东西。
系统扩展、VPN 客户端与安全代理
任何会安装系统扩展、网络扩展、launch daemon 或特权助手的软件，都需要在新 Mac 上重新安装。文件可能会迁移过来，但批准状态不会：macOS 要求这台机器的用户去批准一个系统扩展，而那份批准是按安装实例计的。
VPN 客户端、终端安全代理、带特权助手的备份代理、虚拟音频设备、打印机和扫描仪驱动，以及像 macFUSE 这样的文件系统驱动，全都属于这一类。症状一致而且具有误导性：应用能启动，看起来一切正常，但它的后台组件悄无声息地什么也不做。
迁移后你可以在新 Mac 上盘点实际加载了什么：
systemextensionsctl list这会打印出已注册的系统扩展及其启用状态。如果你预期存在的东西不见了，或者虽然在但未启用，就用当前的安装包重装该应用，而不是试图重新批准迁移过来的副本。
Apple 的启动安全性实用工具位于 macOS Recovery 的 实用工具 → 启动安全性实用工具 下，是 Apple 芯片上管理传统内核扩展的地方。默认是「完全安全性」；要允许用户管理来自已识别开发者的内核扩展，需要降到「降低安全性」。如果某个旧应用需要内核扩展，这是你必须在新机器上有意识做出的决定——迁移不会把它带过来。
Docker 与虚拟机
Docker Desktop 是可靠的「受害者」。docker/for-mac 的 issue 跟踪器里有一份存在已久的报告：使用 Migration Assistant 会导致 Docker 无法启动，直到手动删除相应的 Library/Group Containers 目录；另有一种独立的故障模式是，如果迁移过程中个人目录的用户名发生了变化，守护进程就不会启动。贡献者还指出，在 Apple 芯片上，从 Intel Mac 迁移到 /usr/local/bin 里的 colima 或 limactl 之类工具是错误的架构。
把容器和虚拟机状态当成要重建的东西，而不是要迁移的东西。导出你需要的部分，原生重装工具链，然后重新拉取镜像。
Rosetta 与仅支持 Intel 的应用
在 2026 年，这里的时间点异常重要。
Apple 在 WWDC 2025 上宣布，macOS 27 将是最后一个完整支持 Rosetta 2 的版本，从 macOS 28 起只保留一个有限子集，用于依赖 Intel 框架的、已停止维护的老游戏。自 macOS 26.4 起，当你启动一个需要 Rosetta 2 的应用时系统会发出提示。macOS 27 Golden Gate 在 2026 年 6 月的 WWDC 上宣布、预计 2026 年 9 月发布，它仅支持 Apple 芯片，并放弃了所有 Intel Mac。
这对迁移的影响是：你今天带到新 Mac 上的每一个仅支持 Intel 的二进制文件都有一个明确的保质期。Migration Assistant 会把它们带过来，而按照 Apple 在《Mac 使用手册》中的说明，不兼容的应用，或者已安装更新版本的应用，可能不会被传输，或者传输后无法使用。Gant 的观察是，Migration Assistant 会在 Apple 芯片上标记出仅支持 Intel 的应用，而不是干脆拒绝迁移。
审查的正确时机是在迁移之前而不是之后，因为这份审查会告诉你哪些应用干脆不该带过去。我们的 Rosetta 2 终结前的 Intel 应用盘点指南介绍了生成这份清单的方法。
迁移后检查清单
| 项目 | 操作 |
|---|---|
| 迁移摘要 | 关掉之前先读完；它列出了哪些内容无法传输 |
| FileVault | 检查状态；单独保存并验证新 Mac 的恢复方式，保留源 Mac 的恢复密钥，直到有意抹掉源机且不再需要用它恢复数据 |
| 邮件 | 重新添加账户，等索引建立完成后再评判搜索功能 |
| iCloud 和 Apple 账户 | 登录，然后确认新 Mac 出现在你的设备列表中 |
| 已授权软件 | 重新激活；在处置旧 Mac 之前先在其上取消激活 |
| 杀毒软件、防火墙、VPN 与安全代理 | 按需用当前安装包重新安装代理；恢复正常使用前，重新启用并验证两台 Mac 上所有临时禁用的保护措施 |
| 系统扩展 | 用 systemextensionsctl list 验证 |
| Homebrew | 在 /opt/homebrew 原生重装，重放一份 Brewfile |
| Docker 与虚拟机 | 重装；重建容器和虚拟机状态 |
| Time Machine | 决定是否继承旧的备份历史，然后确认首次备份成功完成 |
| 登录项 | System Settings → 通用 → 登录项与扩展；清理迁移过来的项目 |
| 旧 Mac | 保留旧机，直到重要的迁移文件和应用均已验证，且目标机备份已完成。之后再按下述 Apple 指引退役旧机 |
抹掉旧 Mac 前，请保留已验证的源机备份，并完成新 Mac 的备份。「抹掉所有内容和设置」要求使用搭载 Apple 芯片或 T2 安全芯片的 Mac，并运行 macOS Monterey 12 或更高版本。较旧的 Intel Mac 或其他不受支持的配置，请采用 Apple 提供的其他退役步骤。抹掉后，旧 Mac 将无法再作为恢复退路。
机器能正常工作之后，也值得做一遍通用的新 Mac 配置；前 24 小时必备设置清单涵盖了趁你已经在 System Settings 里时值得调整的那些设置。
特殊情况
从 Intel 到 Apple 芯片
Apple 支持这种迁移，也不要求 macOS 版本一致——它声明的唯一要求是每台 Mac 在其运行的版本上保持最新。变化的是软件。
推荐做法：迁移用户账户、其他文件与文件夹，以及设置；取消勾选应用程序；用当前的安装包重装应用。这样你到处都是原生构建，同时规避了 Rosetta 倒计时和 /usr/local 问题。代价是一个晚上。
如果你确实迁移了应用，就计划好之后对它们做一次审查，并替换掉仅支持 Intel 的那些。
FileVault 在迁移前、迁移中和迁移后
FileVault 加密的是宗卷，不是作为对象的文件。迁移从源机读取解密后的内容并写入目标机。Glenn Fleishman 在 Macworld 关于这个话题的文章描述了那个尴尬的结果：有可能出现 macOS 认为 FileVault 已启用但实际没有的状态，原因恰恰是迁移搬运的是未加密数据而不是加密容器。
实用的顺序：
- 在源 Mac 上，确认你知道自己的登录密码。FileVault 不会阻止迁移，但你得能登录。
- 在目标机上，通过 Setup Assistant 建立一个管理员账户，然后再迁移。
- 迁移之后，别想当然，去检查 FileVault 的实际状态：
fdesetup status- 如果它是关闭的，在 System Settings → 隐私与安全性 → FileVault 中开启它，并把新的恢复密钥记录在一个可靠的地方。
- 旧 Mac 的恢复密钥无法解锁新 Mac。请妥善保留它，直到有意抹掉源 Mac，且不再需要恢复其中的加密数据。单独保存并验证新 Mac 的恢复方式。Apple 说明了恢复选项，并提醒：缺少可用密码或恢复密钥可能导致无法访问数据。
多账户场景下有一个真实的坑。Mac 管理员长期以来都在报告，Migration Assistant 并不一定会给它创建的每个账户授予安全令牌，这意味着一个次要账户可能存在，却无法在启动时解锁 FileVault 加密的磁盘。Apple 没有记录这一行为，所以把它当作现场观察而不是规范。防御性做法成本很低：如果你把多个账户迁移到一台启用了 FileVault 的机器上，就逐个登录，并在重启后确认每个账户都能解锁磁盘，然后再让旧 Mac 退役。
短用户名相同的账户
这是少数几个真正有完善文档的边缘情况之一，Apple 用一个明确的提示来处理它。
如果新 Mac 上已经存在同名账户，Apple 的支持文章说你会被要求在两个选项中做选择：
- 替换新 Mac 上的账户，用旧 Mac 上的账户取而代之。Apple 指出你可能还有一个选项，可以把被替换账户的数据移到「已删除用户」文件夹里保留一份副本，之后可以访问。
- 在传输前重新命名旧账户，这样两个账户都会保留，你可以分别登录。
选择替换前，备份仅存在于目标机上的文件，确认不会丢失独有数据；即使是刚创建的账户，也可能包含新的工作成果。重新命名会保留两个账户。不确定时，请保留两者，不要假定目标账户可以丢弃。
彻底避开这个选择的办法，是在 Setup Assistant 阶段、任何账户存在之前就迁移。如果你是之后才迁移，最干净的做法是在创建 Setup Assistant 账户时刻意用一个不同的短用户名——比如 admin——这样迁移过来的账户能以原名落地、不产生冲突，而你还留着那个一次性管理员账户作为拥有安全令牌的备用账户。
受管理的 Mac 与工作用 Mac
如果新 Mac 已注册到设备管理服务中，不要自作主张。Apple 的 Managed Migration Assistant 记录在 Platform Deployment 指南中，它允许组织控制哪些内容会被传输：个人文件夹内哪些子文件夹是必需的、哪些被排除、哪些用户账户根本不提供迁移选项，以及系统级隐私设置是否会被带过来。它的要求是：源 Mac 运行 macOS 15 或更高版本，新 Mac 运行 macOS 26.4 或更高版本，并且新 Mac 已在 Apple School Manager 或 Apple Business Manager 中注册并分配给某个管理服务。
如果这就是你的情况，那么迁移可能会被策略以从界面上看不出来的方式塑形，而管理员事后会收到一份报告，包含日期、时间、传输的数据量，以及是否有文件未能迁移。开始之前先问一声。
迁移到一台你已经在用的 Mac 上
Migration Assistant 不只用于新 Mac；它可以迁入任何一台 Mac。但这种情况明显更脆弱，因为目标机上已经有状态了。
两条规则。第一，迁入之前先给目标机做备份——即使刚完成设置的目标机，也可能包含独有文件。第二，对上面那个账户冲突的选择要格外慎重，因为在一台你已经用了六个月的机器上选「替换」，跟在一台你今天早上才拆封的机器上选「替换」，含义完全不同。
常见问题排查
Migration Assistant 始终找不到另一台 Mac
问题： 新 Mac 无限期显示 Looking for sources…，或者旧 Mac 始终不出现在列表中。
解决方案： 这是发现失败而不是传输失败，Apple 的前提条件覆盖了大多数原因。仅在通过可信连接迁移期间临时关闭杀毒软件、防火墙和 VPN 软件；受管理的 Mac 应遵循 IT 指引。传输完成或停止排查后，在恢复正常使用前重新启用两台 Mac 上的保护措施。确认每台 Mac 都停在正确的步骤上：新的那台在从 Mac、Time Machine 或启动磁盘，旧的那台在传输到另一台 Mac。确认两台都保持唤醒、接着电源、彼此靠近。如果任何一台运行的是 OS X El Capitan 或更早版本，就把两台接入同一个 Wi-Fi 网络。另外，如果源机正处于从 Recovery 进入的 Share Disk 模式，那正是被报告会在此处无限期挂起的配置——让它正常启动，然后在它上面运行 Migration Assistant。
明明接了线缆，传输却跑在无线速度上
问题： 你接上了 Thunderbolt 线缆，但传输慢如蜗牛。
解决方案： 两个原因，按可能性排序。第一是线缆：MacBook 充电线有 USB-C 接头，但只能传输 USB 2 数据，在 MacRumors 那个相关帖子里，换成一根真正的 Thunderbolt 或 USB4 线缆就是解决办法。找一找那个闪电标记。第二是传输通道的选择：在源 Mac 上关闭 Wi-Fi，然后用传输界面上的 Connection Details 控件确认实际使用的是哪条链路，并在 System Settings → 网络 中确认 Thunderbolt Bridge 显示为已连接。
它说「大约还剩 1 分钟」，而且已经这么说了一个小时
问题： 倒计时坍缩成一个很小的数字后就不动了，但传输并未完成。
解决方案： 估算值静止本身不能证明失败。小文件或元数据处理是一种可能解释，不是诊断，也不是有文档依据的估算器说明。检查两台 Mac 是否报错，并确认电源和连接正常。为大型传输留出充足时间；字节计数器静止一小时并不是失败阈值。如果排查后决定重试，请在可用时使用 App 的取消控件，并先保全源机和目标机的数据。
无法使用此机器进行迁移，发生了启动网络错误
问题： 在安全码匹配之后，源 Mac 显示这个错误，迁移始终无法开始。
解决方案： 2025 年 9 月在 Apple 支持社区被报告，报告者在两台运行 macOS Tahoe 的 Mac mini 之间迁移，在以太网、Wi-Fi 和 Thunderbolt 直连上都看到了完全相同的失败。该帖子中发布的解决方案是放弃直连迁移：用 Time Machine 把源 Mac 备份到外置驱动器，然后从那份备份迁移。Apple 没有承认过这个具体错误，所以把它当作一个由社区报告、由社区验证了绕行方案的故障。在改走备份路线之前，先重启两台 Mac，再试一次。如果此次尝试需要临时禁用 VPN 或安全软件，请使用可信连接；受管理的 Mac 应先咨询 IT，并在尝试结束后立即恢复保护。
迁移完成了，但新 Mac 很慢而且风扇狂转
问题： 所有内容都传输过来了，但机器随后好几个小时都很烫、响应迟钝。
解决方案： 这几乎总是迁移后的索引建立，而不是迁移失败。Spotlight 正在为新写入的数据宗卷建立索引，「照片」正在重建它的分析数据库，「邮件」正在为它的邮件存储重建索引。在一个大型库上，这理所当然要花几小时，而且既吃 I/O 又吃 CPU。让 Mac 保持接电、唤醒并联网，第二天再评判它的性能，而不是当天晚上。
应用能启动，但它的后台组件毫无作用
问题： VPN 客户端、备份代理、安全工具或虚拟音频驱动能启动、看起来正常，却没有任何效果。
解决方案： 应用文件迁移过来了，系统级的批准没有。系统扩展、网络扩展和特权助手必须在它们运行的那台机器上安装并获得批准。用 systemextensionsctl list 检查实际注册了什么，然后用重新下载的当前安装包重装受影响的应用，而不是用迁移过来的副本。在 macOS 弹出提示时批准该扩展，之后再检查 System Settings → 通用 → 登录项与扩展。
Terminal 坏了，或者命令指向了错误的架构
问题： 从 Intel 迁到 Apple 芯片之后，shell 命令行为异常，brew 出问题，或者工具报架构错误。
解决方案： 迁移过来的 /usr/local 树和迁移过来的 shell 配置几乎肯定是原因。用 uname -m 确认机器架构，在 Apple 芯片上它应该报告 arm64。然后按照 Homebrew 的指引：在重装之前删掉从旧 Mac 残留的 /usr/local/bin/brew，原生安装 Homebrew 让它落到 /opt/homebrew，并修正你的 shell 配置，让 /opt/homebrew/bin 排在 PATH 的最前面。从一份 Brewfile 重放你的软件包列表，而不是信任迁移过来的那棵树。
迁移过来的用户账户在启动时无法解锁磁盘
问题： FileVault 已开启，但一个迁移过来的次要账户没有出现在预启动解锁界面上。
解决方案： 单凭这个症状无法判定安全令牌有问题。使用能解锁磁盘的管理员账户登录，然后打开系统设置 → 隐私与安全性 → FileVault。如果出现启用用户（Enable Users），请按 Apple 的说明选择受影响的用户，并输入该用户的登录密码。如果没有这个控件，或 Mac 受管理，请咨询管理员或 Apple 支持，不要猜测令牌修复方法；受管理的配置还可能涉及引导令牌和宗卷所有权。退役旧 Mac 前，重启并验证每个需要的用户都能解锁磁盘。
常见问答
如果两台 Mac 运行的 macOS 版本不同，还能用 Migration Assistant 吗？
可以。Apple 直接声明，两台 Mac 不必使用同一个 macOS 版本，只需要各自的 macOS 都是最新的。实践中版本跨度很大会提高迁移过来的应用行为异常的概率，这也是 Howard Oakley 建议在买到新 Mac 后尽快迁移的原因。
Migration Assistant 会抹掉或改变我旧 Mac 上的东西吗？
不会。Apple 的支持文章明确写道，Migration Assistant 不会删除旧 Mac 上的信息。请保留这个恢复退路，直到重要的迁移文件和应用已检查完毕，且目标机备份已完成。以后若要退役旧机，请按迁移后清单所述，使用与其机型和 macOS 版本相符的抹掉方式。
一次迁移到底该花多长时间？
Apple 没有为任何传输通道发布过吞吐量数据，所以没有官方答案。Apple 唯一的指引是大型传输可能需要数小时。作为一个参考点，Howard Oakley 报告说，从 Mac Studio M1 Max 迁移到 Mac mini M4 Pro，使用 Thunderbolt 3 SSD 上的备份，用时不到两小时。
我该在初始设置期间迁移还是之后迁移？
如果你确定想要旧机器的大部分内容，就在设置期间迁移。在 Setup Assistant 中迁移能让 Migration Assistant 干净地创建账户，并完全避开短用户名相同的冲突。之后再迁移也能正常工作，但你将不得不在替换和重新命名账户之间做选择，而这个决定是有后果的。
当 Migration Assistant 看起来卡死时，强制退出安全吗？
仅凭估算值或字节计数器不变，无法判定失败，即使已持续一小时。检查两台 Mac 的错误、电源和连接问题，并留出充足时间。如果出现明确错误，或排查后决定重试，请在可用时使用 Migration Assistant 的取消控件。保全源机备份和仅存在于目标机上的文件；除非确认可以弃用，否则请保留不完整的账户。若移除账户，也应保留该账户的整个主目录（个人文件夹）。
我能从一台无法启动的旧 Mac 迁移吗？
通常可以，但不是通过 Share Disk。改用 Time Machine 备份或宗卷级克隆，前提是备份位于本地连接磁盘的根目录，而不是某个文件夹内部。如果你没有备份，而且这台 Mac 是 Apple 芯片机型，那么从 macOS Recovery 进入 Share Disk 至少能让你通过线缆手动把文件拷出来。
结论
Migration Assistant 并非不可靠。它是规格说明不足——准确地说，那个几乎决定了你全部结果的选择（传输通道）是自动做出的，Apple 只在一份 IT 部署指南里记录了这件事，而且除非你主动阻止，它默认会选四个选项里最差的那个。
三个决定承担了主要分量。在开始之前决定你要迁移什么，因为在 Intel 到 Apple 芯片的迁移中取消勾选应用程序，能以一个晚上的下载时间为代价消除迁移后的大部分痛苦。给 Migration Assistant 一条有线路径，并在源 Mac 上关闭 Wi-Fi，因为 Apple 自己的文档说，如果你不这么做，两台机器就会建立点对点 Wi-Fi 链路。当倒计时停滞时，请结合错误、电源和连接状态检查进度。小文件处理只是一种可能解释；估算值或静止的字节计数器，即使持续一小时，也不能证明失败。
如果直连路径失败了两次，就别再折腾传输通道了，去改变源：把旧 Mac 备份到外置磁盘，然后从备份迁移。这一步就把那台运行中的第二台机器、网络和交互式会话全都从问题里拿掉了，而它正是解决了 Apple 自家论坛上那些故障报告的升级路径。
无论你做什么，都不要在 Apple 芯片 Mac 上按住 T 键。Target Disk Mode 是一项 Intel 功能，Apple 的文档在第一句话里就说明了这一点。Apple 芯片上的对应功能是 Share Disk，它位于 macOS Recovery 的 实用工具 → Share Disk 下，可通过 USB、USB-C 或 Thunderbolt 工作，而且它交给另一台 Mac 的是一个网络共享而不是桌面上的磁盘——这正是它是一个文件拷贝工具而不是一条迁移路径的原因。
延伸阅读：两台真机上的 Mac 迁移陷阱 · 2026 年最佳 Mac 备份策略