是不是不需要重新开发，就能整合各部门已有的小程序、H5页面，构建统一的移动政务门户

虽然很多城市已经暂停了APP开发的项目，当对于已有的资源开始无法得到充分的利用，每个部门前期开发了一批小程序、H5页面，包括社保、公积金、医保、停车、文旅、教育等服务都有，当有的来自微信小程序，有的是部门早年建设的 H5 页面，还有一些业务已经做成原生页面，却没有被纳入统一的服务目录。

今天分享一下如何将这些已有的资源服务，整合为一个政务APP，通过一个入口就能够实现访问所有的服务。不同部门的服务由不同团队维护，后台系统和发布节奏也各不相同。如果只是把链接堆到首页，用户依旧会反复登录、来回跳转；如果把所有页面重新写进 APP 主工程，后续每次政策调整和页面修改都要等待客户端发版，原本分散的问题会变成一套更大的协作问题。

统一移动政务门户需要解决的，是服务资源如何共存、用户身份如何贯通、不同技术形态如何保持一致，以及上线以后由谁管理这些服务。小程序容器可以承担其中的运行层，但它要和宿主 APP、H5 接入层、小程序管理平台以及原有业务系统一起设计，单独集成一个 SDK 并不能自动解决门户建设的问题。

统一门户先统一入口和身份

门户 APP 的职责不应该是重新实现所有部门业务。它更适合承载稳定的公共能力：统一登录、实名状态、服务目录、消息中心、搜索、通知、原生导航，以及定位、扫码、文件选择等经过授权的设备能力。

用户从服务目录进入某项业务时，门户需要知道这项服务的承载类型、目标页面和所需上下文。例如，社保查询可能是一个小程序，政策公告可能是 H5 页面，某个高频缴费流程可能仍然保留原生页面。门户根据服务配置选择打开方式，并把当前用户的登录状态、地区、语言和必要的业务参数传给对应承载层。

身份贯通要比页面统一更早确定。门户完成实名认证后，小程序和 H5 不应各自再做一套登录流程，也不能把完整的用户凭证直接暴露给前端页面。项目通常会通过统一身份服务换取短时、限定范围的访问上下文，由业务网关完成接口授权和身份映射。服务结束或上下文过期后，容器和 WebView 都应能回到门户的统一登录处理，而不是各自弹出一套无法解释的登录页。

小程序、H5和原生页面可以共存

三种承载方式各有边界，统一门户不需要强行把它们变成同一种技术。

原生页面适合高频、强设备依赖和对启动性能要求高的流程，例如统一身份、消息、扫码、支付确认等公共能力。它们变化相对稳定，放在宿主 APP 中便于集中控制。

H5 适合已有投入较多、以内容展示或查询办理为主的服务。它的优势是服务端更新灵活，原有页面和后台可以继续使用。但 H5 依赖 WebView、网络和域名配置，和宿主之间的返回行为、文件上传、摄像头调用、消息推送也需要明确约定。把一个 URL 放进 APP 并不等于完成接入，页面加载失败、登录失效、版本提示和异常退出都要有统一处理。

小程序适合由部门或合作单位独立维护、需要持续迭代，又希望具备比 H5 更稳定运行边界的业务。小程序代码包由运行时加载，业务页面与宿主 APP 的主工程分开，宿主通过能力桥接向小程序提供经过授权的接口。以 FinClip 这类小程序容器为例，宿主集成 SDK 后负责提供运行环境，小程序运行时负责代码加载、生命周期、页面渲染和能力调用，业务小程序则处理具体的事项页面和流程。

这样的分工并不意味着所有旧 H5 都要迁成小程序。对内容型、变化不频繁、已经稳定运行的页面，继续使用 H5 反而更省事；对需要独立版本、灰度发布、离线包或多端复用的服务，再评估小程序化。技术选型的依据应当是业务更新频率、设备能力、运行稳定性和责任边界，而不是追求门户里只剩一种页面。

统一路由要管住服务入口

多种页面共存之后，路由不能由每个部门自己定义。门户需要建立一套服务标识，将服务名称、部门归属、承载类型、打开地址、默认页面、用户范围和状态纳入统一配置。

用户点击“公积金查询”时，门户读取的是一个服务配置，而不是直接写死某个 URL 或小程序页面路径。配置层判断当前服务应该打开原生页面、H5 还是小程序，并把必要参数交给对应的打开器。服务从 H5 迁移为小程序时，服务目录的入口不必改变，门户只需要切换承载配置并完成新版本验证。

路由层还要处理几个容易被忽视的动作。小程序内部返回时，应该回到小程序自己的页面栈；用户关闭服务时，回到门户原来的位置；H5 页面遇到登录失效时，不能把用户带到一个空白 WebView；服务下架后，旧入口要显示明确的维护或下线提示，而不是让用户一直看到加载失败。

统一路由也方便埋点。一次服务打开可以记录宿主入口、服务标识、承载类型、版本和结果状态。出现“某服务打不开”时，运营和技术人员可以判断是入口配置、容器加载、H5 网络、接口权限还是业务后台的问题，不用在多个团队之间凭感觉排查。

