核心能力
这一页把 .mfp 能做什么列清楚，每条都附上它成立的前提，方便你评估是否适合自己的场景。
能力清单
| 能力 | 说明 |
|---|---|
| 单文件承载多字体 | 支持 TTF / OTF / TTC / OTC / WOFF / WOFF2，可按需安装单个或整包安装 |
| 内容寻址与去重 | 字体条目以内容 SHA-256 命名，天然去重且可校验完整性 |
| 支持超大文件 | 强制 ZIP64，单容器可超过 4 GB |
| 流式读取与随机访问 | 中央目录在末尾，读索引即可按需提取单个条目 |
| 高频增量更新 | 通过 revision 链与 ZIP 追加语义，新增或删除字体只重写中央目录 |
| 跨平台可移植 | 格式本身不含平台相关内容，安装策略由客户端决定 |
| 向后兼容 | 新增可选字段不影响旧客户端读取 |
| 分级降级 | 可选字段缺失时按既定规则降级，不拒绝读取 |
单文件承载多字体
把一族字体的常规字重、粗体、斜体，或者一整套主题字体放进一个文件， 分发时不需要再配一个说明文档或目录结构。
安装粒度是可控的：客户端可以只提取并安装用户选中的那一个，也可以整包安装。 这一点由客户端实现决定，格式本身不强制某种交互。
内容寻址与去重
字体条目名就是它内容的 SHA-256。这个选择同时解决了两件事：
- 去重：同一份字体被重复加入时，条目名相同，只需保留一份
- 校验：读取时可即时验证条目内容是否被篡改或损坏，无需额外的校验文件
包内还支持可选的签名条目，用于需要更强来源保证的场景。 需要强调的是：完整性校验与"加密"是两件事 —— 格式不试图阻止你解压，只保证你能发现内容变了。
支持超大文件
强制使用 ZIP64，单容器可以超过 4 GB。对于收录整套多语言字库的场景， 这个上限通常够用；代价是对小文件有一点冗余开销，属于明确取舍。
流式读取与随机访问
ZIP 的中央目录位于文件末尾，因此读取端可以：
- 先读文件末尾拿到索引
- 按需定位并提取单个条目
- 无需解压整个包
对于"只想看看包里有哪些字体"这类操作，成本很低。
高频增量更新
通过 revision 链与 ZIP 的追加语义，新增或删除字体只需要重写中央目录， 不必把整个文件的字体数据重新写一遍。
这对"字体包持续迭代、每次只增删几款字体"的场景收益明显。 代价是要维护 revision 历史，具体策略留给客户端决定。
跨平台可移植
格式中不含平台相关内容：没有 Windows 注册表项、没有 macOS 字体册句柄、 也没有 Android 的字体目录约定。字体怎么装、装到哪里，全部由客户端决定。
因此同一个 .mfp 可以在不同平台上被不同的客户端读取，而不需要格式层面的分支。
向后兼容与分级降级
新增的字段一律为可选，旧客户端读到不认识的字段可以安全忽略。 反过来，当客户端遇到可选字段缺失时，按规范既定的规则降级处理，而不是拒绝读取。
这条设计让格式在演进时不会把存量实现排除在外。
能力之外的部分
下面这些不由格式规定，需要客户端自行实现或决定：
- 增量更新的具体算法与 revision 合并策略
- 恢复记录的生成方式
- 预览图与预览模板的渲染
- 字体的安装、卸载与冲突解决
- 界面交互与批量操作流程
实现这些时的模块划分、接口签名与伪代码，参见客户端实现指南。