参照官方手册结构整理（数据截至 2026-10，配额/价格以官方最新页面为准）。技术术语保留英文原词。
1. 概述
Cloudflare Queues 是与 Workers 集成的消息队列：保证投递、把工作从请求中卸载、Worker 间传数据、缓冲/批处理数据。最重要的一点：没有出网（egress）带宽费。
一句话定位：保证投递、零出网费的消息队列。
Free 与 Paid 计划均可用。
2. 核心概念
- Producer / Consumer：生产者
send/sendBatch写入；消费者（Worker）处理消息。 - 批处理（Batching）：自动攒批，降低调用次数。
- 重试（Retries）：失败自动重试，可配退避策略。
- Dead Letter Queue（DLQ）：超过最大重试后将消息转入死信队列。
- Pull consumers：也可从 Cloudflare 之外的 HTTP 基础设施拉取。
3. 架构与工作原理
消息写入队列后，由消费者 Worker 异步处理；每条消息通常经历「写 → 读 → 删」三次操作。消费者调用上限 15 分钟挂钟时间。
4. 快速开始
wrangler.jsonc 配置生产者与消费者：
{
"queues": {
"producers": [{ "binding": "MY_QUEUE", "queue": "my-queue" }],
"consumers": [{ "queue": "my-queue", "max_batch_size": 10, "max_retries": 5 }]
}
}
生产消息：
await env.MY_QUEUE.send({ url: "https://example.com", ts: Date.now() });
消费（Worker 的 queue 处理函数）：
export default {
async queue(batch, env): Promise<void> {
for (const msg of batch.messages) {
await fetch(msg.body.url);
}
},
} satisfies ExportedHandler<Env>;
5. 配额与限制
| 限制项 | 上限（Free / Paid 相同，除非注明） |
|---|---|
| 每账户队列数 | 10,000 |
| 消息大小 | 128 KB（含约 100 字节内部元数据） |
| 最大重试次数 | 100 |
| 消费者最大批大小 | 100 条 |
sendBatch 单次 |
100 条（或总计 256 KB） |
| 批最大等待时间 | 60 秒 |
| 每队列吞吐 | 5,000 消息 / 秒 |
| 消息保留期 | Free 24 小时（不可配）/ Paid 默认 4 天，可配至 14 天 |
| 每队列积压大小 | 25 GB |
| 并发消费者调用 | 250（仅 push 模式） |
| 消费者挂钟时间 | 15 分钟 |
visibilityTimeout（pull） |
12 小时 |
delaySeconds |
24 小时 |
超吞吐时 send()/sendBatch() 抛 Too Many Requests。
6. 定价
| 计费项 | Workers Free | Workers Paid |
|---|---|---|
| 标准操作 | 10,000 操作 / 天 | 含 100 万 / 月，超出 $0.40 / 百万操作 |
| 消息保留 | 24 小时（不可配） | 4 天默认，可配至 14 天 |
- 计费单位「操作」：每 64 KB 的写/读/删各计 1 次；>64 KB 按多段计。每消息通常 3 次操作（写+读+删）。
- 无数据出网或吞吐费。
7. 最佳实践
- 用队列把耗时/不可靠的工作（发邮件、调用第三方、图像处理）从 HTTP 请求中卸载，降低用户等待与超时。
- 用 DLQ 接住反复失败的消息，便于排查而非无限重试。
- 合理设
max_batch_size与退避，匹配下游处理能力。
8. 适用场景与选型
- 异步任务、后台作业、Worker 间解耦、事件缓冲。
- 需要可靠投递、削峰填谷 → Queues；需要长流程、多步编排与暂停等待 → Workflows；需要协调共享状态 → Durable Objects。