小程序容器承接独立运行的业务服务

当一个部门的小程序进入政务门户，容器承担的工作不只是把页面显示出来。它需要完成小程序代码包的获取、校验、缓存和加载，维护页面生命周期，隔离不同小程序的运行数据，并通过统一能力接口与宿主 APP 交互。

从运行机制看，小程序通常将业务逻辑和页面渲染分开处理。逻辑层执行脚本，视图层负责页面呈现，容器在中间协调路由、事件和宿主能力。这样，业务小程序不需要直接操作宿主的文件系统、账号数据或系统权限，调用摄像头、定位、扫码等能力时要经过宿主提供的授权接口。

政务场景里的权限边界尤其重要。停车服务可能需要定位和支付，政策查询页面可能只需要网络访问，材料上传服务还会涉及文件选择。权限不宜按宿主 APP 的总权限一次性放开，而应按小程序、接口和业务场景分别登记。用户撤销授权、接口超时或设备不支持时，容器应把错误转成业务能够理解的提示，并保证不会影响门户其他服务。

小程序容器还给多部门协作留出了独立更新的空间。部门页面调整时，可以更新对应小程序版本，不必因为一个表单字段变化就重新提交整个政务 APP。宿主侧的容器升级、系统权限变化和公共导航调整，仍然走 APP 自己的版本流程。两条发布通道分开，才能真正减少主工程排队。

H5 接入不能停留在“套一层 WebView”

已有 H5 资源要进入统一门户，接入重点不在页面能否打开，而在它能否遵守门户的公共规则。

登录方面，H5 不应长期保存门户的完整登录凭证。可以由宿主向统一身份服务申请一次性或短时访问上下文，再由业务服务换取自己的会话。不同部门的 H5 继续使用自己的接口和页面结构，但身份入口、会话过期和退出登录由门户统一处理。

导航方面，需要规定 H5 页面内的返回按钮、系统返回手势和关闭入口如何配合。文件上传、相机、定位和下载能力也要通过宿主桥接或明确的系统授权处理，不能默认 WebView 在所有手机系统上都表现一致。网络异常时，门户应能显示统一错误页，同时保留重试和返回服务目录的入口。

安全方面，要限制可访问的域名、跳转范围和外部页面打开方式，避免一个 H5 页面把用户带出政务 APP 后失去统一身份与审计能力。H5 服务的维护方、域名、接口、数据类型和下线条件也应该登记到服务目录中，否则服务虽然进入了统一入口，治理仍然留在原来的分散状态。

管理平台把资源变成可运营服务

当服务数量只有几个时，运营人员还能靠表格记录。部门和供应商一多，平台必须知道每项服务是谁维护、当前是什么状态、哪一版正在运行、哪些用户可以看到，以及出了问题由谁处理。

小程序管理平台承担的是云端控制面。以 FinClip 管理平台为例，可以围绕小程序资产、宿主 APP 关联、成员与角色、版本提交、审核、发布、灰度、回滚、下架和操作日志建立持续运营流程。小程序从开发版本进入体验验证，再进入审核版本和线上版本，发布过程有记录，运营人员能够看到服务处于什么状态。

H5 和原生服务虽然不经过同样的代码包发布流程，也应该进入同一套服务目录和运营台账。平台至少需要记录服务名称、主管部门、技术负责人、承载类型、入口地址、版本或发布日期、用户范围、所需权限、接口依赖、运行状态和下线条件。这样，服务目录展示的不是一张静态菜单，而是一份有责任主体、有生命周期的业务资产清单。

灰度与回退也要按服务处理。小程序可以按用户范围、版本、地区或设备条件逐步放量；H5 可以通过服务端版本、路由开关或后端配置控制新旧页面；原生页面则遵循 APP 发布流程。无论是哪一种承载方式，都需要有暂停入口、恢复旧版本或切换兜底页面的手段。服务出现异常时，平台先止损，业务团队再排查，不要让一个部门的故障拖住整个门户。

统一门户的价值在长期运营

一个政务 APP 能不能持续使用，不只取决于上线时接入了多少服务，还要看新部门能不能按规则加入，旧服务能不能及时下线，出问题后能不能找到责任人，业务变化能不能避开主 APP 的发版排队。

小程序、H5 和原生页面并存并不可怕，真正需要统一的是服务目录、身份上下文、路由规则、公共能力、发布责任和运行数据。小程序容器提供独立运行和跨端承载能力，H5 保留已有页面的交付效率，原生页面继续承担稳定的公共能力；管理平台把这些资源放进同一套审核、发布和运营规则中。

对建设方来说，这种架构减少的是重复重写和多方对齐的成本；对部门和供应商来说，保留了自己的业务迭代节奏；对运营团队来说，服务有入口、有状态、有版本和退路。移动政务门户不再只是把几十个链接摆在一起，而是形成一套能够持续接入、持续更新、持续治理的服务承载体系。