把社区积分系统接进自建站：我踩了三个"看起来通了的"接口陷阱

上周终于把论坛的积分体系对接到自己写的活动模块里，本以为照着文档调几个接口就能收工，结果在"发帖奖励积分"这个环节卡了两天。不是接口不通，是通得太像通了——返回值 200，积分变动记录也有，但用户总积分死活对不上账。

先说第一个坑：异步回掉里的时序幻觉。我这边用户发完帖，先写本地数据库，再调社区的发帖接口，等社区返回 post_id 后再追一条"发帖奖励积分"的调用。本地测试一切正常，上线后高并发下积分开始乱飞。后来加日志才发现，社区那边发帖接口返回 200 并不代表帖子已经过审完成，只是"接收成功"。我追过去的积分请求比审核回调还早到，直接被拒了，但我的本地记录已经标记"奖励已发放"。结果是部分用户发了帖、没拿到分、我还查不出哪条漏了。

解决办法很土：把积分奖励从"发帖后立即发放"改成"监听社区 webhooks，等审核通过事件再触发"。为此我在本地补了张事件缓冲表，社区回调什么我先记下来，按事件类型和时间戳顺序消费。虽然多了层壳，但至少不会再有"我以为他好了其实他没好"的误会。

第二个坑更隐蔽：积分接口的幂等性只防重复提交，不防重复业务。社区文档写了"同一 biz_id 多次调用仅生效一次"，我以为是万能保险，结果回帖奖励和发帖奖励我偷懒用了同一个 biz_id 前缀，只是后缀分别是 post_id 和 reply_id。好死不死有个帖子 id 和某个回帖 id 数值一样，用户先回帖拿了分，后来发帖时系统判定"这个 biz_id 用过了"，直接跳过。用户跑来骂街，我查了半天才发现是 id 撞车。

现在我的 biz_id 强制带业务类型码，格式改成 `site_act_post_{id}` 和 `site_act_reply_{id}`，宁可长一点，不再赌唯一性。

第三个坑是回帖嵌套时的积分溢出。社区支持楼中楼，我最初只接了"回复主题"和"回复楼层"两种事件，没处理"回复楼中楼"的嵌套场景。结果有人在三层嵌套里疯狂灌水，每一层都触发了我的积分规则，一天刷了八百多分。社区的事件 payload 里其实带了 `parent_id` 的层级关系，但我当初嫌麻烦没解析，现在补了个递归深度限制，超过两层嵌套的回复只记一次基础互动分，不再叠加。

对接第三方系统的接口，最怕的就是"看起来通了"。200 状态码、正常返回体、甚至积分变动记录都有，也不代表业务真的闭环了。我现在每接一个 webhook 或回调接口，强制自己做三件事：补事件缓冲表防时序乱、biz_id 带业务类型防撞车、把对方文档里所有事件类型列出来逐个过一遍防漏场景。

你们接社区积分或者发帖接口的时候，有没有遇到过"返回正常但业务不对"的诡异情况？我这边现在看到 200 都条件反射先怀疑人生了。