通常看来，微信主要有两个产品：微信和企业微信。但是如果细分的话，还可以分出公众号、小程序、JS-SDK、APP SDK等一些列应用，基本可以认为它们之间是平等的关系，并不是说小程序入口在微信客户端内就隶属于微信App。
本文主要关注在第三方开发过程中，在微信体系应用之间的账号互通问题。
提示、微信的核心资产是：关系链（好友、群、聊天），这一部分在当前是永远没有办法通过正规方法获取的（破解方式除外）。
大致关系
其中的核心操作是把不同的应用，关联到同一个微信开放平台之下，然后通过 unionid 来建立联系。
说明：企业微信并没有直接关联到微信开放平台，而是通过关联到公众号从而间接关联到微信开放平台的，至于为什么这么设计，不太清楚。
由于企业微信属于微信之后的独立产品，并且看起来应该也是由完全不同的团队开发，所以企业微信在与微信的互通方面，也给人一种磕磕绊绊的感觉。
另外，企业微信也支持微信小程序以及第三方应用，看起来与微信就更像了。
不过，小程序的最初宿主是微信客户端，现在新增一个企业微信的宿主，以后还可以用另一个小程序做小程序的宿主，这无限套娃也是煞费苦心了。
通过 unionid 来匹配同一个用户已经算是成熟做法了，唯一令人烦心的是群的问题。
- 我可以用微信创建一个群，但是如果这个群在创建的时候，没有包含企业微信用户，那我以后就没有办法使用企业微信加入这个群。
- 我可以用企业微信创建一个群，但是如果这个群在创建的时候，没有包含微信用户，那我以后就没有办法使用微信加入这个群。
除此之外，可以随意互相加入，也就是说，我在用微信加入一个群之后，可以用企业微信再入群一次。隔离又不是完全隔离，不知道是实现上的掣肘，还是特意为之。
由于分属于两个产品，同一个群在不同的产品里面，各自有一套账号体系。面对群里面的同一拨用户，这两个产品又有各自的诉求：
- 企业微信希望提高效率，必然需要开放一部分群的能力。
- 群是微信赖以存在的一个重要因素，必然需要对群严格控制。
所以我也能理解微信的苦衷：
- 往前开放一点，一定是各种程序化营销广告充斥群内。
- 往后收缩一点，企业微信就变成另一个微信，也就没必要存在了。
为了把企业微信视角的群与其他应用（当前只有小程序）视角的群匹配起来，企业微信单独提供了一个 opengid_to_chatid 接口来实现，不知道为什么不给群创建一个类似 unionid 那样作用的字段，
反而现在一种强行难受的感觉。
另外，微信群新增了“企业微信群成员”这类群成员（即，使用企业微信加群的用户），同一个用户的微信号与企业微信号同时加群，又需要想办法来识别不同的群成员账户是否属于同一个用户。
对于普通微信群成员，可以通过 unionid 来匹配，但是企业微信做了一个选择：没有给“企业微信群成员”赋予 unionid，而是选择新增通过 login 操作来间接实现用户匹配。
不知道企业微信这么考虑的出发点是什么，有可能是微信本身的限制。