内容发布在社区系统里是最典型的“看起来简单，实际最容易出问题”的模块。尤其是类似仿小红书这种结构，图文+话题+审核+推荐多条链路叠加，如果一开始设计成“大一统接口”，后面基本改不动。
在宠友社区这套系统里，发布链路做过一轮重构，目标不是功能丰富，而是把链路压缩到最短、最稳定，同时给后续扩展留空间。
一、发布接口只保留核心路径
很多实现习惯在一个接口里完成所有逻辑：
- 写内容
- 写图片
- 绑定话题
- 更新统计
- 写推荐数据
- 触发审核
这种写法的问题不是功能多，而是事务过重。
在仿小红书源码的设计里，发布接口只保留两个动作：
- 内容入库
- 图片关联
核心实现如下：
@Transactional public Long publish(NoteDTO dto) { // 写主内容 Note note = new Note(); note.setUserId(dto.getUserId()); note.setContent(dto.getContent()); note.setStatus(0); // 审核中 noteMapper.insert(note); // 写图片关系 if (dto.getImages() != null && !dto.getImages().isEmpty()) { List<NoteImage> list = dto.getImages().stream().map(url -> { NoteImage img = new NoteImage(); img.setNoteId(note.getId()); img.setUrl(url); return img; }).collect(Collectors.toList()); noteImageMapper.batchInsert(list); } return note.getId(); }这个结构的重点在于：
- 事务只包含数据库写入
- 不依赖外部服务
- 不做复杂计算
发布成功的定义被收敛为：数据成功落库
二、审核逻辑必须前置“状态”，而不是回滚
很多系统会在发布后再做审核，不通过再删除内容。这种设计在社交系统里问题很明显：
- 内容可能被短暂曝光
- 删除操作复杂
- 审核失败需要清理多表数据
在宠友社区的实现中，采用的是“状态驱动”：
status:
0 = 审核中
1 = 已发布
2 = 已拒绝
发布接口只负责写入“审核中”，后续由审核服务修改状态。
这样带来的变化：
- 发布接口不依赖审核服务
- 无需回滚数据
- 内容不会提前曝光
三、话题绑定必须拆出主事务
在仿小红书这类社区中，话题是典型热点数据，如果在发布时同步处理，会直接影响接口性能。
常见问题：
- 热门话题产生锁竞争
- 多表操作导致事务变慢
- 发布接口耗时不稳定
在宠友社区中，话题处理被拆到异步链路：
public void asyncBindTopic(Long noteId, List<Long> topicIds) { if (topicIds == null || topicIds.isEmpty()) return; for (Long topicId : topicIds) { topicRelationMapper.insert(noteId, topicId); } }触发方式通常是：
- 线程池异步执行
- 或通过消息队列解耦
重点不是用什么工具，而是：不阻塞发布接口
四、计数类字段不要在发布时更新
一个很常见的误区：发布时顺便更新统计数据，比如：
- 用户发帖数
- 话题内容数
这种写法在低并发没问题，但一旦用户量上来，会变成写入瓶颈。
在仿小红书源码中，这类数据处理方式是：
- 不在发布时更新
- 通过定时任务统计
- 或走缓存累加
这样做的好处：
- 减少数据库写入压力
- 避免热点行锁
- 提高整体吞吐能力
五、图片链路必须完全解耦
发布接口里最容易被忽略的一个问题是图片处理。
错误做法：
- 发布时上传图片
- 发布时压缩
- 发布时鉴黄
这会导致接口耗时不可控，甚至超时。
在宠友社区中，图片流程是独立的：
1）前端先上传图片
2）服务返回URL
3）发布接口只接收URL
发布接口只做“引用关系”，不参与处理。
六、为什么必须拆事务
在SpringBoot体系里，用@Transactional很方便，但不能滥用。
事务越大，问题越多：
- 锁范围扩大
- 回滚成本增加
- 并发能力下降
在仿小红书这种内容社区场景里，更合理的策略是：
👉 主流程强一致
👉 扩展流程最终一致
也就是：
- 发布成功 = 数据写入成功
- 其它行为允许延迟执行
七、接口性能的关键控制点
发布接口的用户感知非常明显，超过1秒基本会影响体验。
在宠友社区的实际运行中，这条链路优化重点在：
- SQL数量控制在2~3条
- 避免任何远程调用
- 事务时间尽量缩短
最终发布接口稳定在：
👉 100ms ~ 300ms
其它逻辑全部后置处理。
八、链路拆分后的扩展空间
发布链路一旦拆干净，很多功能可以无侵入接入，例如：
- 推荐权重计算
- 内容标签提取
- 风控策略
- 用户行为分析
这些都可以挂在异步流程中，不影响主链路稳定性。
这也是仿小红书类系统一个很典型的特点：功能不断叠加，但核心链路保持简单
九、失败补偿机制必须提前设计
异步链路不可避免会失败，比如：
- 话题绑定失败
- 审核服务异常
如果没有补偿机制，数据会出现不完整。
常见做法：
- 定时扫描未处理数据
- 重新执行逻辑
这种方式在宠友社区中已经是基础能力，用来保证最终一致性。
十、多端统一架构带来的约束
在仿小红书系统里，一套后端需要同时服务：
- 安卓APP
- iOS
- 小程序
- H5
这意味着：
- 发布接口必须稳定
- 响应必须统一
- 数据结构不能频繁变
所以发布链路设计一开始就必须足够“克制”，否则后期改动成本会非常高。
⭐市面上已有成熟的源码—宠友社区https://www.chongyou.info/1/product/xhs.html
