# 发帖、回帖、积分接口对接：用“最小可运行闭环”验证联调顺序

很多开发者在对接社区模块时，习惯先把发帖接口调通，再调回帖，最后接积分。结果往往是：发帖成功但积分没加，回帖成功但积分加给了错误用户，或者积分加了但帖子列表不刷新。问题不在于接口本身，而在于联调顺序错了。

社区模块的三个核心动作——发帖、回帖、积分变动——本质上是一条事件链。正确的做法不是按接口文档逐个测试，而是先建立一个“最小可运行闭环”：用一条测试帖走完“发帖→回帖→积分入账→积分明细可查”的完整路径。这个闭环跑通之后，再扩展到多用户、多版块、多积分规则。

具体操作上，建议把联调拆成四个阶段。第一阶段，只验证发帖接口能否返回帖子 ID，并且这个 ID 能被后续接口正确引用。很多积分接口的失败，根源是发帖返回的 ID 格式与积分接口期望的不一致，比如一个返回整数、一个要求字符串。第二阶段，用上一步拿到的帖子 ID 调回帖接口，确认回帖记录能关联到正确的帖子，并且回帖返回的用户标识与发帖用户标识是同一套体系。第三阶段，在回帖成功后触发积分接口，重点观察积分接口收到的是“谁在什么时间因为什么行为加了多少分”。这里最容易出问题的是行为类型字段：发帖和回帖往往对应不同的积分规则，如果行为类型传错，积分会加但加错档位。第四阶段，调积分明细接口，确认刚才的积分变动能被查询到，并且明细里的关联 ID 能反向定位到具体的帖子和回帖。

一个常见的误区是跳过第四阶段。很多开发者认为积分加上了就结束了，但积分明细查不到意味着对账链路断裂。用户后续如果反馈“积分没到账”，你只能看到总分变了，却说不清是哪一笔。把明细查询纳入最小闭环，等于给自己留了一条回溯路径。

另一个值得注意的细节是并发场景。最小闭环跑通后，建议用两个测试账号同时发帖，观察积分接口是否会出现重复入账或漏账。如果积分接口没有做幂等，同一帖子 ID 重复提交可能会加两次分。这个问题在单账号测试时不会暴露，但上线后一定会遇到。

最后，把闭环验证脚本化。每次改动发帖、回帖或积分相关代码后，跑一遍脚本，确认四个阶段全部通过。这比手工点页面可靠得多，也比等到用户投诉再排查省事得多。