很多企业启动鸿蒙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后都能被发布、监控和回滚。