Cloudflare 完整应用的基础分层

把静态资源、请求逻辑、结构化数据、对象存储和后台任务放到正确边界。

ARCHITECTURE中级30 分钟产出：一张应用职责表

完整应用不等于把所有 Cloudflare 产品都接一遍。它指一条用户流程从页面进入，经过服务端校验和业务逻辑，正确读写数据，并能处理失败、观测和回滚。产品选择应该从职责出发，而不是从产品目录出发。

五层职责

层	负责什么	常见选择	不应该承担什么
静态交付	HTML、CSS、JS 和不可变资源	Workers Static Assets	用户鉴权和 Secret
请求逻辑	路由、认证、校验、响应组合	Worker	长时间阻塞任务
结构化状态	用户、租户、文章、任务状态	D1	原始大文件
对象数据	图片、PDF、导出文件	R2	高频关系查询
后台工作	转换、索引、重试、批处理	Queues 或 Workflows	阻塞用户请求直到全部完成

KV 不是默认数据库

KV 适合读多写少、允许最终一致的配置和缓存型数据。需要关系查询、事务语义或强租户过滤时，先评估 D1；需要有状态协调时再评估 Durable Objects。

同步请求边界

完整应用的同步请求路径 — 先把同步请求限制在清晰主链内；D1、R2 与 Queue 都是 Worker 根据需要访问的后续资源。查看原图

01
入口
静态页面或 API 请求。
02
解析
DNS 与代理决定请求入口。
03
保护
TLS、WAF 与缓存先于业务逻辑。
04
执行
Worker 验证身份、输入和租户。
05
访问资源
只读取当前流程需要的数据。

一条可维护的请求

先识别路由类型

静态资源直接交付；公开读取路由允许缓存；需要身份的 API 先认证；管理操作额外检查角色。不要让一个万能 handler 同时猜测全部行为。

再建立业务上下文

认证结果生成 userId 与 tenantId。后续 D1 查询必须绑定租户条件，R2 key 必须使用受控前缀。客户端自报的租户 ID 不能直接成为授权依据。

把长任务移出请求

图片批处理、PDF 解析、索引和外部 API 重试先写入任务状态，再发送 Queue 消息或启动 Workflow。用户请求返回任务 ID，通过状态接口查看进度。

最后定义响应与观测

成功、校验失败、未授权、资源不存在和下游失败使用稳定错误代码。日志记录 request ID、版本和内部错误类别，不记录 Secret、完整 Token 或不必要的个人数据。

四类项目如何取舍

SaaS

D1 保存账号、租户与套餐；R2 只在需要附件时加入；客户代码执行是另一个高级问题。

CMS

D1 保存内容状态和索引字段；R2 保存媒体；发布时建立明确的公开版本。

图片工具

R2 保存原图或结果；Images 负责支持的转换；Queue 处理非即时批量工作。

PDF 工具

Browser Run 可从 HTML/URL 生成 PDF；上传后解析、索引等任务走异步流程。

完成检查点

为你的项目写出五行职责表。每个资源只承担一类主职责，并说明资源不可用时用户会看到什么。若设计要求一次请求等待所有转换、索引和通知完成，先拆出异步任务再继续。

Next.js 项目先完成目标运行时兼容性门禁；数据库上线使用 D1 迁移与恢复手册。下一步：选择一个完整项目。

框架层与平台层分开学习

如果应用使用 TanStack Start、Router 或 Query，先用 TanStack 生态地图确定路由、SSR、Server Functions 与服务端状态分别由谁负责；再回到本页，把静态交付、请求逻辑、数据和后台任务映射到 Cloudflare。更多运行时与数据专题见相关技术文档网络。