问 【鸿蒙二开】WPS Open SDK 能力回顾清单

已经接过鸿蒙 WPS Open SDK 的同学，周复盘时最常问：能力点那么多，工程里到底该盯哪几条？按对接文档，API 仍是一套：WPSApi + OpenFileRequest。本帖给一份最短回顾清单，适合刚跑通打开、准备收拢封装的同学。把「能打开」升级成「可维护」，核心不是再背参数名，而是确认仓库里是否还只剩一处打开封装在演进字段。

主链路三句话

1. registerApp 成功前不要 sendRequest（会抛异常）

2. 需要激活序列号时，在注册成功回调里 setWpsFileToken，别每次打开塞 wpsToken

3. 预览 / 编辑共用一个 OpenFileRequest 封装，用参数表达差异

WPSApi.registerApp(APP_KEY, APP_SECRET, {
  onCallback: (result: Result): void => {
    if (result.code !== ResultCode.OK) {
      console.error(result.code, result.msg);
      return;
    }
    if (!SdkConstants.isPersonalSdk()) {
      WPSApi.setWpsFileToken(PRO_SN);
    }
  }
});

专业版 / 个人版凭据不可混用。换 HAR 或换包名后 clean，再验正式包是否 1013。调试包正常、正式包失败时，优先查 bundleName 与申请批次，而不是先改业务字段。

打开与策略怎么叠

• 路径先拷到应用沙箱再打开

• enableEdit 控制只读 / 可编辑

• 水印、extraOptions、落地相关字段按需赋值；extraOptions 仅显式赋值生效

• 需要关窗结果时再开 wpsTransferType，与可编辑开关独立

联调顺序：注册 → 只读 → 可编辑 → 水印 / 菜单 → 回传。一次堆满所有开关，ResultCode.ERROR 很难归因。enableLocalization 等字段按交付形态生效；方案评审先确认约定，再测菜单是否被强制关闭。预览与编辑入口共用同一函数，可避免复制粘贴后字段漂移。

周复盘检查表

• 全仓是否只有一处 new OpenFileRequest

• 是否还残留逐次 request.wpsToken

• Release 是否打印完整 secret

• 正式包包名与申请凭据是否一致

• 关窗回传是否在真机验过 Result.data

建议把上面五条写进 PR 模板。多人并行接入时，冻结新增平行 Helper，统一走 Facade。统一版解决的是研发模型一致；产品选哪套客户端、是否要求不落地，仍按合规与授权决定。开发侧坚持一套 Facade，页面只调 prepare / open。字段语义以官方对接文档为准，随 SDK 版本核对。路径务必先落到沙箱；外部 URI 权限不足时常见泛化 ERROR。可编辑与回传是两个独立开关，按入口语义组合，不要在复制粘贴中写死「编辑=回传」。换 HAR 后务必 clean，核对正式包包名与申请凭据一致。周复盘时全局搜索 new OpenFileRequest 与 wpsToken，命中数下降比口头说「改完了」更可靠。把联调顺序写进用例表：注册 → 只读 → 可编辑 → 策略 → 回传，一次堆满开关很难归因。新人上手时，先画清调用链再对照对接文档核对字段，比直接复制 Demo 更稳。本帖仅作社区交流备忘，细节以官方文档与当前 HAR 说明为准。

更多参数见官方对接文档：https://365.kdocs.cn/l/clQl5cek2NoT

申请 SDK HAR 与凭据：m_open_sdk@wps.cn（邮件注明包名与所需版本）

技术交流 QQ 群：628436767