很多政务、央企和集团企业已经有自己的移动门户。审批、报销、会议、公告、资产、考勤、工单、知识库等功能都放在一个APP里，员工打开手机就能处理日常事务。

到了信创改造阶段，问题会换一种形态出现：移动端已经有一套入口，PC端和桌面端还要再做一套；不同部门习惯不同终端，业务系统又分散在多个供应商手里。如果仍然按“每个终端单独开发一遍”的方式推进，项目会很快变重。

更现实的路线，是把办公门户拆成两层：宿主端负责账号、组织、权限、消息、设备能力和安全边界；具体业务模块以小程序形态接入，由小程序容器承载。这样移动端和信创桌面端可以复用同一批业务模块，门户团队不用反复维护多套页面和多套发布节奏。

一、信创门户的难点，已经从终端替换转到应用生态

信创项目早期通常关注终端、操作系统、浏览器内核、中间件和数据库适配。等底座逐步稳定后，应用层的问题会变得更明显。

一个集团门户里可能同时存在几类系统：OA、HR、财务、会议、资产、合同、采购、工单、知识库、差旅、党建、培训。每套系统的供应商、接口风格、权限模型和发版节奏都不一样。移动端做过一轮整合，桌面端又要重新对接一次，开发量会被终端数量放大。

如果移动端、PC端、国产桌面端分别维护业务页面，几个问题很难避开。

业务规则容易不一致。比如同一个报销入口，移动端已经支持新字段，桌面端还停留在旧版本；审批状态在APP里可见，PC端需要刷新页面；某个部门新增了工单类型，几个端的上线时间不一样。

测试链路被拉长。一次小功能调整要覆盖不同终端、不同账号、不同组织、不同版本。很多团队最终会把大量精力花在兼容验证上，业务迭代反而排不到前面。

供应商接入变复杂。外部服务一旦进入主工程，版本、权限、接口调用、异常处理都要由门户团队兜底。业务越多，主工程越难保持清晰。

这些问题靠压缩需求很难解决。门户本来就要承接越来越多的办公场景，需要调整的是业务承载方式。

二、宿主门户做底座，业务模块小程序化

多端门户不适合继续把所有功能塞进主工程。可维护的拆法，是让宿主门户只保留公共能力，把业务模块拆成独立小程序。

宿主门户承担几件长期稳定的事：统一登录、组织架构、权限校验、导航框架、消息中心、文件预览、扫码、定位、设备能力、审计日志和安全策略。这些能力和企业安全边界强相关，适合由门户团队统一维护。

小程序负责具体业务模块。例如会议室预订、费用报销、资产领用、采购申请、工单处理、培训报名、公告阅读、差旅申请等。每个小程序可以按业务线独立开发、独立发布，也可以由不同部门或供应商维护。

这样拆分后，门户团队的工作重心会从“写所有功能”转为“维护运行底座和接入规范”。业务团队要上线一个新模块，不必等待主APP发版，只要符合小程序接入规范，就可以走管理平台发布流程。

一套典型架构可以拆成四层：

这套边界对信创桌面门户尤其重要。桌面端并不只是把移动端页面拉宽，还涉及鼠标键盘交互、窗口尺寸、文件能力、外设能力和办公网络环境。把业务模块放到小程序层，可以让同一批模块在多端复用，再针对桌面端做必要适配。具体支持范围仍然要以项目使用的SDK版本、国产操作系统、终端型号和安全策略为准。

三、用路由表统一多端入口

门户从移动端扩展到桌面端时，入口管理容易变乱。一个功能可能同时出现在首页、工作台、搜索、消息卡片、组织门户和PC快捷入口里。如果每个入口都直接写业务页面地址，后期调整会很麻烦。

项目里可以维护一张服务路由表，把“用户看到的入口”和“实际承载的小程序”拆开。下面是项目侧示例配置，不是FinClip官方SDK方法签名。

{"serviceCode":"meeting-room","serviceName":"会议室预订","platforms":["ios","android","harmonyos","xinchuang_pc"],"miniProgram":{"appId":"office-meeting","path":"/pages/booking/index","minVersion":"1.4.0"},"fallback":{"type":"native","route":"portal://meeting-room"},"permission":{"roles":["employee","admin"],"orgScope":["headquarters","branch"]}}

这张表解决三个问题。

入口可以统一治理。移动端首页、桌面端工作台、搜索结果和消息卡片都从服务码找到对应小程序，不需要各写各的路径。

多端策略可以分开配置。某些小程序先上移动端，再灰度到信创PC端；某些功能只开放给总部或特定分支机构。配置层能表达这些规则，业务代码里不用塞满判断。

失败时有退路。如果小程序版本不满足要求、终端暂不支持、用户无权限，宿主门户可以回退到原生页面、Web页面或提示升级，避免把错误直接暴露给用户。

四、权限网关要放在宿主和小程序之间

小程序生态一旦开放给多个部门和供应商，权限问题不能只靠前端约定。宿主门户需要提供统一的权限网关，所有敏感能力都要经过校验。

常见能力包括获取用户信息、读取组织关系、发起审批、调用文件、打开通讯录、发送消息、调用摄像头、访问内网接口等。小程序可以申请使用这些能力，但不能直接绕过宿主安全边界。

