最近在做一个小工具，核心功能很简单：
👉 监控事件 → 触发条件 → 机器人推送消息
一、技术选型：没做调研就直接开冲
提到国内消息机器人，大家第一反应基本就是这些：
- QQ 机器人
- 企业微信机器人
- 钉钉机器人
- 飞书机器人
出于一点“情怀”，我在没有提前做好技术调研的情况下：
👉 直接无脑冲了 QQ 机器人
现在回头看，这一步真的是后面踩坑的起点。
二、接入 QQ 机器人：前期一切都很顺
我先去 QQ 机器人官网完成了基础操作：
- 注册开发者账号
- 新建机器人
- 拿到 AppID、密钥等配置
- 接入到我现成的小系统里
我的小系统本身已经支持：
👉 TG 推送（懂得都懂）
所以当时的想法非常朴素：
现有的消息触发机制都已经准备好了，就差各种推送渠道对接了。
刚开始我习惯性的思路是：
把机器人拉进 QQ 群，然后让它按照约定规则定时发消息。
结果，现实第一棒直接敲下来：
❌ 个人开发者不支持 QQ 机器人进群！
三、第一个大坑：QQ群场景必须企业认证
想把 QQ 机器人拉进 QQ 群做消息转发通知，必须得是：
- 企业认证开发者
- 提供营业执照
- 法人身份证号
- 甚至法人照片等资料
说实话，当时我的第一反应就是：
我只是想做一个供自己学习或者娱乐使用的小工具而已啊…… 😅
这一步真的很劝退。
四、退而求其次：那就做单对单私聊机器人
既然群聊走不通，那我就退一步：
👉 改成 单对单私聊机器人
于是开始一通操作：
- 查官方文档
- 对接接口
- 调通消息发送
- 测试消息是否能正常收到
整体流程跑下来，其实还算顺利。
中间只有一个比较明显的坑：
⚠️ 坑点：用户对话 ID / openId 获取方式不够直接
这一点和 TG 很不一样。
TG 的用户标识拿起来通常更直接，但 QQ 机器人的用户对话标识，官方没有通过一个很直观的链接查询接口直接给出来。
你需要自己去翻 QQ 官方接口文档，然后手动写方法查询出用户对话 ID，最后再导入配置。
这一点在实际开发里还挺反直觉的。
当时我踩到这个坑的时候，也顺手截了图：
五、阶段性成功：终于把消息发给自己了
good，经过一系列折腾，也是成功把消息转发给了我自己。
看到消息真的发出来的时候，心情还是很不错的，毕竟这说明：
- 整个链路通了
- 接口也跑起来了
- 机器人确实能完成私聊通知
当时的截图也留了下来：
说实话，看到这一幕的时候，我还挺满意的。
甚至已经开始想：
后续可以再多配几个用户，比如给我的小伙伴也推送一下。
结果，我高兴得还是太早了。
六、噩梦开始：一下午怎么才收到零星几条？
还没等我高兴多久，我就发现不对劲了。
按我的预期，消息应该会比较稳定地往外推。
但实际情况却是：
一整个下午，居然只发了零星几条通知给我。
我当时第一反应是：
- 后台是不是出 bug 了？
- 触发逻辑是不是有问题？
- 是不是我的代码哪里写漏了？
于是开始回头检查：
- 后台任务执行情况
- 消息触发条件
- 接口调用逻辑
- 重试和限流逻辑
结果最后看日志，发现真相了。
七、真相：不是代码坏了，是被平台限流了
日志里打印的是这个：
[QQ] Wakeup 通道被平台限流(40034122)，仍会继续尝试发送；
当前参考冷却剩余 1800 秒。 [QQ] 本次发送失败（wakeup 冷却剩余 1800 秒）
八、终极暴击：主动消息推送一天只有 4 条？
看到那一刻，我是真的有点绷不住。
一个月只能主动发消息四条？？？
当时脑子里全是问号：
- 这对吗？
- 这合适吗？
- 这机器人要了有什么用？
后面冷静下来再看，问题已经很明显了：
QQ 机器人并不适合我这种“监控事件 + 高频消息推送”的场景。
九、这波踩坑之后，我最大的感受
事后想了想，还是怪自己：
前期没有做好技术调研
这件事又一次让我深刻体会到了这句话：
磨刀不误砍柴工
前期调研做好了，技术选型、平台选型定清楚了，后面真的能少走很多弯路。
否则就是：
- 一边开发
- 一边踩坑
- 一边怀疑人生
十、重新调研各大平台机器人能力
吃了这次亏之后，我开始重新查资料。
主要还是借助大模型，去比较当前几个主流平台机器人的优劣势。
最后我自己整理了一个对比表：
| 平台 | 主动推送 | 群聊能力 | 单用户限制 | 总体限制 |
|---|---|---|---|---|
| ❌ 极严 | ❌ 很难 | ❌ 一天 4 条 | 🚨 最严格 | |
| 钉钉 | ✅ 可以 | ✅ 强 | ❌ 基本没有 | ⭐ 中等 |
| 飞书 | ✅ 可以 | ✅ 强 | ❌ 很宽松 | ⭐⭐ 最宽松 |
这个表虽然不一定覆盖全部细节，但至少足够给我做方向判断了。
十一、最终选择：飞书机器人
经过重新评估，最后我决定：
👉 选择飞书机器人作为替换方案
原因很简单：
- 支持主动推送
- 群聊能力强
- 消息限制相对宽松
- 更适合我的实时监控通知场景
对我这个项目来说，飞书明显更匹配：
监控事件触发 → 实时消息推送 → 支持群聊或多用户通知
十二、总结：技术选型真的比埋头开发更重要
这次踩坑让我最大的收获不是“怎么调某个接口”，而是：
选型失误，会让后面的所有努力都变得低效。
很多时候，问题不是你不会写代码，而是：
- 平台能力本身不支持
- 使用场景和平台定位不匹配
- 前期调研没有做透
所以这次我也算是被 QQ 机器人“教育”了一波。
不过也不算完全白折腾，至少把路趟明白了：
- QQ 机器人更适合非常轻量、低频、受限场景
- 真要做消息推送和实时通知，还是得看更开放的平台
十三、下期预告
接下来我准备正式折腾飞书机器人。
如果有兴趣的话，关注一波，下一期我会分享：
接入飞书机器人的过程趣事 + 实际踩坑记录
