这 Bug 让你的机器人“看起来在邀请”，其实啥都没干

你以为 invite_chatroom_members 是“点一下就好”的 API，其实它是个隐藏坑点的大杀器。

最近多位群友反馈了一个非常“诡异”的问题：调用 invite_chatroom_members 接口，所有返回值都是 success，日志也没有异常，但在实际的聊天窗口里，有的群根本没发出邀请。

于是你以为：啊，大概是我没注意。

再来一轮，一样的现象：服务器“说话算话”，客户端“一言不发”。

第一次看见这个现象时，查克还以为是缓存； 第二次，查克开始怀疑是微信版本 bug； 第三次，查克意识到问题远比预想的复杂。

Bug 现场

看似正常，其实一刀未出。

复现逻辑非常简单：

wcf.invite_chatroom_members("chatroom_id", "wxid1,wxid2,wxid3")
# 返回值：True
# 聊天窗口：没任何动静

这个问题在多个不同版本中被验证复现，并且不依赖群人数大小。甚至有用户反馈：空旷的 4 人小群，也复现了。

群友评论区高能回顾：

“加大延迟也没用” “我还以为是群人太多微信要确认，结果小群也不行” “明明后台返回 success，群里一点动作没有” “是不是这个人本来就在群里？不对，确认过，确实不在”

问题分析

真假“成功”的迷雾。

这个问题之所以棘手，有几个特别“坑人”的点：

1. 接口返回值是真的 True，日志上也真的成功了。一切都在告诉你“没问题，兄弟继续”，可你转头发现，群里一个人都没加进来。
2. 并非所有群都失败，是“偶发”。有时候你能成功拉进去人，有时候就是安静如鸡。于是你开始怀疑人生。
3. 失败没有弹窗，没有提示，没有任何 UI 反馈。它不像发消息那样会失败重试，像群邀请这种行为是“沉默失败”。
4. 你以为可以信赖系统日志，其实它也只能信你调用成功了，信不过实际结果。
5. 等等，好像有个规律：wxid_xxxx 都可以；但修改过的 wxid，好吧，也可以。不对，短的（6 个字母）不行！

问题的根源

同样是字符串（wxid），短一点就马上乱成一锅粥，长一点倒又貌似一切正常？

多数时候正常

多数时候正常

短一点的wxid却变空了

短一点的wxid却变空了

一翻排查，竟然是经典的 悬空指针（Dangling Pointer）” 和 SSO（Small String Optimization） 在作祟！这背后的内存真相，连老司机都得吓一跳。

对于 悬空指针，查克早有预防；但却是因为 SSO，才把这个 BUG 暴露出来，让查克知道预防（因为不小心）并没有生效。

算了，写那么多估计你们也不感兴趣（看不懂），直接说结论吧：已经修复……

后台回复 WCF 围观机器人🤖 后台回复 量子 研究量子计算

后台回复 保险 咨询保障方案