大家都以为按到达顺序处理最公平，但在实时内容审核里，这反而是效率杀手。一场直播活动中，几分钟内可能涌进几百条上传。严格先来后到的队列，听着很合理——直到某一个嘉宾开始上传大视频，全场摄影师拍的照片就只能排队干等，预览久久出不来，审核员面对空转的清闲窗口。

但无限制的并行处理又会走向另一个极端：存储、扫描和预览生成全部挤占同一资源，整个管线一起崩溃。于是设计核心变成在“公平”与“吞吐”之间重新画线。不是简单地取消排队，而是把单一队列拆成多个独立阶段——验证、恶意软件扫描、元数据提取、预览生成、人工审核——每段都有不同的资源账单和失败策略。一个文件带上稳定的媒体ID和阶段版本，即使重试也不会生产重复的衍生品或审核工单。

准入控制是防止涌入恶化的第一道闸。不要一接到请求就立刻分配计算资源，而是先让控制器限流：按事件和按上传者会话分别限制活跃工作数；超出的项直接放进持久化的等待状态，浏览器被告知“已接受”但系统并没有假忙。界面要清晰区分“已接受但排队”和“真正在处理”，不让进度条给用户一个停摆的错觉。

调度逻辑最核心的一步是按成本分班。照片、短音频、视频分到不同成本槽里，给图像 6 个并发槽、音频 2 个、视频 2 个，用小项目保证流动、大项目保证容量。权重依据实际处理时长动态调整，不看文件数量。为了防止一个上传者霸占所有资源，采用按会话轮转或给每个会话设并发上限；有官方来源需要优先就写进审计记录，但绝不用隐藏的设备指纹去制造“公平身份”，一个活动内的随机会话标识足够做速率控制了。

背压机制是让系统真正可扩展的关键。下游的扫描服务饱和时，上游的派生工并不继续扔百万条待处理消息，而是主动降速；同时暴露队列深度和最旧项年龄，两个指标联合缩放，避免单看队列长度自欺欺人。给重试设最大次数，确定性失败直接推进死信路径，只带媒体ID、阶段、安全错误码和重试记录，绝不在日志里泄露任何签名URL或隐私标题。

审核员的视图设计同样不能忽视。光标下的工单不能乱跳；给每一项稳定位置，或划出清晰的“新项目”分界线。显示媒体类型、活动内的本地上下文、处理状态和自动化标记的原因。操作必须幂等——两个审核员同时通过同一项，结果收敛为一个状态，产生一条审计记录而不是两份通知。工作节点崩溃也不怕：长视频处理中不断续租，每个阶段都可安全重试，预览写完但未确认就崩溃，只需重启重放，绝不丢数据。