很多企业启动鸿蒙APP建设时，难点并不只在ArkTS工程本身。已有Android、iOS和微信小程序已经承载了大量业务，服务入口、活动页、商城、设备控制、会员权益、售后工单都跑了多年。如果鸿蒙端全部重新开发一遍，页面、接口、测试用例、运营后台和发布流程都要重新铺，周期会被拉长。

例如某鸿蒙APP，在建设早期，可以把“复用已有小程序资产”作为一条工程路径。
ArkTS宿主负责账号、导航、设备能力、安全边界和统一入口；已有业务小程序通过小程序运行时承接页面和交互；小程序管理平台负责上传、审核、灰度、热更新、回滚和下架。这样做的目标很明确：鸿蒙端保留原生体验和系统能力，同时把已经验证过的业务模块尽量复用起来。

这类方案不是让鸿蒙APP变成一个页面容器。宿主APP仍然是主工程，小程序只是承接变化快、跨端复用价值高的业务模块。工程拆分做清楚后，鸿蒙端可以更快形成可用版本，后续业务更新也不必每次都等待宿主APP发版。

一、盘点已有小程序资源

存量小程序不应一次性全部搬进鸿蒙APP。更合理的做法，是按业务风险和复用收益分层。活动运营、会员权益、内容资讯、服务预约、售后工单、商城导购、设备使用说明这类模块，通常页面变化较快，原生依赖相对少，可以优先评估小程序化承接。

账号登录、支付确认、消息推送、设备配网、蓝牙控制、系统权限申请这类能力，应由ArkTS宿主统一掌握。小程序如果需要调用这些能力，通过宿主能力网关完成，不直接绕过宿主APP。这样既能复用小程序页面，也能避免把设备权限和账号安全分散到多个模块里。

盘点阶段要输出一张迁移清单，至少包含业务名称、现有小程序路径、依赖接口、宿主能力、兼容风险、灰度范围和回滚策略。没有这张清单，后续很容易出现“页面能打开，但关键流程跑不通”的问题。

二、ArkTS宿主负责主框架和系统能力

鸿蒙APP的主工程仍然要按原生应用的方式设计。首页框架、底部导航、账号体系、消息中心、设备列表、设置页、系统权限提示，都应由ArkTS宿主负责。小程序运行时嵌入宿主后，负责打开具体业务模块。

从工程边界看，ArkTS宿主至少要提供几类上下文：当前用户、组织或家庭空间、设备ID、客户端版本、网络状态、权限状态和安全策略。小程序只拿到当前业务需要的信息。例如售后工单小程序需要设备ID和用户授权状态；会员权益小程序需要会员等级和权益ID；内容资讯小程序只需要基础登录态和入口来源。

这层边界要通过项目封装固定下来。

{"routeId":"device_service_order","miniProgramId":"service_order_mp","entry":"/pages/order/create","hostContext":["userId","deviceId","clientVersion"],"hostScopes":["device.basic.read","file.image.select","message.notify.confirm"],"fallback":{"type":"native","page":"ServiceOrderAbility"},"release":{"grayGroup":"harmony_pilot","rollbackVersion":"2.3.0"}}

小程序包损坏、客户端版本不满足、运行时初始化失败、网络异常时，宿主APP要能给出原生兜底页或明确提示，不能把用户卡在空白页面。

三、小程序运行时承接已有业务模块

已有小程序进入鸿蒙APP后，需要重点检查三类兼容问题。页面层要看组件、样式、滚动、弹窗、键盘和安全区是否适配；能力层要看文件、相册、定位、扫码、分享、支付、设备能力是否有宿主映射；网络层要看域名、鉴权、Cookie或Token策略是否符合当前APP安全要求。

小程序运行时解决的是“在鸿蒙APP内运行小程序”的基础能力，项目侧仍然要做适配清单。不要默认一个微信小程序在新宿主里所有能力都能直接沿用。能复用的是业务页面、交互结构、部分前端逻辑和已有发布经验；涉及平台特有API、授权模型、支付链路和设备能力的部分，需要按宿主能力重新封装。

对于家电、IoT、车载、办公设备这类场景，小程序承接的边界要更谨慎。设备控制链路可以由宿主APP提供标准能力，小程序只做入口、说明、工单、场景配置或轻量控制。涉及安全风险的指令，必须经过宿主APP确认和权限校验。

四、三端适配要靠统一服务目录收敛

不少企业会同时维护Android、iOS和鸿蒙客户端。若每端都有一套入口配置和运营页面，长期会产生重复开发。小程序管理平台可以把业务模块沉淀成统一服务目录，三端客户端按版本、系统和灰度规则拉取可用服务。

服务目录里不要只存一个小程序ID。它还应记录支持端、最低客户端版本、入口位置、展示规则、灰度人群、依赖宿主能力和回滚版本。某个小程序在Android和iOS已经稳定，鸿蒙端还处于试点，就可以只向鸿蒙试点人群开放；等兼容验证通过后，再逐步扩大范围。

这样处理后，运营团队修改活动页、售后流程或会员权益页时，不需要分别找三个客户端团队排期。平台侧发布新版本，小程序运行时负责加载，宿主APP根据服务目录决定是否展示入口。

五、发布治理不能只看“能打开”

鸿蒙端复用小程序资产，测试标准不能停留在页面打开。发布前至少要检查四件事：小程序包完整性和签名校验，宿主能力申请是否匹配，客户端版本和运行时版本是否满足，异常场景是否能回滚或下架。

小程序管理平台可以把发布链路拆成开发版、体验版、灰度版和正式版。开发版用于模块团队自测，体验版用于鸿蒙端联调，灰度版面向内部或少量用户，正式版再进入全量服务目录。每一次发布都应记录版本号、审核结论、灰度范围和回滚目标。

热更新也要有边界。展示内容、表单规则、轻量流程可以更快更新；涉及宿主能力新增、敏感权限、支付或设备控制的版本，要走更严格审核。否则小程序虽然脱离了主APP发版，却可能把风险转移到运行时里。

六、监控和回滚要按小程序维度做

小程序接入后，监控体系也要拆到模块级。宿主APP需要记录运行时初始化、包下载、页面打开、宿主能力调用、异常退出和用户取消授权。小程序管理平台需要看到每个小程序版本的打开成功率、错误类型、灰度人群和回滚次数。

一旦某个版本在鸿蒙端出现异常，处理顺序应当清楚：先关闭入口或回滚小程序版本，再排查运行时、宿主能力和业务接口。不要把所有问题都归到鸿蒙主工程，否则排障会很慢。

对跨端团队来说，按小程序维度做监控还有一个好处：同一个业务模块在Android、iOS和鸿蒙端的运行情况可以放在一起比较。某端异常升高时，能更快判断是小程序版本问题、宿主能力差异，还是系统适配问题。

七、落地建议：从低耦合业务开始迁移

鸿蒙APP复用小程序资产，可以先选低耦合、高更新频率的模块。比如活动页、内容资讯、会员权益、售后工单、服务预约、帮助中心。这些业务能快速验证运行时、服务目录、灰度发布和回滚链路。

等这些模块稳定后，再评估更复杂的场景。比如设备控制、支付、订单、消息和文件能力，需要更完整的宿主能力网关和审计机制。迁移节奏不要被“已有小程序很多”带偏，关键是每一个模块进入鸿蒙APP后，都能被发布、监控和回滚。