结论先说：文档编辑 SDK 只卖“在页面里打开、编辑与保存触发”那一层，落库与存储链路由接入方实现；石墨办公文档中台私有部署（Shimo Office SDK，以下简称文档中台）把编辑之外的能力一并接住。除了可嵌入的预览与编辑界面，它还提供服务端接口、高保真格式转换、权限复用和安全事件回调。分界线不在“能不能编辑”，而在“文件打开以后那六项责任归谁做”。
判断顺序很简单：先把文件存取、身份映射、权限判定、格式转换、事件消费、升级维护列出来，写明由谁负责，再看产品做完了哪几项。名字叫什么，参考价值不大。
一、差别在“编辑之外那几件事”
只比“有没有编辑器”比不出差别：两类都能显示文件。真正决定周期的是编辑之外的事，它们不会因为嵌了个编辑器就自动完成，只会从供应商的交付范围转进你的研发排期。
| 责任项 | 只买编辑器 SDK | 文档中台私有部署 |
|---|---|---|
| 编辑与预览 | SDK 渲染，页面自己搭容器 | JSSDK、JSAPI 嵌入业务页面 |
| 内容与版本 | 自建保存链路与文件存储 | 服务端 API 读写内容与版本，具体接口以开发文档为准 |
| 格式转换 | 自建，或另外采购 | 高保真转换与批量处理，支持 OFD |
| 身份与权限 | 接入方判定后传给编辑器 | 复用既有权限体系，开放权限接口 |
| 安全与事件 | 自加水印、自记审计、自消费回调 | 文字水印、安全事件回调；补偿仍归接入方 |
| 升级维护 | 有团队长期维护保存链路与升级 | 以版本说明与合同为准 |
第六行也值得说：文档中台不是买完就没人管。官网写得很直接——接入方仍需设计身份、权限、业务入口、事件通知和异常处理；中台补齐文档那一侧，业务那一侧仍在接入方手里。升级维护则要按版本说明与合同逐项确认。
二、名字靠不住：先看它把哪一层叫“中台”
这两个词没有统一口径，甚至可能反过来。公开的开发者文档里就有相反的例子：有的厂商把带存储、权限、组织管理的完整能力叫“文档 SDK”，把只提供预览编辑、存储和权限需业务方开发的叫“文档中台”。按名字选型一定踩空。
- 文件最后存在谁那里？答案若是“你的系统”，编辑器只负责渲染，它更接近 SDK。
- 谁能看、谁能改，由谁判定？权限要在文档侧再配一遍，说明没复用你的体系。
- 转换、水印、审计事件由谁产出？都要你自己造，买到的只是编辑交互。
三问都指向“你”，那就是编辑器 SDK；两项以上由产品承担，才谈得上能力底座。
三、接入方式定交接点，PoC 只验交接点
四类接入方式不是四选一，而是分工；它们同时决定“交接点”落在哪里。
| 接入方式 | 落在哪一层 | 交接点 |
|---|---|---|
| JSSDK | 前端渲染与交互 | 容器尺寸、样式与页面生命周期归接入方 |
| JSAPI | 页面调用编辑器能力 | 只读与编辑态切换由业务侧触发，接口以开发文档为准 |
| 服务端 API | 内容与版本读取、格式转换、权限信息 | 文件落库、归档与单据对应关系归接入方 |
| 事件回调 | 文档动作与安全事件 | 消费、重试与幂等归接入方 |
公开文档里也是这个结构：编辑器靠回调把保存状态交回存储侧，回调要接入方自己实现，ONLYOFFICE 的回调说明即是一例。
PoC 不用把功能点一遍，只验三个交接点，每项都写清失败谁负责、怎么补偿。
| 交接点 | 怎么验 | 通过标准 |
|---|---|---|
| 保存链路 | 断网、超时、重启后各保存一次 | 失败可见、重试可收敛，不出现“已保存”却未落库 |
| 权限双判 | 两个权限不同的账号打开同一文件 | 只读、编辑、下载判定一致，冲突有明确规则 |
| 事件补偿 | 触发典型事件，制造一次投递失败 | 可幂等重放，流程不卡住 |
这三项过了，再谈格式还原与并发容量：前者按真实业务文件另做，后者按下一节口径压测。
四、并发口径：并发是“同时在用”，不是“公司有多少人”
文档中台按并发计费，也最容易算错。并发是同一时刻正在预览或编辑的会话数，员工总数对应席位；峰值会话数通常远低于员工总数，具体要按业务系统访问日志估，而一次批量转换却能短时打满。
- 列动作：预览、编辑、转换、导出各算一类，转换和批量导出最容易打满。
- 找峰值：月结、报税、招标截止前一天，往往远高于日均。
- 折算会话：用业务系统访问日志估“同时打开的文档会话数”，没日志就先在一个部门试点。
- 写进 PoC：峰值怎么取、余量留多少、压测怎么做，都写进验收条件。
试用版按 30 天、30 并发提供，商业版 30 并发起售、含 5 个应用接入；费用与版本范围见文档中台定价，估算可先用并发计算器。
五、什么情况只买编辑器 SDK 就够
四条同时成立时编辑器 SDK 更划算：只嵌一个系统、只要能看能改、合规上不要求统一水印与审计、有团队能长期维护保存链路与升级。
四条里两条不成立，就该按能力底座评估：多系统要接、权限跟着业务单据走、要留痕可审计、没有专职团队维护集成。省下的不是采购费，而是重复开发三套预览与转换的排期。反过来也要认：并发、延迟与复杂文件表现以技术文档和 PoC 结果为准。
要按底座评估，可先看文档中台私有部署的能力与边界，再对照产品选型确认自己属于“单系统嵌入”还是“多系统输出”。
常见问题
买 SDK 还要自己做哪些事？
保存链路与文件存储、格式转换、身份映射、权限判定、事件消费与重试、水印与审计、兼容升级。把接口清单逐项标“谁实现”，标成“我方”的就是你的活。
文档中台包含编辑器吗？
包含。它以 JSSDK 和 JSAPI 提供嵌入式预览与编辑界面，同时提供服务端 API 和事件回调；但不含你的业务入口、身份体系和审批流程。
什么规模该上中台？
不按人数，按接入面：两个以上系统要接、权限要跟业务单据走、要统一水印与审计、没有专职团队维护集成，四条占两条以上就该按底座评估。一个系统、只做预览编辑，编辑器 SDK 更省。
判断自己属于哪一种，最省时间的做法是带上系统清单、三份真实业务文件和峰值并发：预约演示时逐项对，当场确认哪些由产品承担、哪些要你自建。也可以先看私有化部署方案，了解部署形态与交付范围。