已收录 金山文档和 WPS WebOffice 到底怎么选？一套引擎，两种交付
一、这个问题的来源
过去半年我被问得最多的一句话是：
这个问题问得合理——两边的在线编辑器，技术形态几乎是同一套：服务端回调拿文件、前端 JSSDK 挂 iframe。所以只看接入文档，很容易觉得"这不就是一回事吗"。
但这两者解决的问题不一样。先把结论摆出来：
金山文档是一个产品：有自己的账号、自己的存储、自己的界面、自己的目录和分享体系，用户是"来用文档的人"。
WPS WebOffice是一套能力：提供的是文档的预览与编辑，文件、账号、界面、权限都在接入方那边，用户是"在别人的系统里看文档的人"。
再换一个更好记的说法：
家要有人住，引擎只需要被装进去。
下面逐条拆，最后给选型判断。
二、一张表先看清
维度 | 金山文档（开放平台 developer.kdocs.cn） | WPS WebOffice（solution.wps.cn） |
产品定位 | 在线协作文档 SaaS，提供文档创建、协作、分享、收集的完整产品能力 | 官方定义："在线文档预览编辑服务，可为接入方提供专业的文档处理能力" |
交付对象 | 使用文档的人，以及要"长出文档功能"的应用 | 要把文档能力嵌进自己系统的研发团队 |
文件存哪 | 金山云（个人"我的文档" / 组织"应用文档"） | 接入方自己的存储，服务端通过回调把下载地址给 WPS |
账号体系 | 金山文档账号，OAuth 2.0 授权登录 | 接入方自有账号，回调里传用户信息 |
界面归属 | 金山文档的界面与品牌 | 接入方系统界面，工具栏与入口可配置 |
能力边界 | 文档全生命周期：新建、目录、版本、分享、回收站、表单、多维表、AirScript | 聚焦已有文件的处理：预览、编辑、批注、修订、格式转换、权限、水印 |
终端 | 网页、App、小程序 | PC + 移动端，兼容主流浏览器与微信小程序 |
私有化 | 官方未见私有化说明（未核实） | 公网以 API 版交付；私有化走 WPS 文档中台，两者能力同源、交付形态有重叠（见 3.7） |
表格里最容易被忽略的是第 3 行和第 4 行——它俩决定了 80% 的选型结果，比"支持多少种格式"重要得多。
三、逐条拆开看
3.1 文件最终存在谁那儿
这是第一个分水岭。
金山文档开放平台把文档分成两类：
个人文档：挂在"我的文档"下，属于某个金山文档账号；
应用文档（appspace）：所有权属于组织，官方明确说明"用户登录个人金山文档账号也无法在文档列表中看到"。
注意后半句——它说明的是可见性隔离，不是存储位置迁移。文件仍然在金山的云上。对多数 SaaS、教育、协作类产品来说这是合适的选择：存储、备份、版本、回收站这些基础能力由平台承载，接入方不需要自建。
如果立项条件里已经写明"文件必须留在我的对象存储里"或者"文档内容不能出我的 VPC"，那么在评估阶段就应该转向文件留在接入方侧的方案，比如 WebOffice。
WebOffice 对应的设计是反过来的：接入方需要实现服务端回调，把文件元信息、下载地址、用户信息、权限、保存动作都交回给接入方。官方对这件事的表述是"账号、文件管理、文件存储可自行管控，无需迁移和账号对接"。
对接入方的要求也很明确：需要有一个自己的文件服务。文件、版本、权限、保存链路，这些都在接入方这一侧。
3.2 用户要不要多一个账号
金山文档开放平台走的是 OAuth 2.0：用户拿金山文档账号授权登录你的应用。这是标准的授权流程；如果目标系统本身已经有一套账号体系，就需要额外评估"员工是否接受再注册一个账号"这件事。
WebOffice 不走这条路径，因为它没有自己的用户体系——回调里告诉它"这次请求是谁、有什么权限"，它按这个渲染。终端用户不需要额外的金山账号（界面品牌也可以通过配置控制）。
在政企、金融这类对账号来源和登录链路有明确要求的项目里，"是否引入外部账号"通常会被单独列为评估项，这一点值得在方案阶段就确认清楚。
3.3 能力边界：文档产品 vs 文档引擎
金山文档开放平台的接口覆盖面很宽：文档 CRUD、分享、回收站、应用文档版本历史、WPS 表格、在线表格（ksheet，beta）、轻维表（dbt，支持 Webhook）、AirScript、以及表单相关接口（目前标注为 alpha），应用形态还分网页应用和小程序。
翻译一下：它的设计前提是接入方要的是一套"文档产品"，所以把文档周边能力一并提供了。
WebOffice 给的是另一套东西：1000+ 文档 Web SDK 接口、30+ 常规配置项、编辑/预览/批注/修订/水印、格式转换，以及官方"文档用户权限"里的 9 个权限位：read / update / download / copy / print / comment / history / rename / saveas（其中 history 控制的是历史版本入口是否可见，不是编辑权，别望文生义）。
翻译一下：它的设计前提是接入方已有自己的文件与产品体系，只缺文档处理这一环，产品侧的逻辑（目录树、搜索、分享链接、权限管理界面、回收站）由接入方自己实现。
所以如果目标本身就是"做一套在线协作文档平台"，基于金山文档开放平台会更省工作量；WebOffice 的位置是嵌入已有业务系统的文档环节，两者解决的是不同层次的问题。
3.4 格式和终端
WebOffice 官方格式清单中，代表性的几类如下：
文字：doc / dot / wps / docx / dotx / docm / rtf / txt / uof
表格：xls / xlt / et / xlsx / xltx / csv / xlsm / ett
演示：ppt / pptx / pptm / ppsx / potx / dps / dpt
版式：pdf / ofd
金山文档这边覆盖的是主流办公格式（Word / Excel / PPT / PDF），再叠加它自有的文档形态（智能文档、在线表格、轻维表）。两边的格式能力都建议以官方文档的最新说明为准。
有个细节值得注意：WebOffice 编辑态支持的格式比预览态少（比如 rtf、txt、xml 只支持预览）。做过文档系统的都知道这很正常——预览可以走转换渲染，编辑必须真解析。选型时如果客户的核心文件是冷门格式，一定要拿真实文件跑一遍，别只看清单。
终端方面官方口径是"支持 PC 和移动端，兼容主流浏览器及微信小程序等平台"。这一条对做移动办公、企业微信/钉钉内嵌的场景很关键。
3.5 接入形态：长得像，但不是一回事
两边的接入流程可以并排看：
WebOffice（三步）
控制台创建应用，拿 AppID / AppSecret；
服务端实现回调：文件元信息、下载地址、用户信息、权限、保存；
前端引入 JSSDK，初始化后挂到 iframe 上。
金山文档开放平台
申请应用（网页应用 / 小程序），走 OAuth 2.0 拿用户授权；
调 REST 接口创建 / 上传 / 管理文档（个人文档或应用文档）；
服务端取编辑预览 URL，前端 JSSDK + iframe 渲染；App / 小程序用自带 WebView。
第 3 步几乎一模一样。差别全在第 1、2 步——一个是在跟"自己的文件服务"对接，一个是在跟"金山的文档空间"对接。
这也是为什么很多团队评估时觉得"两边差不多"：他们只看了第 3 步。
四、选型：问自己五个问题
不用背表格，按顺序回答这五个问题，答案会自己出来。
Q1：文档最终存在哪里？
必须存在我方存储 / 客户内网 → WebOffice
存金山云没问题 → 继续问
Q2：终端用户能不能多一个金山账号？
不能，或者会引发合规问题 → WebOffice
可以，甚至是优点（跨端同步、分享方便）→ 继续问
Q3：你需要的是"编辑器"还是"文档产品"？
只要一个能看能改的界面，目录/分享/回收站我自己有 → WebOffice
我需要文档能新建、能组织、能分享、能收集 → 金山文档
Q4：界面品牌归谁？
界面要完全长在我的系统里，不希望出现第三方品牌 → WebOffice
不介意，甚至希望用户知道文档来自金山文档 → 金山文档
Q5：要私有化部署 / 信创吗？
要 → 这条线要单独谈 WPS 文档中台。
五个问题里，只要 Q1 或 Q2 有一个指向 WebOffice，后面的就不用问了——那是硬约束。
五、三种常见的场景错配
5.1 用文档产品去满足"文档能力"的需求
这类项目功能上通常能跑通，但方案里需要把两件事说明白：账号（终端用户通过金山文档账号授权登录）和数据（文件存放在金山云）。
判断信号：需求里出现"数据不出域""不能用第三方登录""文件要归档到我们的存储"——出现任意一条，就属于 WebOffice 更直接覆盖的范围。
5.2 用文档能力去满足"文档产品"的需求
技术上完全可行，工作量主要落在产品周边：文件列表、目录树、全文搜索、分享链接与有效期、回收站、权限管理界面、协作邀请等，都需要接入方自行实现。而这些能力在金山文档里是产品自带的。
判断信号：需求里出现"员工可以自己新建文档""要能分享给外部人看"——这已经是产品级需求，选金山文档会更直接。
5.3 接入前没确认回调网关的可达性
WebOffice 的回调网关需要公网可达。这在公有云部署里不是问题；如果客户系统部署在纯内网，或安全策略只允许出方向流量，就需要在接入设计阶段把这个条件确认下来，避免联调时才发现链路不通。
顺带一句：「文档不落地」出自 WPS 365 文档中心 / 文档中台的官方口径，solution.wps.cn 的开发文档里没有这个术语；官方博客在讲中台案例时也出现过"接入 WebOffice 开放能力"的写法。写方案时最好把"哪种部署形态、文件落在谁那儿"说清楚，避免用词混用造成理解偏差。
六、我的结论
如果只用一句话：
再补两句更实用的：
别用"能不能 iframe 嵌入"来做判断。两边都能嵌，这是最没有区分度的一个指标。
判断标准是数据归属和账号归属。这两个定了，剩下的都是细节。
同一套排版与协同引擎，一种交付形态是完整产品，交给使用者直接用；另一种是能力接口，交给系统去集成。两者各覆盖一段需求，先确认自己站在哪一段，比对着功能清单逐条打勾有用得多。
七、参考出处
WPS WebOffice 产品简介：https://solution.wps.cn/docs/product/summary
WebOffice 接入流程与回调机制：https://solution.wps.cn/docs/editing/flow.html
WebOffice 支持格式清单：https://solution.wps.cn/docs/product/format.html
WebOffice 计费说明：https://solution.wps.cn/docs/price/detail.html
WPS 开放平台首页（1000+ Web SDK、30+ 配置项、终端支持口径）：https://solution.wps.cn
金山文档开放平台 API 概览：https://developer.kdocs.cn/server/guide/api-overview.html
金山文档应用文档（appspace）说明：https://developer.kdocs.cn/server/appspace/overview.html
金山文档开放平台应用申请与能力分类：https://developer.kdocs.cn/admin/apply
WPS 365 文档中台（私有化形态）：https://plus.wps.cn/blog/p126432.html
金山文档定价页（WPS 365 套餐）：https://kdocs.cn/price
