Workers

适用场景

场景	处理方式	搭配能力
文档站、官网、博客	静态优先，Worker 只做少量动态接口。	静态资产层 + 明确的动态入口
评论、表单、第三方回调、小接口	Worker 接口。	Workers + D1 / KV / Turnstile
鉴权、代理、接口网关	Worker 网关。	Workers + WAF / 限流
文件上传下载	Worker 只做权限和签名。	Workers + R2
房间、会话、协作状态	Worker 只做入口。	Workers + Durable Objects
邮件、导入、重试、后处理	放到后台异步处理。	Workers + Queues / Workflows
服务端渲染、重搜索、AI 前处理	单独估 CPU。	CPU 指标 + Workers Paid
爬取、总结、通知、导出串联	入队后处理。	Workers 入队 + Queues / Workflows / Containers

升级条件

动态请求稳定接近 Free 限制时，再考虑升级。典型信号是公开接口、评论、搜索代理或服务端渲染已经有人持续使用。

CPU 经常达到限制也要单独看，尤其是解析大请求、服务端渲染、加密、AI 前处理和批量数据处理。生产问题需要更长日志留存、请求追踪日志或外部日志平台时，Workers Paid 也会更合适。

D1、KV、Queues、Durable Objects 成为主要依赖后，这些产品的免费层也会一起决定是否升级到 Workers Paid。更多定时任务、Worker 数量、外部调用或更大包体，属于工程配额升级。

架构分工

静态页面和前端资源交给静态资产层 / Pages，免费不限量，也更适合缓存。Worker 负责路由、鉴权和轻接口。评论、订单、业务表放 D1；公开配置、缓存、索引放 KV；图片、附件、导出包放 R2。房间、会话、限流器这类单实体强一致状态放 Durable Objects。慢任务、通知、重试放 Queues / Workflows，不绑在一次请求生命周期里。

长任务处理

ctx.waitUntil() 适合返回响应后的短尾任务，例如日志、缓存刷新、轻通知。不要在请求里串太多外部 API：本地可能正常，上线后外部 API 一慢，整条请求就会被拖住。

用户提交后应尽快返回：校验输入、写任务记录、入队，然后返回任务状态。邮件、爬取、AI 总结、文件解析、通知发送放到队列或工作流里慢慢处理。真正重计算交给 Containers 或外部计算服务。