企业官网建设流程全解析

HarmonyOS 业务里接入@wps/wps_sdk之后，打开 Word 往往只是起点。真正进入评审的，通常是「文档能不能外泄、截图能不能控、改动能不能追溯」。这些诉求并不靠再写一套编辑器，而是落在OpenFileRequest的策略字段上：水印、修订、enableLocalization与extraOptions。本文按调用链把参数对齐到可复用封装，字段语义以官方对接文档为准。

一、安全策略在调用链中的位置

对接文档的时序仍是硬约束：RegisterAppRequest成功之前，其它sendRequest会 reject。安全相关能力都挂在「已注册」之后的打开请求上，而不是注册阶段。

建议分层叠加，避免一次写满所有开关：

联调顺序建议：注册成功 → 沙箱只读打开 → 可编辑 → 水印/修订 → 再调enableLocalization与extraOptions。一次堆满时，ResultCode.ERROR很难归因。

二、水印参数怎么注入

水印通过wpsWaterMarkParams（类型WaterMark）注入。常用字段如下：

import{common}from'@kit.AbilityKit';import{WPSApi,RegisterAppRequest,OpenFileRequest,WaterMark,Revision,OpenFileExtraOptions,ResultCode,}from'@wps/wps_sdk';importfsfrom'@ohos.file.fs';functionbuildWatermark(text:string):WaterMark{constmark=newWaterMark();mark.Enable=true;mark.WaterMaskText=text;mark.Angle=-30;mark.FontColor='#19000000';mark.FontSize=24;returnmark;}

文案不要写死在页面按钮里。更稳的做法是由会话层传入「操作者标识」，打开模块只负责挂到req.wpsWaterMarkParams。预览与编辑共用同一打开函数，只差enableEdit，避免两套水印配置漂移。

三、修订模式与打开策略一起配

修订走wpsRevisionParams（类型Revision）：

审批、会签类入口通常希望一打开就进入修订，且作者名可追溯。注意：修订与水印、菜单开关彼此独立——开了修订不等于自动禁打印；打印/导出仍要靠extraOptions或落地策略约束。

functionbuildRevision(userName:string):Revision{constrev=newRevision();rev.UserName=userName;rev.EnterReviseMode=true;rev.ShowRevisionPanel=true;rev.EnterRevisionSilent=true;returnrev;}

四、enableLocalization 与 extraOptions 的叠加关系

enableLocalization控制是否允许文档在 WPS 侧持久化缓存：true表示允许落地；false或未设置表示不落地（在支持该能力的 SDK 形态下生效）。不落地时，云文档、分享、另存为、打印、导出、复制粘贴、截图等能力可能被 SDK强制关闭，即便extraOptions写成开启也无效。

OpenFileExtraOptions仅显式赋值的属性生效。常见字段包括：enableShare、enableCloud、enableSaveAs、enablePrint、enableExport、enableCopy、enablePaste、enableScreenShot等。方案评审时应先确认是否允许落地，再讨论菜单矩阵，否则真机上会出现「改了开关却没变化」。

functiontoSandbox(ctx:common.UIAbilityContext,src:string):string{constdir=`${ctx.filesDir}/wps_secure`;fs.mkdirSync(dir,true);constdest=`${dir}/${Date.now()}.docx`;fs.copyFileSync(src,dest);returndest;}asyncfunctionopenSecureDoc(ctx:common.UIAbilityContext,src:string,opts:{editable:boolean;operatorId:string;allowPersist:boolean;}):Promise<void>{constreg=awaitWPSApi.sendRequest(newRegisterAppRequest(ctx,APP_KEY,APP_SECRET));if(reg.code!==ResultCode.OK){thrownewError(`register${reg.code}`);}constpath=toSandbox(ctx,src);constreq=newOpenFileRequest(ctx,path);req.enableEdit=opts.editable;req.enableLocalization=opts.allowPersist;req.wpsWaterMarkParams=buildWatermark(`UID:${opts.operatorId}`);req.wpsRevisionParams=buildRevision(opts.operatorId);if(opts.allowPersist){constextra=newOpenFileExtraOptions();extra.enableShare=false;extra.enablePrint=false;extra.enableExport=false;extra.enableSaveAs=false;extra.enableScreenShot=false;req.extraOptions=extra;}constres=awaitWPSApi.sendRequest(req);if(res.code!==ResultCode.OK){thrownewError(res.msg??`open${res.code}`);}}

未开回传时，OK且无data通常表示拉起成功，不要当成业务已落库。若同时开了 URI 回传，拷贝到己方沙箱后，可按业务要求删除 WPS 侧临时文件，降低残留风险。

五、联调清单与常见坑

常见坑：把外部选择器 URI 直接传给OpenFileRequest；忘记enableEdit导致「以为能改其实只读」；在不落地模式下反复调extraOptions却看不到变化；冷启动连点触发多次注册。建议日志前缀统一[WPS][secure]，只打code/msg/allowPersist布尔值。

六、工程封装建议与回归范围

把策略收敛到单一模块后，页面层只传「操作者标识、是否可编辑、是否允许落地」三个开关即可。内部再决定是否挂水印、修订与extraOptions。这样产品改文案时不会误伤注册链路，测试也可以按 profile 做矩阵，而不是每个页面手写一份new WaterMark()。

建议在内部 README 固定回归范围：换 HAR 后 clean；调试包与上架包分别核对bundleName；水印预览/编辑各看一眼；不落地与允许落地各跑一次打印/分享是否符合预期；若开启关窗回传，确认业务沙箱已拿到文件再清理临时路径。弱网下再点一次打开入口，确认注册门禁仍然有效。

日志方面统一前缀，例如[WPS][secure]，输出code、msg、allowPersist、是否启用水印/修订的布尔值即可。不要输出完整appSecret，也不要在 Release 包把水印策略密钥打进控制台。Code review 可固定三问：策略是否单出口？不落地时是否误指望extraOptions？路径是否已进沙箱？

Word 与表格类小文件都要覆盖。偶发路径问题经常被误判成「水印没生效」或「客户端菜单坏了」。把打开建立在「已注册 + 合法路径」之上，后面叠回传或修订时，心态会稳很多；日常需求也通常只改策略模块参数，而不必每次从零打穿 Demo。

七、小结

在 HarmonyOS 上做 WPS 文档二开的安全策略，核心不是堆菜单，而是把水印、修订、落地与功能开关按层挂到OpenFileRequest。注册先就绪，沙箱路径再打开，策略字段后叠加；enableLocalization决定一批敏感能力是否被强制关闭，extraOptions在允许落地后才有细粒度空间。字段与申请渠道以官方对接文档为准；封装稳定后，产品侧改水印文案或菜单布尔，研发只需在策略模块调整，不必把鉴权重新散落到页面按钮。

基于 WPS Open SDK 鸿蒙版对接实践整理，仅供开发者参考。
官方对接文档：https://365.kdocs.cn/l/clQl5cek2NoT