发帖回帖积分联动改造实录：断点、缓存与事务的三角博弈

社区里关于积分接口对接的讨论不少，但大多停留在“怎么调API”的层面。这次想聊点更实在的——当发帖、回帖、积分这三个模块真正串起来跑生产时，那些文档里不会写的坑。如果你正打算给社区做类似的功能联动，这篇笔记或许能帮你少走几段弯路。

先说背景。我们的社区原本是发帖回帖各自独立，积分系统是后来加的。需求很常规：发新帖得2分，回帖得1分，删帖扣回相应积分。听起来简单，但真正对接时发现，问题往往出在“你觉得理所应当”的地方。

第一个坑是断点位置。一开始我们把积分变更逻辑直接写进发帖成功的回调里，结果发现高并发下同一用户连续发帖时，积分偶尔会少算。排查到最后，问题出在事务边界——发帖主流程和积分更新不在同一个数据库事务里。发帖成功但积分更新失败时，没有回滚机制，用户帖子发出去了，积分却没到账。后来我们把积分操作挪进主流程事务内，用数据库行锁保证同一用户的积分变更串行化，问题才解决。

第二个坑是缓存一致性。积分值我们做了Redis缓存，每次变更后主动更新缓存。但删帖场景下，缓存更新时机和数据库回滚顺序一旦颠倒，就会导致缓存里残留旧积分。比如删帖事务提交前先清了缓存，事务回滚后缓存是空的，用户下次请求就会触发缓存穿透。现在的做法是：先更新数据库，事务提交成功后，再异步刷新缓存，并且给缓存键加版本号，避免并发写覆盖。

第三个坑是回帖的匿名场景。我们社区允许匿名回帖，但积分规则要求只有登录用户回帖才加分。最初判断“是否登录”用的是前端传的UID，结果被人抓包伪造UID刷分。后来改为服务端从会话里取登录态，匿名回帖的UID置空，积分操作前先校验会话有效性。这个改动不大，但堵住了最明显的漏洞。

还有个容易被忽略的细节：编辑帖子算不算积分变更？我们的规则是编辑不重新计分，但编辑后如果内容被管理员判定违规删除，积分是否追回？这里需要定义清楚“删除”的语义——是软删除还是硬删除，软删除时积分要不要立即扣回，还是等定期任务统一处理。我们最终选择了软删除时立即扣回，但留了七天申诉期，申诉成功可以补回积分。

最后说说联调时的一个小技巧。积分变更涉及发帖、回帖、删帖、申诉多个入口，靠人工测试很难覆盖全。我们写了一个模拟脚本，随机生成用户行为序列，然后比对数据库里的积分流水和预期值，跑了几轮下来确实发现几个边界条件下的逻辑漏洞。

以上都是些笨办法，但胜在可靠。如果你也在做类似的模块联动，建议先画一张完整的时序图，把每个入口的请求路径、事务边界、缓存策略标清楚，再动手写代码。出问题时，这张图会是你最快的定位工具。