Unicloud 云服务空间迁移不完全指南

你要稳稳的幸福，那稳稳怎么办？

简单朴素的想法总是觉得，自己花钱了或者找大厂的服务肯定比自己弄要稳定很多。但是事实是这样的吗？不是偶尔不是这样的，而是从来不是这样的。

我们看看google 都关闭了那些服务：

当然这些服务，对于开发者来说其实没那么大的影响。但是，国内的大厂的服务就靠得住吗？也未必，Findu旧版本依赖的阿里云的openim 旺信，最开始说是免费，到时候停止服务，也不过短短几年时间。因为这个原因，也导致自己直接放弃了之前的旧版本的维护。这次要说的是闺蜜圈APP的unicloud的云服务依赖。

上个月服务到期之后，直到续费才发现续费周期最长只能选择几个月，下面一行字写着：因阿里云 EMAS 功能逐步下线，uniCloud阿里云服务空间自2026年11月1日起不再支持新建，并将于2027年9月30日正式停服，续费后的到期时间不得晚于2027年8月31日，建议您尽快迁移，

点进公告之后，提示显示可以加群获取迁移工具，然而加群之后，工具却迟迟没有发布出来：

中旬的时候，看通知说月底发布。后来点开还是说是月底发布，现在依然是月底了。却连工具的影子都没看到，不得不说看来他们是真的不着急。

既然他们不着急，自己也不想再等了，不如完全自己动手吧。动手之前首先要清理清楚自己用到了uni的那些云空间的功能，可能的功能包括：

1.uni-id 账号登录系统 （）

2.uni-admin 管理后台 （✓）

3.uni-upgrade-center app升级管理工具 （✓）

4.uni-push 推送工具 （✓）

5.uni-statics 统计 （✓）

6.uni-chat ai会话框架 （✓）

7.其他的关联服务 （）

这么看起来，要迁移的东西不少，那么既然迁移就不得不提到另外一个问题，关于uni的云空间计费问题。虽然数据量不大，但是很多计费规则其实是从不同的维度对同一个东西的反复计数，这就导致一个仅有一万多用户的app 云空间每到月底就频繁提示剩余资源不足：

所以在实际迁移之后，准备放弃以下内容：

2.uni-admin 管理后台 （✓）

3.uni-upgrade-center app升级管理工具 （✓）

5.uni-statics 统计 （✓）

所以，要迁移的东西也就少了很多，数据可以完全丢弃，只需要迁移云函数就可以了。保证推送 以及 uni-chat的相关功能可以正常使用即可。不过新建空间的时候要注意，支付宝云不支持 universal-links。如果app已经绑定了通用链接，建议迁移到别的地方去，直接放到app的后台或者官网上。

并且支付宝云，哪怕你上传了文件，实际进行校验的时候仍可能过不了：

上传到自己的官网直接源码格式修改manifest.json文件，改成自己的正确地址就可以了。

剩下的就是常规部署流程：

1.云函数重新上传，直接通过hbuiler关联空间，上传代码即可：

2.数据库同步，目前没有工具，如果需要同步数据，可以通过后台数据库生成初始化数据导出数据，将导出数据复制到hbuider初始化代码的目录下，重新初始化数据库（注意：每次最多选20个表，并且在执行导出的时候，不要再去导出操作，会全部失败！）：

如果上面的数据有问题，最可靠的就是通过数据库页面的导出功能 导出jsonl格式的数据，在另外一个数据库直接导入：

3.云空间的资源同步？

抱歉，目前没有任何办法，甚至连批量下载的方法都没有。hbuilder带的云空间管理也只能查看，没有批量下载，这个就等官方吧。

4.迁移之后的域名绑定，需要重新绑定域名的几个地方：云空间的自定义域名、云函数的自定义域名。

如果不能直接修改绑定关系，可以添加一个新的域名，修改后端代码，新服务使用新的域名，旧的保持继续可用就行了。

之所以可以这么做是因为支付宝云支持绑定多个域名，所以后期可以把之前阿里云的域名也绑定过来，这样旧版的服务依旧可以正常运行。

如果不涉及到云空间的图片资源等等之类的到这里就算迁移结束了，至于代码怎么改，可以直接扔给ai。或者让ai跑一遍迁移分析，给出迁移步骤以及需要处理的内容和注意事项：

| 阶段 | 内容 | 状态 |
| --- | --- | --- |
| 0 | 准备与确认 |  已逐项复核（2026-10-24）。时间线/HBuilderX/密钥/云函数/索引均通过；备份含结构（54 集合）+ 全量数据（355,378 条），已核实无用户/订单/push cid | | 1 | 新空间创建 |  完成 | | 2 | 数据库迁移 |  表结构完成（3 张已上传，无数据搬运）；2.2 数据迁移 / 2.3 索引 / 2.4 验收均**不适用**（2026-10-24 确认） | | 3 | 云函数部署 |  完成（`babyUniPush` + `uni-ai-chat` 均真机验证） | | 4 | 推送切换 |  服务端 + 真机已验证（在线通道 `successed_online` 待复测） | | 5 | 云存储 |  完成（APK / 图标 / 二维码全部切外部域名） | | 6 | Universal Links |  全链路就绪（`.well-known` + 根路径均 200，深路径兜底已上线，Apple CDN 已收录）；仅剩重新打包 + 开放平台填 UL | | 7 | 客户端配置与发版 |  未开始（小程序域名、重新打包；打包前需修 `Dayima-Info.plist` 占位值） | | 8 | 后端 |  完成（唯一对接点 `uni_push.py` 已切） | | 9 | 切流与收尾 |  未开始（全端回归、旧空间保留） |

