把社区积分接口接进自己CMS后，我才懂什么叫"异步到账"的玄学

上周把社区的发帖、回帖、积分变动三个接口正式对接进自研后台，本以为照着文档拼URL传参数就能收工，结果在"积分到账延迟"这个问题上卡了整整两天。

先说背景：我们社区用的那套系统，积分不是实时落库的。用户发完帖，前端立刻显示"积分+5"，但数据库里可能还在队列里排队。我一开始没细看文档，直接在发帖回调里同步调了积分查询接口，想给用户弹个"当前余额"的提示。结果十次有三次查回来还是老数字，用户截图骂我"骗人"，我后台日志一看，接口返回200，数据确实没变——这时候积分消息还没消费到。

后来改成异步方案：发帖成功先记一条流水到本地中间表，再开个定时任务去对账。这里又踩了个坑，社区接口的`order_id`是我传的，但回查时它给我的`trade_no`是另一套规则，两边对不上。翻了半天社区开发群的聊天记录，才发现人家文档里 buried 在附录第三页有一行小字："回查请使用平台方 trade_no，原 order_id 仅作透传"。

回帖接口更折腾。社区为了防止刷帖，做了同内容相似度检测，但我CMS里的"快捷回复"功能预设了几条模板，用户连续点两次，第二次直接被社区吞了，返回了个`CONTENT_DUPLICATE`的错误码。我前端没处理这个码，用户那边看着按钮转完圈啥反应没有，疯狂连点，最后同一层楼回了八条。现在我的处理是：收到这个码，前端伪造成"发送成功"但其实是本地缓存展示，同时把真实状态挂到轮询里等最终结果。

积分接口最让我头疼的是"反向操作"。用户删帖要扣回积分，社区支持负向流水，但要求必须带上原正向流水的`trade_no`。我一开始没存这个字段，删帖时根本扣不了分。现在发帖成功的回调里，我把`trade_no`、`order_id`、`时间戳`三件套全写进本地关联表，才敢开放删帖功能。

对接完这三个接口，我在CMS里多加了两个表：`community_sync_log`和`points_reconcile_queue`。一个记每次调用的原始报文，一个放需要对账的脏数据。以前觉得"接口对接"就是拼参数，现在才明白，真正的活全在异常分支和状态对齐上。

有同样接社区接口的兄弟吗？你们积分到账延迟一般怎么处理，是轮询还是等回调？我现在的5秒轮询感觉还是有点蠢。