很多单位在国产终端上验证时才发现：OA 里的公文只能先下载到本地，用 WPS 打开，改完再手动传回去；浏览器里的“在线编辑”其实并不存在。没有 PageOffice 这类产品，国产终端上的 OA 连在网页中打开并编辑 Word 都做不到，剩下的只有下载、本地打开、打印，最多再手动上传。所谓留痕、套红、盖章、局部编辑，更无从谈起。信创走到今天，缺的往往不是又一台国产电脑，而是把公文重新放回 OA 里编辑的那“最后一环”。

一、换了国产电脑，为什么公文还是“改不了”

问题的根子，在于“在浏览器里编辑 Office”这件事，浏览器本身并不具备这个能力，它需要一个把本地 Office 和 Web 系统连接起来的中间件。

在 Windows 上，这个中间件过去是 IE 的 ActiveX 控件，后来演化为独立的客户端程序。它在 OA 里承担两件事：一是让用户不必把文件反复下载、上传，打开、修改、保存都在业务系统里完成；二是让系统在打开文档的那一刻施加控制——只允许修改指定的几个区域、以只读方式打开、把数据库里的数据动态填进模板。对 OA 来说，这两件事才是“在线编辑”的真正含义。

国产桌面操作系统上的浏览器基本都基于 Chromium 内核，ActiveX 和 NPAPI 插件机制已经整体淘汰，Windows 上那套控件无法照搬。更关键的是，Windows 上的控件并不能直接搬到国产终端，需要一套专门适配的中间件；缺了这一层，OA 只能在页面上提供一个下载链接，用户把公文存到本地、用 WPS 打开、打印，或者改完再手动传回去——在线编辑这一层，直接消失了。

那用云文档行不行？公有云文档确实能在浏览器里编辑，但对公文场景来说，它带来两个绕不过去的问题。

第一是数据边界。公文要上传到第三方服务器，再由第三方完成转换、存储、渲染，这与“数据不出内网、不出域”的要求天然冲突。第二是版式。云文档的通行做法是把 .docx 转成 HTML 再用网页渲染，字体、行距、表格、页码、红头位置在转换中很容易走样；公文对版式的要求近乎苛刻，一份通知的版记、成文日期、印发机关，差一行都不行，打印出来更是必须和本地 Word 完全一致。

所以信创替换的验收标准，不是“公文能下载、能打印”，而是“能像 Windows 客户端那样，在 OA 里直接打开、编辑、保存公文”：不用反复上传下载，能控制局部编辑，能以只读方式打开，能把业务数据动态填进模板。这一层补不上，前面换的芯片和操作系统就只是完成了“能用电脑”，还没有完成“能办公”。

二、PageOffice 国产版的技术路线

PageOffice 国产版没有继续沿着浏览器插件的老路走，而是把编辑动作交还给用户本机安装的 WPS，由PageOffice客户端程序负责“网页”和“本地 Office”之间的衔接。

从结构上看，一次在线编辑大致分为三层：

1. Web 业务系统：决定谁能打开哪份文件、能修改哪一部分、保存后进入哪个流程。文档的来源和去处，始终由单位自己的系统掌握。

2. PageOffice 服务器端类库：以 Java、.NET、.NET Core 等类库的形式集成在业务系统中，负责把文件、权限、数据区域和业务数据下发给客户端。

3. 客户端与本地 WPS：客户端程序在用户电脑上启动 WPS，打开的是真正的 .docx 文件，编辑完成后把文件回传给业务系统。

对用户来说，最直接的变化是不再需要“下载—打开—另存—上传”这一圈折腾；对业务系统来说，打开文档的那一刻仍然掌握控制权：哪些区域可编辑、是否只读、模板里填什么数据，都由系统决定。这两件事，正是 Windows 客户端上文档控件长期存在的理由，也是国产版必须原样补上的能力，而不只是让公文“能看”。

从技术上看，这条链路带来三个直接结果。

文档不出内网。 文件从单位自己的服务器传到员工本机，编辑完再回传，全程不经过厂商云端，也不需要公网账号。与公网完全物理隔离的内网环境同样可以部署使用。对党政机关和国企来说，这不是“加分项”，而是能不能通过合规审查的前提。

编辑的是真文档，不是网页。 因为调用的是本地 WPS，排版、字体、页码、表格、打印都与单机 WPS 一致。用户不会遇到“网页上看着好好的，下载下来全乱了”的情况，打印出来的红头文件也能做到所见即所得。

一套集成代码，两种客户端。 对集成商而言，最怕的是 Windows 一套逻辑、国产系统再写一套。PageOffice 的服务端调用方式在两种客户端上保持一致，客户端未安装时还能自动识别当前是 Windows 还是国产操作系统，引导用户下载对应平台的安装程序，不需要开发人员额外写系统判断代码。

三、国产环境适配到了什么程度

截至 2026 年 8 月发布的 6.7.0.1 版本，PageOffice 国产版的环境清单已经比较完整：

1. 操作系统：统信 UOS、银河麒麟；

