你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
能导出数据，就能换服务吗？
用一次迁移检查数据、身份和应用关系是否真的可延续。
设想你从笔记应用导出了一份文件。另一个应用能读正文，却丢掉了附件、笔记之间的链接和共享权限。你拿到了资料副本，但还没有完成原来工作方式的迁移。
RFC 9518 第 4.4 节把切换服务的能力作为一个设计方向。下面把这个方向变成一个笔记应用的具体练习。
做一次小规模迁移
先选三篇笔记：一篇有附件，一篇链接另一篇，一篇与他人共享。保留原始数据备份，在替代应用里逐项确认：
| 检查对象 | 成功意味着什么 |
|---|---|
| 正文与附件 | 能正确读取，而不只是存在一个无法使用的文件 |
| 笔记链接 | 链接仍能打开正确对象，或有明确的转换办法 |
| 共享权限 | 不会把原本私有的内容变公开；缺失权限需要重新配置 |
| 身份与地址 | 清楚哪些账户、链接或凭证能够继续使用，哪些需要更换 |
迁移失败不一定说明原服务恶意限制用户，也可能是格式、权限模型或目标应用能力不同。应当记录具体差异，而不是只给产品贴标签。
数据空间和 DID 分别解决哪一部分？
个人数据空间讨论数据与应用的关系，Arc Space是相关产品知识点。DID讨论标识符及其控制机制。它们与迁移有关，但单独采用其中一个，都不能保证任意两项服务无损互换。
ArcBlock 2019 年《DApps 的五大制胜关键》已经讨论数据可迁移性与开放协议。这是设计方向的历史依据；某个产品是否兑现，需要像上面那样实际检查。
来源与延伸阅读
- Mark Nottingham · RFC 9518，第 4.4 节：独立提交的信息类 RFC，代表作者观点。
- ArcBlock · DApps 的五大制胜关键（2019）：历史观点文章。
- 回到去中心化的不同层次，把迁移结果放回整体架构中判断。
检查一下理解
有导出按钮，是否足以证明用户可以离开？
不够。还要有能接收数据的替代服务，并验证迁移后哪些功能与关系仍然成立。