有一次拉了个几个人建立了一个微信群，开始研究微信群的一些细节的实现机制，如群Notice、国际化处理、拉人、踢人、申请和撤销等。确实发现了一些实现的细节，也发现了一些小问题。
Notice实现
先说结论，微信（包括企业微信）的群管理Notice实现是基于客户端实现的，可能有两种实现方式：
- 客户端为主服务器为辅
资源信息，包括文案、语态等都是存在客户端的，服务器只负责通知客户端需要展示那种类型的的Notice，同时需要提供相关的填充数据的值。这里的值指的是用户uid，具体的名称由客户端根据uid 来进行填充，包括真实名称和本地昵称，这一块交给客户端去做。
- 服务器为主客户端为辅
资源信息，包括文案、语态等都是存在服务器端的，客户端只是负责接收服务器的通知然后进行展示，同时需要将下发的uid等信息进行名称的替换，同上一点。
缺陷
Notice中名称的渲染问题
由于微信的Notice是客户端实时进行渲染的，所有有些时候你会发现这样的Notice
这一点也就证明了昵称内容是客户端来做而非服务器来做，但是客户端获取用户uid对应的名称又需要一定的接口调用，导致中间有时间差。在这个时间差范围内进行了展示，就出现了上图的样子。 所以从另一个角度证明了，这个Notice是通过Push进行下发的，为了保证体验上的友好度，进行了实时展示，而没有等待名称获取到之后再去展示。 这个问题不是很容易发现，但是我测了几次都出现了，可能跟网络或客户端版本有关。
踢人出群的链接管理问题
这个缺陷其实很隐蔽，隐藏在邀请人入群操作的链接的处理上。如果A邀请了一个人入群并通过群主审核通过后，会给他发一个Notice，后面有一个撤销的链接，点击后可以对被邀请的人进行移除出群操作。
但是个链接并没有有效期，可以在任意时间段进行移除操作。好在微信对不同人邀请同一个人入群后移除的权限做了控制，即使A曾经邀请C入群成功，后来C被群主踢出群，后来又有B邀请C入群成功，此时A和B
都有撤销链接，但此时只有B的有效。
这个撤销功能其实是私信比较复杂的功能，它关乎产品的体验和对用户的理解，个人感觉这个是最不微信的地方。
另外，已经暴露出去的可操作Notice没有时效性这一点是一个很不稳妥的考虑。一般对资源的操作，尤其是涉及到登录状态的资源操作都应该有时效性的保证，如二维码有过期时间，SSO也有失效时间，包括用户的session和cookie 都需要有时间来保证。这里很显然是欠考虑的。
本文首次发布于 LiuShuo’s Blog, 转载请保留原文链接.
