已归档：未采用的挂载实验方案
保留磁盘映像、系统挂载配置与守护进程方案的验证结果。
实验方案，不是当前功能
以下保留 2026 年 9 月在 macOS 27.0（26A428）环境探索过的方法、结果与未采用的原因。它们不构成当前安装教程，也不表示 AppPorts 曾正式提供相应开关。
用磁盘映像承载数据
曾考虑在外部存储中放一个 APFS 磁盘映像，再把映像内部的卷接到应用目录。它的吸引力是把所需文件系统封装在一个文件中，似乎可以用于更多外盘格式。
在受测 USB 设备的两轮意外断开实验中，sparsebundle 映像重新接入后无法挂载；原生 APFS 卷也出现过数据库损坏。ASIF 尝试在有效拔盘测试前中止，没有成功或失败结论。具体过程和计数保留在意外断开实验。
因此当前容器迁移不把磁盘映像作为绕过 APFS 要求的选项。这不意味着所有映像在任何环境中都会失败，也不把有限样本当成故障率。
用系统挂载表固定位置
实验比较过在系统挂载表（fstab）中使用卷 UUID 与设备编号。受测环境里，UUID 形式未能挂载；直接设备编号的形式可以挂载，但编号可能在重启或重新连接后变化。
一个固定条目也不足以处理用户数据尚未解锁、应用容器授权和磁盘延迟上线。因此它没有成为当前给用户配置容器迁移的方式。实验失败只代表这组配置，不能扩展为 macOS 永远不支持 UUID 挂载。
由系统守护进程提前挂载
曾测试让系统级进程在登录前或解锁后直接挂载。FileVault 开启时，目标用户数据路径在解锁前不可用；解锁后，管理员身份也不能代替容器访问所需授权。
另一种尝试是让系统级进程仅启动已有授权的用户任务。用户会话存在时可以触发，会话尚未建立时会失败；这又引入系统级安装、重试与额外维护。当前采用用户侧任务接回，不要求用户安装这套实验守护进程。
只看命令成功、不核对实际位置
旧调查中发现，数据卷已被系统挂到其他位置时，指定挂载点的命令仍可能返回成功，却没有把卷接到原目录。因此当前检查真实挂载位置，并在需要时重试；仅看“进程已启动”或“返回成功”都不足以判断接回完成。
启动配置调整改善了部分样本的等待时间，但应用仍可能抢先启动。完整时序结果与限制见重启与自动接回。