需要特别注意的一点，就是那个uni-upgrade-center这个东西和你绑定的域名没有任何的关系，所以如果app升级服务用的uni的服务，那么只能强制更新，让旧版本升上来才能解决这个问题。

## 阶段 6.5：旧版本 App 升级（uni-upgrade-center 兼容）

> 背景：≤ 5.3.20 的包升级走 **uniCloud 云函数** `uni-upgrade-center`；
> 2026-10-20（`d66f6f49`）起改用 HTTP `app.zhongxiaojie.cn/`。
> 旧空间 2027-09-30 停服后云函数消失，需评估对老用户的影响。
>
> 完整契约、真实返回、复现脚本：`开发文档/upgrade-center-接口存档/README.md`

- [x] **查清旧接口的数据拼接方式** ——  2026-10-26，直接调线上云函数采集 - 请求：`{action:'checkVersion', appid, appVersion, wgtVersion}` - 返回：`code 102` 整包 / `101` wgt / `0` 无更新 / `-101` 无版本 / `-102` 参数错 - 版本比较：按 `.` 分段转数字逐段比，多余段为 0 视为相等 - 真实响应已原样存档（`raw/`，含 4 个版本用例 + 网关原始外层结构） - [x] **采集脚本可复跑** —— `probe_upgrade_center.py`，走 uniCloud 阿里云原生协议 - 签名 `x-serverless-sign = HMAC-MD5(排序后 k=v 串, clientSecret)`（**不是 SHA256**） - 匿名授权 → `serverless.function.runtime.invoke` - [x] **兼容方案设计完成，但按决定不上线**（2026-10-26） - 映射规则已用临时脚本跑通并与旧接口逐用例对齐：5.2.16→102、5.1.89→102、1.0.0→102、5.3.20→0、缺参→-102、错 appid→-101 - 设计保留在 `upgrade-center-接口存档/README.md` 第四节，代码未提交（后端仓库已 `git reset` 回退） - 原因：见下一条限制——上线也没人调用 ###  关键限制：旧包到不了这个接口 旧包调用的是**云函数**，SDK 内写死发往 DCloud 域名： ```js {spaceId:"mp-77ffff8b-45c8-4ea4-9b30-98594e60f775", clientSecret:"…", endpoint:"https://api.next.bspapp.com"} // 无 failoverEndpoint ``` `spaceId` / `clientSecret` 编译进包内，域名不受我们控制，证书合法无法劫持 —— **无法重定向**。 且旧包弹窗前必调 `uniCloud.getTempFileURL([url])`，同样依赖旧空间存活； 即使能收到请求，这一步失败也会让弹窗被跳过。 > **结论：重写接口这件事本身没意义** —— 旧包只能依赖旧空间活到 2027-09-30。 > 这与服务端实现无关，是客户端编译产物决定的事实。 ### 因此真正要做的事 - [ ] 停服前（2027-09-30）把「桥接版本」推给老用户 - 版本号必须 `> 5.3.20`，且已使用 `app.zhongxiaojie.cn` 新升级服务 - 建议借旧空间仍在，用 `is_mandatory` 强更把 5.2.x 及更老用户拉上来 - [ ] 停服后仍未启动的设备：升级检查静默失败（`console.error`，不崩溃）， **App 本体可用**（业务接口在 Django），只能从下载页手动更新 - [x] **附带发现**：旧云函数平台判断有 bug - `platform = /iPhone|iPad/.test(event.headers)` —— `event.headers` 是对象，正则恒 false - 实测三种头部（`OS:ios` / `uni-platform:ios` / iPhone UA）**全部返回 Android 记录 + APK 地址** - iOS 那条 App Store 记录（`5.0.20`）永远命中不了 - 若将来真做兼容接口，要按平台显式区分（iOS 返回 App Store 链接

一个endpoint:”https://api.next.bspapp.com”} 就直接卡死了所有的可能性！

这是唯一一个无解的问题，如果用了uni的升级服务，请尽快强制更新，先拜托升级服务依赖问题，否则一旦原来的空间停了，那些没升级上来的版本就成了野孩子了。当然，这个东西有解吗？严格说来也有解，只要uni官方支持修改云空间的id，允许复用原来空间的id就可以了。

所以看到这里，如果你想长期做一个产品，或者说运营一个产品，那么还是尽量减少第三方服务的依赖，毕竟他们的死活切实影响到了自己的app的功能，如果真的死了，那时候临时去找个替代品又岂是那么容易？

小厂的靠不住，大厂的也不一定靠得住。

免费的靠不住，收费的也不见得靠得住。