手Q机器人开发遇到的两个离谱Bug与排查思路

最近在折腾手Q机器人的流式输出功能，结果大半夜测出了两个让人哭笑不得的Bug。测试环境是手机QQ最新版（9.3.15.37995），问题主要集中在流式Markdown消息的渲染和转发上。如果你也在做类似的开发，或者刚好遇到类似情况，可以参考一下我的踩坑经历。

Bug 一：复制流式消息会多出“null”

先说第一个比较诡异的问题。机器人在私聊中发送流式Markdown消息时，在聊天窗口里看着一切正常，加粗的格式也没问题，甚至连在QQ内转发这条消息都很完美。但是，只要你长按这条消息，选择“复制文字”，复制出来的内容就开始“鬼畜”了。

现象复现

• 原消息：**晚上好呀，雪雪。茶给你温着。**
• 复制结果：null**

手机QQ复制流式消息异常示例

再换一个句子试试：

• 原消息：当然可以呀，像这样：这是一段**加粗的文字**。
• 复制结果：null当然

看起来像是复制功能拿到的“纯文本版本”（fallback）出现了严重问题。它不仅会在头部加一个“null”，还会把大段正文截断，只保留开头一点点内容。这对于用户体验来说简直是灾难，用户想转发复制结果到别处，结果拿到的是一堆乱码和残缺。

可能的原因与排查思路

初步判断，问题出在QQ客户端对流式式Markdown消息的处理逻辑上。

1. Fallback 段为空或异常：机器人发送流式消息时，可能会分多次更新消息体。QQ客户端在处理“复制文字”操作时，可能不是拿当前渲染后的富文本进行转换，而是去读取消息协议中的纯文本字段。如果这个字段在流式更新过程中没有正确维护，或者初始值被设为了字符串“null”，就会导致复制出“null”。
2. 协议兼容性问题：如果是分片发送的Markdown，可能QQ在合并或读取时，只拿到了第一个流片段的文本内容，这就解释了为什么“复制结果”里只有“当然”这两个字，而后面的“加粗的文字”全丢了。
3. 建议解决方案：
   • 在发送流式消息时，确保每次更新消息体时，text 字段都包含完整的纯文本内容，而不是增量片段。
   • 如果可能，尝试在消息发送完成后，再追加一次完整的消息结构，强制覆盖之前的缓存。
   • 作为一个临时绕行方案，可以提示用户使用“转发”功能代替“复制文字”，因为测试中转发功能的表现是正常的。

Bug 二：多条消息转发后顺序错乱

第二个Bug相对来说更像是客户端的逻辑小问题。我在群里吐槽第一个Bug的时候，连发了三条消息，顺序分别是 1、2、3。然后我把这三条消息一起转发到隔壁群，结果到了隔壁群里，顺序赫然变成了 3、2、1。

批量转发导致消息顺序反转示例

虽然这在日常聊天里可能只是个笑话，但在某些需要依赖消息时序的场景下（比如日志追踪、连续剧情输出），这种反转就非常搞心态了。

排查建议

这大概率是QQ客户端在处理批量转发时的排序算法出现了副作用。

• 可能是按消息ID倒序排列，或者在打包转发消息时，采用了栈（后进先出）的结构而不是队列（先进先出）。
• ** workaround**：目前看来没有直接的设置可以修改，开发者只能在需要严格顺序时，避免批量转发，而是逐条手动转发，或者通过机器人重新整理内容发送。

写在最后

发邮件给官方反馈暂时没人回，找客服的话懂的都懂，效率感人。这两个Bug目前看起来都是客户端层面的兼容问题，服务端能做的优化有限。如果你也遇到了类似的情况，欢迎交流一下看看有没有更优雅的绕过方式。

做第三方开发最怕的就是这种平台端的“玄学”Bug，只能祝大家开发顺利，少踩坑！