首先承认uni im是个很好的产品，但也存在一些问题。由于uni im的推送基于appid，在需要推送消息的场景，包括但不限于不同appid应用的用户在同一群中聊天、添加好友、拉别人进群、自己进群、删除好友、同意添加为好友、收发im系统消息、群通知、创建群聊等等这些功能，在不同appid的应用之间实现这些功能，会有挺大的麻烦。比如以下场景很难实现：
业务场景类似拼多多，用户端可以跟商户端聊天，用户端的用户可以互相聊天。各端都需要实现离线推送能力。这个场景有以下解决方案，但都存在各自的问题：
1.用户端和商家端各自集成uni im，按照以上说的，由于是不同的appid，这个很难实现。
2.独立部署一个web版uni im，用户端和商户端通过webview接入这个im，应用在离线场景下，webview都没启动，这样肯定是无法实现离线推送能力。
3.独立部署一个uni im，让它的appid和商户端应用的appid相同，用户端和商户端通过webview接入这个im。这样存在两个问题，一个是只有商户端能收到离线消息，用户端收不到离线推送；另一个是用户端的用户登录到im后，相当于也登录了商户端，即用户在用户端注册后，也就获得了登录商户端的能力，这样虽然好像也不算什么大事，但不利于不同端用户隔离。
而其他的im产品貌似没有这个问题，核心根源在于uni im在执行推送消息相关的操作时，是基于appid的，即是区分应用的。uni im是个很好的产品，希望未来能解决这个问题，改变这个机制，使推送消息相关的操作跟appid无关。
Neveregret (作者)
我看了看其他的im产品，它们并没有非要绑定appid这个问题，基于unipush的uni im如果无法绕开绑定appid的话，是不是unipush本身就无法很好的实现im呢？相比其他的im产品，这确实是个问题。
另外，上述解决方法感觉并不能彻底解决以上问题，正如我帖子里说的，uni im中含有大量推送消息相关的操作，包括但不限于不同appid应用的用户在同一群中聊天、添加好友、拉别人进群、自己进群、删除好友、同意添加为好友、收发im系统消息、群通知、创建群聊等等这些功能，通过修改appid这种方式，细节太多了，改起来真的太难了。说个极端场景，如果是三个appid有通信需求，在当前绑定appid的机制下，几乎就没办法实现了。
如果实在绕不开appid这个事，能否调研参考下其他im的设计思路，来实现uni im呢？
这个问题不解决，感觉“多appid应用通信的同时实现离线推送”，始终会是个问题，并且这个需求其实挺广泛的，希望官方能够考虑一下，我也会持续支持并关注uni im
2024-08-15 15:42
DCloud_uniCloud_JSON
回复 Neveregret: 添加好友、拉别人进群、自己进群、删除好友、同意添加为好...这些功能，没有计划在不同 appid 中打通
其他关于必须 appid是逻辑问题，并不是技术问题
2024-08-16 11:31