社区发帖接口接入自家CMS后，积分到账延迟五分钟，用户以为我跑路了

上周把社区的发帖、回帖和积分接口接进自己写的CMS，本来想着就是个HTTP调用的事儿，结果上线第一天就被用户在群里@，说发帖没给积分，是不是系统吞了。我后台一查，积分记录明明有，再一看时间戳，好家伙，延迟了四分多钟。

问题出在异步队列上。社区那边为了防刷，积分发放走的是消息队列，我CMS这边调用发帖接口成功就返回了，但积分到账是另外一个异步进程在跑。我之前没仔细看文档，以为`code: 200`就是万事大吉，还在前端直接弹了个"发帖成功，积分+5"的toast。用户刷新页面一看余额没变，截图就来质问，我百口莫辩。

后来改成轮询查账。发帖成功后前端每隔3秒调一次积分流水接口，最多查10次，到账了再提示。但这样又踩了社区API频率限制的坑，测试环境没感觉，上线后并发一高，部分请求被`429`了。最后妥协方案是：发帖接口返回里带一个`expected_credit`字段，告诉前端预计到账积分，余额没更新前先显示"待到账"，等用户下次刷新或者触发其他积分操作时再对账。

回帖接口更折腾。社区要求回帖内容先过审核再公开，但积分是即时预发放的，如果审核不通过还要扣回。我一开始没对接审核回调，结果有人刷垃圾回帖薅了几十积分，审核删除后积分没回收。补回调的时候发现，社区扣回积分走的是另一套`revoke`接口，参数结构跟发放完全不一样，签名方式还多了个时间戳偏移量校验，文档藏在"高级接入"页面的二级菜单里，找了我半小时。

最无语的是积分流水对账。社区接口返回的流水ID是字符串，我数据库里存的是自增INT，对接时顺手`intval()`了一下，结果有个流水ID带了字母前缀，直接变0，对账永远差一条。后来全改成VARCHAR(64)，又在每晚跑个定时任务，把本地未确认的流水ID批量去社区校验状态，这才算把账平住。

现在我的对接代码里专门封了个`CommunityCreditTrait`，把发帖、回帖、签到三种场景的积分预检、发放查询、异常回滚全包在一起。下次再接类似平台，至少不会再让用户觉得我要卷积分跑路了。