项目侧可以把能力调用封装成统一网关，示例伪代码如下：

typeHostApiRequest={appId:string;api:string;payload:Record<string,unknown>;traceId:string;};asyncfunctioncallHostApi(req:HostApiRequest){constallowed=awaitpermissionGateway.check({appId:req.appId,api:req.api,userId:currentUser.id,orgId:currentUser.orgId});if(!allowed){auditLogger.warn("host_api_denied",req);return{ok:false,code:"PERMISSION_DENIED"};}try{constresult=awaithostApiDispatcher.invoke(req.api,req.payload);auditLogger.info("host_api_success",{...req,resultCode:"OK"});return{ok:true,data:result};}catch(error){auditLogger.error("host_api_failed",{...req,message:String(error)});return{ok:false,code:"HOST_API_FAILED"};}}

这段代码表达的是工程边界：小程序调用宿主能力时，必须经过权限判断、调用分发和审计记录。真实项目里需要按端侧框架、SDK初始化方式和企业安全规范做适配。

对政务、央企、集团企业来说，权限网关还有一个好处：不同供应商的小程序可以接入同一个能力体系。供应商不需要理解每个终端的账号实现，只需要按平台规范申请能力、处理返回值、记录业务状态。

五、发布治理要覆盖移动端和桌面端

把业务模块小程序化后，发布速度会提升，但治理不能省。否则只是把主工程里的复杂度搬到了小程序生态里。

小程序管理平台要至少覆盖五类动作。

上传和审核。业务线或供应商提交小程序包后，平台侧检查基础信息、版本号、权限申请、接口域名、页面路径和风险说明。涉及敏感能力的模块，需要走额外审批。

灰度发布。按组织、角色、终端类型、客户端版本、设备型号、网络环境等维度逐步放量。信创桌面端可以先在内测组织验证，再扩大到更多单位。

热更新。业务页面、活动配置、服务目录、非强制逻辑变更可以通过小程序版本更新完成，减少主APP发版压力。涉及宿主能力变更、SDK升级、安全策略调整的内容，仍然要走客户端发版。

回滚和下架。一旦出现兼容问题、接口异常或权限误配，平台要能把指定版本快速回滚，必要时直接下架入口。桌面端和移动端的回滚策略可以不同，不能一刀切。

数据统计。平台需要看到小程序访问量、启动耗时、错误率、接口失败率、终端分布和版本分布。没有这些数据，灰度策略只能靠经验判断。

六、迁移时先挑稳定高频模块

从移动门户扩展到信创桌面门户，不建议一开始就迁移全部办公系统。可以先挑几个稳定、高频、边界清晰的模块试点。

会议室预订、公告阅读、资产查询、工单列表、培训报名通常比较适合作为第一批。它们对交易安全的依赖较低，流程相对固定，用户覆盖面广，能快速验证小程序容器在多端办公场景里的加载、渲染、权限和发布流程。

财务报销、合同审批、采购申请这类模块也可以小程序化，但要更重视权限、审计、附件、电子签章和内网接口访问。迁移前需要把接口清单、权限清单、异常状态和回滚方案整理清楚。

桌面端适配时要重点关注三件事。

页面布局不要只按手机尺寸设计。小程序页面需要支持更宽的窗口、鼠标滚动、键盘输入和表格场景。审批列表、报表、工单流转在桌面端往往更依赖密集信息展示。

文件能力要提前验证。桌面办公离不开上传、下载、预览、打印、拖拽、剪贴板等能力。具体能力能否开放，需要结合宿主端能力、容器支持情况和安全策略确认。

网络环境要分清楚。政务和央企项目里经常存在内网、专网、VPN、代理和私有云部署。小程序包下载、接口访问、日志上报都要提前做网络分区设计。

七、对门户团队的变化

采用小程序生态后，门户团队的交付方式会发生变化。

过去，门户团队容易成为所有需求的开发出口。业务线提需求，供应商给页面，最后都要合进主工程。排期、测试、兼容、发版都压到同一支队伍。

拆成小程序生态后，门户团队可以把工作放到平台规则上：制定接入规范，提供宿主能力，维护权限网关，管理服务目录，控制发布节奏，监控运行质量。业务团队和供应商负责具体小程序模块，平台负责让这些模块可控地运行在移动端和信创桌面端。

这对大型组织更有价值。分支机构、下属单位、委办局、事业部都可以按统一规范提交小程序，平台侧用审核、灰度、权限和审计做治理。业务扩展不再依赖主工程持续膨胀。

例如选择FinClip小程序容器时，可以把目标拆成三步：先让现有移动门户具备小程序运行能力，再把一批低风险办公模块迁到小程序，随后扩展到信创PC端和桌面门户。每一步都要保留原生回退路径，避免一次性替换带来不可控风险。

信创办公门户的建设，不能停留在多做一个PC端入口。更有价值的方向，是把办公服务做成可复用、可发布、可审计、可回滚的小程序资产。移动端和桌面端共享同一套业务模块，门户团队维护统一底座，业务线按规范快速接入。这样一来，应用生态才能跟上组织规模，减少终端适配和重复开发带来的拖累。