对接发帖回帖与积分接口时最容易踩的五个坑

上周帮朋友排查一个论坛插件问题，功能很简单：用户发帖加5分，回帖加1分，积分到账后自动升级用户组。结果上线三天，运营反馈"有人发帖积分没加，有人回帖加了两次"。我跟着查了两天，把发帖、回帖、积分三个模块的接口对接环节翻了个遍，整理出五个反复出现的坑，都是真实踩过的，不是理论推演。

第一个坑：把积分发放写在发帖成功回调里，但回调可能被触发两次。

朋友的项目里，发帖逻辑走的是"插入帖子表 → 触发钩子 → 钩子里调积分接口"。问题出在钩子触发时机上：帖子插入成功后，如果后续还有附件处理、标签关联等操作，某些框架会在这些子步骤里再次触发同一个钩子。结果就是一条帖子插进去，积分接口被调了两遍。排查方法很简单，在积分接口入口打一行日志，记录调用来源和帖子ID，跑一次发帖看日志打了几次。修复方式有两种：要么在积分接口里做幂等，用"帖子ID+用户ID+操作类型"做唯一键；要么把积分发放从钩子里挪出来，改成发帖主流程走完、事务提交之后再调。推荐后者，逻辑更清晰。

第二个坑：回帖积分和帖子作者积分混在一起算。

很多论坛的回帖逻辑是：回帖人加分，同时帖子作者也加分（鼓励被回复）。朋友的项目里这两个积分走的是同一个接口，参数只传了"用户ID"和"分值"，没传"积分来源"。结果运营想查"某个用户这周回帖得了多少分"时，发现数据里分不清哪些是回帖人得分、哪些是作者被回复得分。后来加了一个 source 字段，取值比如 reply_author、reply_replier、post_create，查询和统计才做得下去。这个字段一开始不加，后面补数据迁移会很痛苦。

第三个坑：积分接口同步调用，拖慢发帖响应。

积分接口本身不慢，但如果它里面还做了用户组升级判断、升级后发通知、通知走邮件队列，整个链路就长了。朋友的项目发帖接口平均响应从 200ms 涨到 1.2s，就是因为在发帖事务里同步调了积分接口，积分接口又同步调了用户组升级，升级逻辑里还查了三次数据库。改法是把积分发放改成异步：发帖成功后往消息队列扔一条积分任务，后台 worker 消费。如果项目规模小不想上队列，至少把用户组升级判断从积分接口里拆出来，单独跑定时任务或延迟任务。

第四个坑：积分扣减和帖子删除没有对齐。

发帖加分、删帖扣分，听起来对称，实际很容易漏。朋友的项目里，用户删自己的帖子会扣分，但版主删帖、后台批量删帖、用户被封禁导致帖子被隐藏，这几个路径都没走扣分逻辑。结果有人靠"发帖加分→被版主删帖不扣分"刷积分。后来统一收口：所有删除帖子的入口，不管是用户操作还是管理操作，都调同一个 deletePost 方法，这个方法里统一处理积分回滚。关键是别在控制器里各写各的删除逻辑。

第五个坑：积分接口的返回值没校验，失败了也当成功。

积分接口返回格式是 {code:0, msg:"ok", data:{...}}，但朋友的项目里调用方只看了 HTTP 状态码 200 就认为成功，没解析 body 里的 code。有一次积分服务数据库连接池满了，接口返回 200 但 body 里 code 是 500，发帖流程照样往下走，用户看到"发帖成功"但积分没到。修复就是在调用积分接口的地方加一层统一封装，解析 body，code 非 0 时抛异常或记错误日志，发帖主流程根据这个决定是否回滚或提示用户。

这五个坑里，前两个是逻辑设计问题，中间两个是性能和数据一致性问题，最后一个是调用规范问题。如果正在做类似对接，建议先从幂等和 source 字段入手，这两个改起来成本最低、收益最直接。