2. 芯片架构：X86_64、ARM64、LoongArch64、MIPS64；

3. 办公软件：金山 WPS；

4. 服务器端：Windows、Linux、Unix，支持 Java、.NET、.NET Core 等开发栈；

5. 产品形态：国产版目前为面向信创环境的企业版。

更能说明问题的是版本迭代的方向。6.7.0.1 的更新里，有几条专门针对国产版：PDF 增加 PrintOut 打印能力， WebSaveAsPDF 从 Word 扩展到 Excel 和 PPT，POBrowser 窗口支持在同一页面自由切换 Word、Excel、PPT、PDF 四类文档。这些都不是“能跑起来”级别的适配，而是把日常办公里真正会碰到的细节一个个补齐。

四、公文流转的四项硬需求

环境适配只是入场券。公文能不能在国产终端上真正流转起来，还要看四个具体能力。

1. 不是全文都能改：局部编辑

公文会签时，最怕有人顺手改了正文。PageOffice 的做法是用“数据区域”划定可编辑范围：在 Word 模板里把需要填写的位置做成以 PO_ 开头的书签，再用表单模式 docSubmitForm 打开文档，只有被设置为可编辑的数据区域才能修改，其余部分全部只读。

例如，一份公文里“拟办意见”对应数据区域 PO_NiBan ，打开时只放开这一处，正文和其他意见栏保持只读：

这样既避免了误操作，也能在制度上划清部门责任：谁改的、改了哪一段，边界是清楚的。

2. 改了什么必须留得下：强制留痕

Word 本身有“修订”功能，但用户可以随手关掉，也可以接受、拒绝别人的修订，这在公文审阅里是不可接受的。PageOffice 的强制留痕模式用 docRevisionOnly 打开文档，修订状态由程序控制，用户无法关闭；不同用户的修订用不同颜色标记，并记录修订人姓名、时间和内容；任何人都不能接受、拒绝或删除其他人做的修订。

审阅环节结束后，核稿人员用 docAdmin 模式打开文档，才能集中处理这些修订、清掉痕迹，形成正式文件。留痕与核稿分开，恰好对应了公文“先审后发”的制度流程。

3. 红头不能靠手工贴：模板套红

套红是把正文套进红头模板的过程。PageOffice 支持在服务端用 WordDocumentWriter 直接操作模板：发文单位、文号、标题、主题词、成文日期等数据区域或数据标签由程序赋值，正文则以 [word]正文文件路径[/word] 的形式插入模板的指定位置。

套红完成后得到的仍然是一份真正的 .docx，后续流转、归档、打印都不需要再做格式转换。模板还可以交给业务人员自行维护，需求变化时不必改代码、重新发版。

4. 盖章与打印：最后的法律效力与观感

电子印章方面，PageOffice 提供两条路径：一条是产品自带的简易印章管理平台，部署简单，适合对电子签名法效力要求不高的内部场景；另一条是 ZoomSeal 电子印章，采用数字签名技术并带 CA 数字证书，符合《电子签名法》要求，适用于合同、公文等需要法律效力的场景。 打印则直接调用本地 WPS 的打印能力，红头、版记、页码与单机打印保持一致——这一点，恰恰是 HTML 渲染路线的云文档最难补齐的地方。

五、集成成本与长期账

对开发团队来说，PageOffice 的集成方式相对克制：服务端几行代码完成打开、赋值、保存，前端一次 JS 调用发起，官方提供 Spring Boot、Vue、JSP、ASP.NET 等常见框架的示例，照着改文档路径和业务参数即可。

对运维来说，客户端支持在线安装与自动升级，不必逐台重装，版本更新可以跟着业务系统一起走。

对采购来说，PageOffice 按服务器授权，客户端数量不限，每套授权一次购买后可长期使用，不按人头、不按年续费。单位人数越多、终端越分散，这种授权方式的总拥有成本优势越明显。需要说明的是，Windows 版与国产版是分开销售、分别授权的两套产品：单位如果同时有 Windows 终端和国产终端，需要各买一套。好在 Web 项目的集成代码只有一套，服务端调用方式在两种客户端上保持一致，不需要为两个平台分别开发、维护两个分支。对集成商来说，报价要按两套授权分别计算，技术方案则只需要准备一套。

六、结语

信创走到应用层，拼的已经不是“有没有国产版本”，而是“国产版本能不能把活干完”。公文在线编辑看似只是 OA 里的一个小功能，却同时牵着数据安全、版式规范、编辑留痕和流程可控四件事，任何一件掉链子，整个公文流转就转不起来。国产版如果做不到 Windows 客户端那样，信创就只完成了“换电脑”，没有完成“换办公方式”。

PageOffice 国产版补的正是这一环：让国产终端上的公文重新回到 OA 里，像在 Windows 客户端上一样打开、编辑、留痕、套红、盖章、打印，而不是只能下载到本地、改完再手动传回去。底座换完之后，应用层这一环补齐，信创才算真正闭环。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。