先在https://dev.dcloud.net.cn/pages/app/push2 同一个appid下添加2个或以上的关联服务空间
通过一下代码发送push消息
const pushClient = uniCloud.getPushManager({
appId,
debug: false,
})
pushClient.sendMessage(pushParam)
eoc
- 发布：2026-06-26 17:12
- 更新：2026-06-26 17:58
- 阅读：65
产品分类： uniCloud/App
操作步骤：
预期结果：
正常的应该是绑定的多个服务空间的时候uniCloud.getPushManager应该可以返回多个空间push客户端。
正常的应该是绑定的多个服务空间的时候uniCloud.getPushManager应该可以返回多个空间push客户端。
实际结果：
{"errCode":"uni-cloud-push-error-10001","errMsg":"token is invalid"}
{"errCode":"uni-cloud-push-error-10001","errMsg":"token is invalid"}bug描述：
在https://dev.dcloud.net.cn/pages/app/push2 绑定多个空间，无法使用第二个服务空间的push，会出现token is invalid错误
返回的错误结果：
{"errCode":"uni-cloud-push-error-10001","errMsg":"token is invalid"}同一个appid可能会有两套服务空间或者在系统切换过渡到其他品牌的服务空间的时候会需要有两个，我的新用户在alipay的云空间，新用户在使用im的时候，会无法正常使用。
Ask小助手 - Ask社区AI助手
欢迎到专业群（ uni-im技术交流群 ） 咨询，群中有相关专业的管理员和群友。
从 bug 反馈内容来看，问题的核心是在 dev.dcloud.net.cn 的 uni-push 配置页面中，为同一个应用（appid）绑定了多个服务空间后，调用 uniCloud.getPushManager 发送消息时，第二个服务空间无法正常工作，返回了 token is invalid 的错误。
反馈内容分析
- 完整性：反馈包含了标题、问题描述、复现步骤、代码示例、预期结果和实际结果，结构上比较完整。
- 描述清晰度：问题描述得很清楚，指出了“同一个appid”、“绑定多个服务空间”、“第二个服务空间无法使用”这几个关键点，并且给出了具体的错误码
uni-cloud-push-error-10001和错误信息token is invalid。动机也说明了是因为新老用户可能在不同服务空间，这在业务切换场景下是合理的。 - 代码示例：提供的代码示例是标准的调用方式，但可能不够完整。关键在于，
uniCloud.getPushManager默认是与当前 uni-app 项目所关联的服务空间进行交互的。如果开发者期望通过传入appId就能自动区分和调用不同服务空间的 push 服务，这个预期可能和当前的设计机制有出入。 - 复现步骤：步骤清晰，即在开发者后台为同一个应用绑定多个服务空间后调用 API。
- 预期结果：用户期望“绑定的多个服务空间的时候
uniCloud.getPushManager应该可以返回多个空间push客户端”。这个预期需要商榷。根据知识库中关于“一个应用访问多个服务空间”的说明，uniCloud 是支持一个应用访问多个服务空间的，但需要通过uniCloud.init手动初始化不同的服务空间实例。然而，uniCloud.getPushManager是否支持这种多实例模式，或者在 uni-push 的配置体系下，一个应用（appid）是否被设计为仅与一个主服务空间进行推送通信，是判断此 bug 是否成立的关键。 - 分类信息：缺少 uni-app 的版本、HBuilderX 的版本、运行平台等信息，虽然对核心问题影响不大，但补充上会更完善。
对问题的判断
根据知识库和 ask 社区的反馈：
- 错误码
uni-cloud-push-error-10001：根据知识库中的“返回码说明”，10001明确表示“token错误/失效”。ask 社区中已有类似反馈（DCloud问答_178974），当时 DCloud 官方人员的回复是“push的token存储在opendb-tempdata表，一个 appid一条记录”。 - 核心机制：这句话非常关键。它揭示了 uni-push 2.0 的底层机制：推送的鉴权 token 很可能是以 appid 为维度存储的，且一个 appid 只对应一条有效的 token 记录。当你在开发者后台为一个 appid 绑定了多个服务空间时，系统可能会为后绑定的服务空间生成新的 token，并覆盖掉前一个服务空间的 token，导致第一个服务空间的 token 失效。或者反之，系统只认最新绑定的那一个服务空间的 token。
因此，这很可能不是一个代码层面的“bug”，而是 uni-push 2.0 当前设计上对“一个 appid 绑定多个服务空间”的场景支持不完善。系统设计上，一个 appid 的推送服务是唯一关联到一个服务空间的，以确保推送通道的单一性和稳定性。
结论与建议
这个反馈是有效的，它指出了产品设计上可能存在的局限，而非用户使用方法的错误。用户的预期（一个应用能通过多个服务空间推送）在当前的 uni-push 架构下可能无法通过简单的配置实现。
- 问题定性：这更偏向于一个功能需求或设计局限，而非操作层面的 bug。系统目前的机制可能不支持一个 appid 下的推送服务同时跨多个服务空间生效。
- 替代方案：
- 推荐方案：将需要推送的用户都迁移到同一个服务空间下。这是最根本、最稳定的解决方案。无论是新用户还是老用户，只要最终都在同一个 uniCloud 服务空间内，就可以正常使用 uni-push 进行推送。
- 临时方案：如果业务上必须使用多个服务空间，可以考虑创建多个应用（不同的 appid），每个应用绑定一个服务空间。在服务端推送时，根据用户所属的“新”或“旧”逻辑，选择对应 appid 的
getPushManager实例来发送消息。但这会引入额外的管理复杂度。
- 后续跟进：建议将此问题作为功能需求，反馈给 uniCloud 团队，看未来是否计划支持一个 appid 绑定多个服务空间进行推送的场景。
总结来说，用户遇到的问题是产品设计限制导致的，并非操作失误。建议调整业务架构，统一服务空间是最佳实践。
内容为 AI 生成，仅供参考
