惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
B
Blog
M
MIT News - Artificial intelligence
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
P
Proofpoint News Feed
C
Check Point Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
J
Java Code Geeks
博客园 - 叶小钗
S
SegmentFault 最新的问题
Last Week in AI
Last Week in AI
T
The Blog of Author Tim Ferriss
Microsoft Security Blog
Microsoft Security Blog
小众软件
小众软件
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 【当耐特】
腾讯CDC
博客园 - Franky
博客园 - 聂微东
V
Visual Studio Blog
GbyAI
GbyAI
Martin Fowler
Martin Fowler
罗磊的独立博客
Y
Y Combinator Blog

Aimee's Blog

秒杀怎么防机器人:验证码之外的几道防线 防薅羊毛怎么做:号码风控、设备指纹与分层策略 接口限流怎么选:固定窗口、滑动窗口、令牌桶 批量打包下载怎么设计:流式 ZIP 与异步任务 图片处理怎么做:异步处理与 CDN 实时参数 大文件上传怎么设计:分片、断点续传、秒传 报表可重跑的设计:快照、水位线与幂等 UV 统计为什么有误差:精确计数与近似计数怎么选 大数据量导出怎么做:流式写入与异步任务 排行榜的两类需求,难度差了一个数量级 实时热榜怎么设计:Redis ZSet 与热度分值 互关状态怎么保持同步:双向关系的维护与缓存失效 并发点赞的计数设计:原子操作与最终对账 删了父评论,子评论怎么处理——先想清楚用户看到的是什么 定时消息任务触发了两次 消息量大,写扩散还是读扩散——接到这个需求先问清楚规模 同一条消息推送了三次 活动结束了,用户还在收短信 接到注销需求,先问两个问题 微服务与服务拆分:何时拆、怎么拆 异步与事件驱动架构:把协作从「打电话」改成「发消息」 高可用设计:怎么让系统尽量不宕机 可扩展性设计:怎么让系统加机器就能扛更多 缓存架构:多级缓存怎么搭 高并发三板斧:限流、熔断、降级 架构设计到底在设计什么 —— 从单体到微服务的演进 服务成本账:一个服务一个月烧多少钱 可观测性:线上出问题怎么查 API 设计:好接口长什么样 消息队列:为什么要 MQ,以及丢失、重复、顺序怎么破
内容审核怎么选:先审后发,还是先发后审
Aimee · 2026-08-09 · via Aimee's Blog

内容审核怎么选:先审后发,还是先发后审

UGC 平台的内容审核有两条路:先审后发 vs 先发后审

在讨论技术方案之前,先要问产品和法务:这个平台能承受多少风险窗口?


两种策略的核心权衡

先审后发

用户发布内容 → 进入审核队列 → 审核通过后可见

  • 违规内容不会被任何人看到
  • 用户体验差:发完看不到,以为发失败了;审核有延迟,内容时效性受影响
  • 适合:强监管内容(医疗建议、金融信息、儿童内容)、对违规零容忍的平台

先发后审

用户发布内容 → 立刻可见 → 异步送审 → 审核未通过则下架

  • 用户体验好,发完即见
  • 违规内容有短暂可见窗口(通常几分钟到几小时,取决于审核速度)
  • 适合:低风险社区类内容、对时效性要求高的平台

混合策略:按风险分级

不是所有内容都一样危险,更合理的做法是按内容风险分级处理:

内容提交
    ↓
机审(秒级)
    ├─ 确定违规 → 拒绝,不发布
    ├─ 确定安全(低风险)→ 直接发布,不再人审
    └─ 不确定(含图片、敏感关键词命中)→ 先发后审(人工队列)
                                              └─ 人审通过 → 保持可见
                                              └─ 人审拒绝 → 下架 + 通知用户

代码层面,内容状态机:

public enum ContentStatus {
    PENDING,   // 待审核(先审后发时,此状态内容不可见)
    PUBLISHED, // 已发布可见
    REJECTED,  // 审核拒绝,不可见
    REMOVED    // 先发后审被下架
}

查询时按状态过滤:WHERE status = 'PUBLISHED'


先发后审的实现细节

内容创建后直接写入 DB,状态设为 PUBLISHED,同时发消息给审核队列:

@Transactional
public void publishContent(Content content) {
    content.setStatus(ContentStatus.PUBLISHED);
    content.setAuditStatus(AuditStatus.PENDING);  // 审核状态独立
    contentDao.insert(content);
    
    auditMqProducer.send(new AuditTask(content.getId()));
}

审核完成回调:

public void onAuditResult(long contentId, boolean passed) {
    if (!passed) {
        contentDao.updateStatus(contentId, ContentStatus.REMOVED);
        notifyUser(contentId, "您的内容因违反社区规范已被移除");
    }
}

审核状态(audit_status)和发布状态(status)分开存:审核状态是内部运营字段,发布状态是面向用户的展示字段,两者独立维护,互不耦合。


机审接入

自己写规则引擎处理不了图片、语音、视频。接入第三方内容安全 API(如阿里云内容安全、腾讯天御)是标准做法:

  • 文本:关键词过滤 + 语义分析
  • 图片:涉黄/涉暴/广告识别
  • 视频:抽帧送图片审核

机审 API 是外部调用,要做超时和降级:超时时进人工审核队列(不能因为机审挂了就让所有内容绕过审核直接发)。


用户告知

无论哪种策略,让用户看到自己内容的审核状态,是减少客诉的最直接方式:

  • 先审后发:发布后显示"内容审核中,审核通过后将对外展示"
  • 先发后审被下架:明确告知原因,提供申诉入口
  • 长时间未审核:超过 N 小时未出结果,发通知给用户并升级处理优先级