你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
FS、JSON、KV 和 DID Space 有什么不同？
共同操作不抹平存储位置、数据结构和持久化契约。
从同一份报告出发
| Provider | 理解入口 | 不应推断的能力 |
|---|---|---|
| FS | 映射一个允许访问的本地文件范围 | 任意主机路径都可访问 |
| JSON | 把 JSON 的结构呈现为可寻址节点 | 所有字段写入都等同数据库事务 |
| KV | 用键组织值 | 所有后端都提供相同排序或事务 |
| DID Space | 访问所属数据空间中的资源 | 只知道 DID 就拥有读写权限 |
读取“报告标题”可以经过类似的 AFS 操作，但它可能来自文件解析、对象字段或远端空间。应用要依赖的是声明并实现的行为，而不是类名。
替换后端前做什么
列出调用方真正依赖的能力：持久化、分页、条件写入、通知、错误分类。换 provider 后，分别检查成功行为和失败行为。尤其不要把内存中的单实例测试，写成跨进程持久化或并发正确的证据。
把“报告”落到具体数据上
下面是同一业务对象的四种存储示意，不是四个 provider 自动共享的路径：
- FS：允许访问的目录中有
report.json文件，文件内容包含标题和状态。 - JSON：一个 JSON 文档中有
report对象，其title字段保存标题。 - KV：键
report对应一个值，值中包含标题和状态。KV 即 key-value，键值存储。 - DID Space：报告保存在由身份与权限控制的数据空间中。DID 是去中心化标识符，用来标识身份；知道标识符并不等于通过访问授权。
这些数据的生命周期由实际后端决定。文件是否写入磁盘、KV 是否持久化、远端空间是否可达，都需要分别确认。若希望替换后端而保留 /work/report，需要由 provider 的映射契约明确维持这条引用。
练习：把上面的 JSON 报告换成 KV 值，先确认 /work/report 是否仍返回同样的数据结构，再检查更新是否需要版本条件；不要从共同的路径形式推断相同的存储保证。