确认部署环境与 Cloudflare 资源
确认账户、项目状态与资源绑定，避免把首次初始化、远程更新和本地开发混为一谈。
Saavo 的生产应用运行在 Cloudflare Workers 上，业务数据、文件、内容和后台任务分别使用不同资源。部署前先确认资源属于哪个账户，以及当前项目是否已经初始化，后面选择命令才不会出错。
Cloudflare 注册和 R2 开通步骤见准备 Cloudflare，这里主要检查项目与账户之间的关系。
一、确认正在操作的项目
在应用根目录检查 package.json 和 wrangler.jsonc，确认这是准备上线的业务项目。当前模板提供以下部署入口：
npm run deploy:init
npm run deploy:update
npm run domain:set -- https://app.example.com这里只列出入口供核对，具体执行顺序见首次部署与后续更新。不要把 Saavo 官网自身的构建脚本当成新建应用的部署命令，也不要因为旧教程提到 deploy:prod 就自行补一个同名脚本。
接着确认项目状态：
- 尚未初始化：Worker 和资源名称仍待确认，D1 的
database_id、KV 的id尚未由部署写入。 - 已经初始化：
wrangler.jsonc已记录账户和资源 ID，远程存在对应 Worker。 - 初始化中断：部分资源已经存在，但数据库迁移、KV 同步或健康检查尚未完成。
第三种状态需要先排查，不能简单地归为“还没部署过”。
二、核对 Cloudflare 账户
在终端执行：
npx wrangler whoami如果没有登录，再运行：
npx wrangler login同一个 Cloudflare 用户可能能访问多个账户。检查 whoami 输出的账户列表，确保准备部署的账户与 wrangler.jsonc 的 account_id 一致。
首次部署时，脚本可以让你选择账户并写入配置。后续更新会检查当前身份是否能访问已记录的账户，不会替你自动迁移到另一个账户。
如果使用部署机或 CI，部署凭据应放在执行环境的凭据配置中。它们是发布工具的权限，不属于应用运行时变量，不要写入 .env.production。
三、认识模板使用的资源
| 绑定或配置 | Cloudflare 资源 | 用途 |
|---|---|---|
Worker 的 name | Worker | 接收页面、API、队列和定时触发请求 |
DB | D1 | 用户、订单、权限、工单及业务数据 |
ANALYTICS_DB | D1 | 访问统计数据，与主业务库分开 |
MAIN_KV | KV Namespace | 文档、博客内容，以及项目使用的 KV 数据 |
MAIN_R2 | R2 Bucket | 上传文件等对象数据 |
ASYNC_POLICY_TASK_QUEUE | Queue | Reaction 后台业务任务 |
ASYNC_LOGGER_QUEUE | Queue | 异步日志写入 |
ANALYTICS_QUEUE | Queue | 访问统计事件 |
durable_objects.bindings | Durable Objects | 限流、计数、Nonce、Token Bucket 与 Timer |
triggers.crons | Cron Triggers | 按计划触发权益检查和数据维护 |
默认配置保留这些资源。即使首版暂时不使用某项界面功能，也不要只凭名称删除绑定，相关服务和后台入口可能仍依赖它。
DB 与 ANALYTICS_DB 必须指向不同的 D1。两者的表结构、维护任务和数据用途不同，不能为了减少配置而填同一个 ID。
四、首次部署由脚本创建资源
新的项目使用 npm run deploy:init。脚本先检查目标账户和资源名称，在确认后通过部署流程创建、绑定资源，并把生成的标识记录到项目配置中。
因此，通常不需要提前运行一组 wrangler d1 create、kv namespace create 和 queues create 命令。同名资源已经存在时，初始化检查会停止，不会默认接管它们。
模板初始的 D1、KV 配置没有可以跨账户复用的生产 ID。资源名称也会根据 Worker 名称调整，例如 Worker 名称为 my-app 时，主库名称会采用 my-app-db。
首次部署需要账户可以使用 R2。如果提示 R2 未开启，先按准备工作开通，再继续。权限检查失败时也要先核对账户和授权，不要通过改资源 ID 绕过错误。
Durable Objects 的类注册由 wrangler.jsonc 中的迁移配置随部署处理，无需手工创建对象实例。已经发布的迁移标签不要随意重命名或回退。
五、已有项目检查绑定即可
完成首次部署后，运行：
npm run doctor:remote它会检查生产环境文件、绑定配置、迁移文件以及当前 Cloudflare 身份。ERROR 会使检查失败，WARNING 则需要结合你启用的功能判断。例如首版不收款时，Stripe 未配置可以是预期状态。
doctor:remote 不是完整的线上业务探测，也不会逐个验证邮件、支付和所有资源里的数据。通过之后，仍要在 Cloudflare 中核对 Worker 的绑定，并按后文验证业务。
建议保留以下部署记录：
- 代码提交或发布版本。
- Cloudflare 账户和 Worker 名称。
- 主库、统计库、KV、R2 与 Queue 的对应关系。
- 正式域名、最近部署时间和使用的命令。
资源 ID 记录在项目配置中便于后续更新，密钥则单独管理。不要在部署记录里粘贴完整 Secret。
六、本地、生产和额外业务服务
本地 npm run dev 使用的数据库状态，与远程 D1 不是同一份数据。部署后看不到本地测试账户是正常现象，不要因此把本地测试库整体覆盖到生产。
.env.production 表示当前项目部署时使用的生产配置文件，不代表模板已经自动提供一套名为 production 的 Wrangler environment。当前默认流程使用项目的顶层资源配置，不需要额外加 --env production。
如果需要独立预览环境，应明确准备独立的 Worker、资源绑定、域名和提供商测试配置。仅复制环境文件，不会自动隔离数据库和队列。
实战教程中的 PDF Worker 属于业务新增依赖，通用部署脚本不会自动发布它。上线前先部署这类服务，再确认主站的 Service Binding、凭据和调用约定。具体产品依赖以自己的业务实现为准。
下一步：准备生产配置与密钥。