办公应用多端发布如何核验安装包与生产资源

一个修复已经进入源码，一个安装包仍然复现旧问题，两件事可以同时成立。尤其在同一个版本号下多次重新构建 Windows、Android 和 HarmonyOS 成品时，仅看文件名或关于页，往往无法确认用户拿到的究竟是哪一次构建。

本文以海豹办公 1.9.15 的发布核验脚本为案例，讨论源码、内置资源、成品模块、用户动作和分发文件之间的检查关系。目标不是增加更多“测试通过”的汇总数字，而是让每份结论能够关联到具体产物与具体能力。

把版本标识与产物身份分开

版本号说明面向用户的发布序列，不能独立证明两个文件内容相同。文件名也可能被手动修改。一次发布记录至少需要平台、架构、构建来源、文件大小、摘要校验值、签名状态与实际验收结果。

摘要值用于判断内容是否一致，签名用于验证相应信任体系下的发布身份和完整性，两者不能替代。应用市场是否允许上架又是另一层审核结果；拥有正式签名不等于已经通过市场审核。

对于同版本重打包，更清楚的做法是在内部保留构建标识和产物清单，记录旧包与新包的差异，而不是让运维人员凭下载时间猜测。对外沿用版本号时，也应让正式下载位置只指向经过验证的文件。

图1：案例项目的桌面工作台。关于页或状态栏中的版本号属于必要检查，但不足以证明当前包已包含某项修复。

为每条用户路径列出资源边界

桌面编辑器不只有一个可执行文件，还包含前端资源、主进程模块、兼容处理模块和平台集成文件。移动端又多了原生外壳、安装包内的本地页面、桥接代码、图标与启动资源。

例如登录 Logo 丢失，可能涉及前端资源 URL；启动页标识过大，可能来自原生密度图片；模板列表正常但编辑副本失败，则可能发生在资源服务装配。三者都能被描述为“最新版还是不对”，却不应被放进同一个前端截图检查。

先列出动作实际读取哪些资源，才能知道构建后应检查哪里。版本文件更新了，不代表安装包里的 Web 资源、原生启动图或辅助模块也同步更新。

完整性清单应说明覆盖范围

项目 main/integrity.js 为 main 与 dist 中的文件生成相对路径、字节数和 SHA-256 校验值，校验时检查缺失与内容不一致。清单结构验证还限制路径范围，并拒绝包含上级目录片段的记录。

这能帮助发现指定构建文件被遗漏或内容发生变化，但不能被写成“安装目录里所有内容都经过安全验证”。当前清单覆盖的是明确扫描的目录，不是系统依赖、外部运行环境或所有未列出的文件。

还要区分构建一致性检查与可信认证。如果校验清单与程序文件一起被替换，仅在包内自查摘要不能建立独立的发布者信任。签名、可信分发与外部保存的产物摘要需要各自发挥作用。

直接加载成品中的处理模块

单元测试加载仓库里的文件，成品测试应尽量加载真正交付的模块。案例的 verify-packaged-codecs.cjs 接收 app.asar 路径，从成品归档读取模块与依赖，核对版本和完整性，再生成实际文档产物。

脚本覆盖 DOCX 正文图片与页眉页脚、多工作表 XLSX、PPTX 文字图片和 PDF 页面操作，并包含 XLSX、PPTX 的连续保存重开检查。它回答的是“这个归档里的模块是否完成这些具体操作”，不是只问源码目录里的同名模块是否正常。

调用形式如下，路径需要替换成隔离的待验收目录，不能把日常用户资料目录当成测试输出位置：

electron scripts/verify-packaged-codecs.cjs <app.asar> <report-directory>

连续保存测试也要保留明确断言。文字、格式、公式、图片、备注和行列尺寸应分项检查，不能只比较文件能否重新打开。三个保存周期通过，只说明这些样本的对应属性在这三个周期内保留，不等于任意复杂文档无损往返。

成品模块测试与界面测试不要合并报告

后端处理器成功读写文件，不能证明菜单点得开、弹窗能关闭、F5 可以进入放映或用户可以选择导出路径。脚本本身也明确说明成品处理模块测试不自动化应用 UI。

独立的 Windows 成品脚本通过真实运行的主进程和页面执行用户流程。语言切换还有单独的冒烟脚本，可指定交付程序路径。将两类报告分开，可以避免在某项 UI 操作失败时仍然用“文档处理器全部通过”掩盖用户无法完成任务。

移动端必须同时检查 Web 与原生资源

案例移动回归加载生产本地入口，检查登录图片真实解码、模板预览页数及资源生命周期，并检查原生启动图片尺寸与可见范围。前端图片改好了，不代表原生启动页已经使用新的资源。

图2：安装包内页面相关回归所使用的模板预览实图。图片能显示，还要结合九页结构、编辑副本与资源读取断言检查完整动作。

这里需要明确运行环境。桌面 Electron 中加载 file:// 生产页面，可以发现部分路径和桥接问题，但并不等于目标 Android WebView 与 HarmonyOS 真机都已经验收。低内存、系统文件选择器、后台恢复与原生线程仍需设备层检查。

因此，“源码单测通过”“本地生产页面通过”“最终包已安装到真机验收”应作为三种不同结论保存，不应合并成一句“移动端全面测试通过”。

从验收文件到下载文件保持同一性

完成测试以后重新压缩、重新签名或替换包内文件，可能改变最终产物。应在最终处理完成后核对分发文件，并将实际发布的摘要与验收记录关联。不要用签名前或重打包前的摘要代表最终下载文件。

分发到两个代码仓库或多个渠道时，也需要检查附件是否为同一份预期成品，避免一个仓库仍指向旧包。正式安装包应作为发布附件管理，不应为了上传成品把密码文件、签名私钥或临时工作目录混入源代码提交。

平台命名也属于验收项。本项目普通 Windows、Linux 与移动界面使用“海豹办公”；微软商店 MSIX 清单则使用已保留的商店名称 seal-office。不能因为一个平台的身份约束，批量改掉其他平台的应用显示名。

用可复现记录支持下一次定位

一份有效记录应该包含产物身份、运行环境、已执行动作、预期与实际结果、报告位置和截图。复现资料需要脱敏，截图中的账号、业务文档和设备信息不应直接公开。

对失败保留分层信息，比反复重新打包更有价值：失败发生在进程创建、资源读取、页面操作还是原生生命周期，会决定下一步需要改动什么。没有失败证据时盲目更新所有依赖，可能只会让可复现问题变成偶发现象。

源码与复核入口

• 构建完整性检查
• 成品文档处理模块核验
• Windows 成品交互验收
• 移动生产资源回归

工程验收的关键不是把所有检查合并成一个成功标记，而是保留产物身份、已执行动作和实际运行环境。本文讨论的脚本覆盖范围与设备验收应分别记录；脚本存在本身不代表任意发布产物已经通过全部检查。