Queues 适合把用户请求后面的慢动作拆出去：发邮件、通知、第三方回调，R2 上传后生成缩略图或解析文件，调用有频率限制的外部服务，爬虫、截图、Browser Run 任务，都可以入队处理。消息里尽量只放对象标识和必要元数据。
批量写日志、事件、索引也可以入队后再批量写。用户需要立刻拿到结果时，保留同步请求或做任务状态查询。多步骤、长时间、需要状态机的流程看 Workflows。强一致房间、计数器、锁看 Durable Objects。
成本按消息生命周期估算，不按任务条数估算。Free 阶段需要及时消费，避免消息堆太久。大文件、正文和二进制内容放 R2，消息只放对象标识和必要元数据。大消息会按分片计操作，小消息也要考虑写、读、删。重试和失败队列会让操作数量变大，生产任务需要可观测。
- 不要把 10,000 次操作/天当成 10,000 条任务，要按消息数量和生命周期一起估算。
- Free backlog 不要超过 24 小时，要监控 backlog 和 oldest message。
- 不要假设消息只会执行一次，每条任务带
jobId，写入时做幂等。 - 生产任务默认配失败队列和告警。
- 消息里不要塞大内容，文件、正文、大对象放 R2 或 D1。
- 主动拉取时避免频繁空转，普通 Worker 任务优先使用队列主动推送。
生产端要薄，只做校验请求、生成任务 ID、写入队列，然后返回。消费端要幂等，因为重复执行是正常情况。消息要小，队列传任务引用，不传文件和大正文。外部服务、邮件、数据库写入都要按承载能力控制并发。重试次数、失败队列、告警和人工处理路径要提前定。多步骤审批、等待、人机交互优先评估 Workflows。