已有微信小程序如何迁移到 FinClip 中运行，并完成测试与上架
分享到微信
已有微信小程序，想在自有 APP 里继续使用，通常不需要把所有页面重新做成原生页面。迁移的重点不在于“把代码包上传一次”，而在于把原来依赖微信环境的能力梳理清楚，再接入宿主 APP 和小程序管理平台。
FinClip 在其中承担两部分工作：小程序容器负责让小程序在 APP 内加载和运行；小程序管理平台负责版本上传、体验测试、审核、发布、灰度和下架。原有的订单、会员、内容等业务系统仍然沿用，不需要重建。
整套流程可以按七步推进。
第一步：确定迁移范围
先确定首个迁移版本要覆盖哪些业务，不要一开始把全部页面都纳入范围。通常优先选择访问频率高、业务流程相对完整、对微信专属能力依赖较少的模块，例如服务查询、内容浏览、预约提交或会员服务。
准备材料时，至少要有：
- 当前稳定的小程序代码分支和构建配置；
- 页面清单，标出首页、登录页、提交页、结果页和异常页；
- 微信侧能力使用清单，例如登录、支付、分享、订阅消息、扫码、地图、文件和云服务；
- 测试账号、测试数据、接口地址和常见错误码；
- 目标 APP 的系统版本范围，以及已经具备的登录、支付、定位、相机等能力；
- 版本负责人、审核人和紧急回退负责人。
完成标准：团队能说清用户从 APP 入口进入后，要完成哪一条业务链路，以及每一步由小程序、宿主 APP 还是业务服务端负责。
第二步：执行兼容性检查
在 FinClip Studio 中导入小程序项目，运行兼容性检查。检查工具会扫描项目中使用的组件和 API，并标出相关文件和行号。先根据结果建立改造清单，再安排开发，不建议跳过检查直接上传。
检查结果可以这样处理：
- 已支持的组件和 API：保留现有代码。已支持的
wx调用不需要为了迁移而统一改名。 - 页面表现相关项：在真机上重点检查长列表、富文本、动画、地图、输入框和键盘遮挡等表现。
- 微信专属服务：逐项确认替代方式。微信登录要接入宿主 APP 的账号体系；支付、分享、通知、云服务等能力，则根据业务需要改为宿主能力或项目服务端接口。
完成标准：每一个不兼容项都有处理结论，明确是改造、替换、暂不支持还是从首个版本中移除。
第三步：完成宿主 APP 接入
小程序运行在 APP 内，宿主工程需要先集成 FinClip 小程序容器。宿主 APP 继续负责原生导航、账号体系、设备权限、支付和消息等能力；小程序负责页面和业务交互；管理平台负责小程序的版本与分发。
联调前要重点确认两件事。
一是登录状态。原微信小程序获得的用户身份不能直接沿用到自有 APP。需要由宿主 APP 和业务服务端约定用户身份、会话过期和退出登录的处理方式，小程序只使用已授权的业务上下文。
二是设备能力。相机、定位、相册、文件、蓝牙等能力是否可用，取决于宿主 APP 是否已接入，以及用户是否授予系统权限。业务页面必须处理拒绝授权、设备不支持和调用失败，不能只覆盖正常返回。
完成标准：从宿主 APP 打开小程序后，登录、返回 APP 和已纳入范围的原生能力都能正常工作。
第四步：在管理平台建立关联
进入 FinClip 小程序管理平台，完成小程序资产和宿主 APP 的关联。建议按以下顺序操作：
- 创建或确认小程序信息，补齐名称、图标、介绍、类目和责任人。
- 在应用管理中创建或确认宿主 APP，登记对应的 Bundle ID 等应用标识。
- 将小程序关联到目标 APP，并核对宿主工程使用的应用配置是否一致。
- 确认 APP 内的入口位置，例如服务页、活动位、消息卡片或业务页面跳转入口。
- 明确下架或取消关联后，用户会看到什么提示或替代页面。
完成标准：测试人员能从目标 APP 的真实入口打开已关联的小程序。若工具里能预览、APP 内无法打开，优先检查应用关联和宿主配置。
第五步：上传代码并建立体验版本
在 FinClip Studio 中完成构建、预览和上传。上传前检查版本号、图标、页面配置、入口页和接口环境，避免把调试页面或测试地址带进体验包。
上传完成后，先指定为体验版本，配置体验成员，再让测试人员在目标 APP 内验证。体验版本可以设置测试页面路径和参数，适合直接进入登录、详情、订单确认等重点页面。
完成标准：体验成员能在真实 APP 内打开指定版本，并能重复进入关键页面，不受旧缓存或旧包影响。
第六步：按业务主链路完成测试
测试从真实 APP 入口开始，不要只在开发工具里点页面。建议按以下顺序执行：
- 入口与返回：检查首页、携参跳转、二级页面直达、返回上一页、返回 APP、重新进入和冷启动。
- 登录与会话：覆盖未登录、已登录、退出登录、切换账号、会话失效和重新登录。
- 原生能力：按实际业务验证定位、相机、扫码、文件、支付等能力，同时验证用户拒绝授权和系统限制时的提示。
- 网络与异常：检查弱网、断网、接口超时、服务端报错、重复提交和页面重新进入。
- 多端验证：如果本次覆盖 iOS、Android 或鸿蒙，应分别保留机型、系统版本、小程序版本、宿主版本和问题记录。
完成标准：主业务链路、登录状态和异常提示都有测试记录；阻断问题关闭后再创建审核版本。
第七步：审核、发布、灰度与回退
体验测试通过后，在管理平台中选择上传的代码包创建审核版本，按要求填写测试账号、登录方式和操作说明。审核通过后，再发布为线上版本。
首次迁移上线，建议由版本负责人确认后手动发布。涉及登录、支付、个人信息、政务或医疗服务时，更需要保留人工确认和完整的发布记录。
已有线上版本后，可以通过灰度规则逐步放出新版本。未命中规则的用户继续打开线上版本。灰度期间应关注小程序启动、页面报错、崩溃、接口异常和业务完成情况；发现异常时回退到已验证版本，紧急情况下也可以下架或取消宿主关联，停止继续打开服务。
完成标准：发布前已经确认回退版本、操作人和通知方式，遇到问题时不需要临时寻找后台权限。
迁移后的日常管理
迁移完成后，页面和业务服务的日常更新可以走小程序的体验、审核、发布和灰度流程，不必每次都绑定主 APP 发版。宿主 APP 需要新增原生能力、调整底层运行环境或改动 APP 入口时，仍应按客户端发布流程处理。
边界清楚以后，现有微信小程序中已经验证过的页面和业务逻辑可以继续复用，自有 APP 也能获得一条可管理、可测试、可回退的小程序服务发布链路。