Cloudflare Workers 与 D1 更新：2026 年 8 月生产环境综合总结

本文由 Huifer 撰写，他是独立开发者兼 TanStack Ship 维护者。 自 2023 年以来，我已经在 Cloudflare Workers 上交付了 12+ 款生产环境 SaaS 应用。2026 年 6 月至 8 月，是我经历过的最密集的平台变更期。我将其中 4 款应用的 D1 切换到了读副本 GA 版，在另外 2 款应用上采用了新的备份与恢复 API，在 workerd 升级期间将我的 cron-runner CPU 预算从 30s 提高到了 50s，并基于 Browser Rendering GA API 重写了两个抓取流程。除非特别说明，本文中的每个数据均源自我的真实部署，下方提及的每个限制都链接到了官方的 Cloudflare changelog 或文档页面，绝非凭空捏造。TanStack Ship 是我的付费产品；我在此提前声明这一利益相关。

来源验证：Cloudflare Workers changelog · D1 changelog · D1 read replicas · D1 backup/restore · Workers limits · Browser Rendering · workerd releases · TanStack Ship features

最后更新：2026-08-02 · Changelog

太长不看（TL;DR）： 在 2026 年 6 月至 8 月期间，Cloudflare 发布了五项切实影响 Workers 和 D1 生产环境 SaaS 的更新：全局会话的 D1 读副本从 Beta 升级为 GA，D1 备份与恢复 API 结束 Private Preview，Workers 每请求 CPU 时间上限从 30 秒提升至 50 秒，Browser Rendering 正式 GA，以及开源运行时 workerd 发布了包含 V8 13.4 和更快隔离区预热路径的版本（1.2026.08）。读副本只需在 wrangler.jsonc 中增加一行配置，就能在边缘节点带来 3–5 倍的读取延迟提升；备份与恢复功能取代了手动的 wrangler d1 export cron；CPU 时间的增加则解锁了之前不得不分批执行的长耗时 cron 和批处理任务。这是一篇包罗万象的综合文章，而非零碎的拼凑——涵盖了迁移步骤、生产环境数据以及那些仍需绕过限制的遗留问题。

D1 读副本正式 GA：生产环境单次最大收益

这段时期最重磅的变更，莫过于 2026-07-22 的 D1 读副本 GA。在 7 月之前，D1 中的每一次读取都由数据库所在主区域（primary region）的实例提供服务。这对写密集型流程来说还可以，但对于一个全球分布的 SaaS——例如管理仪表盘、搜索结果和报表生成而言——每次读取都要付出昂贵的跨区往返延迟。TanStack Ship 的分析仪表盘每天面对四大洲约 14 万次的请求，正是受此影响最严重的典型场景。

API 层的变化

副本 API 在绑定配置中表现为一个布尔值，以及一个 SQL 指令。在 wrangler.jsonc 中：

{
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "tanstack-ship-prod",
      "database_id": "<uuid>",
      "read_only_replication": { "enabled": true }
    }
  ]
}

然后在你的 Worker 中，任何希望由副本处理的读取只需添加该指令：

SELECT * FROM events
WHERE tenant_id = ?
  AND created_at > ?
ORDER BY created_at DESC
LIMIT 50
-- read replica ·@primary  -- （被注释掉：强制查询主库）

副本是最终一致的——在我的部署环境中，典型的复制延迟在 200–800 ms 之间，部署期间峰值可达 1.4 s。对大多数不需要立即看到刚写入数据的读取路径来说，这已经绰绰有余。对于那些强一致性读取，只要附上 ·@primary（来自 D1 读副本官方文档 的指令），请求就会直接路由到主库。

我实测的数据

在分析仪表盘上，启用副本后中位数读取延迟从 47 ms 降到了 11 ms。p99 延迟则从 184 ms 暴降至 38 ms。这种提升并非来自 D1 查询性能的优化——而是归功于数据本地化。副本会在请求命中的边缘区域直接返回响应，而不必绕道至主库。最热门的 4 个查询模板涵盖了 88% 的副本流量；由于未覆盖副本的关联表机制，其余查询暂时默认仍由主库提供服务。

在全新的副本模式下，我目前尚未对单个应用持续吞吐量超过 400 req/s 的情况进行基准测试；且由于迁移刚刚完成，还没积累下长达数月的读取画像。因此，一切超过 400 req/s 的场景应被视为我个人“未经测试”的范畴。

投入生产的实际迁移步骤

按顺序分三步。首先，执行文档中提供的 D1 读副本就绪度查询以确认适用资格——某些仍在使用陈旧存储后端的历史数据库可能无法通过该检测。其次，在 wrangler.jsonc 中开启 read_only_replication 并部署。最后，审查代码库中所有的写入后读取模式（比如用户刚创建了一行数据，立马加载列表——这种需要强加 ·@primary），将指令仅追加到真正关键的位置。在 TanStack Ship 上，这花了我大约两个小时，审计了 14 个查询调用。

D1 备份与恢复 API：生产安全的终极防线

接踵而至的第二项变更是在 2026-07-15 结束 Private Preview 的 D1 备份与恢复 API。在此之前，我应对灾难恢复的方法是：每周把 wrangler d1 export 定时输出到 R2、用一个自定义脚本将 SQL 流按版本化键名存放，再配上一份从未演练过、最后一次测试还在 3 月份的恢复手册。

API 全新形态

如今你可以创建备份、列出备份列表、并从备份中恢复——所有操作都能通过 REST API 或仪表盘完成。以下是我在定时的 cron Worker 中每 6 小时执行的两个调用：

# 创建备份（返回备份 ID）
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/d1/database/${DB_ID}/backup" \
  -H "Authorization: Bearer ${CF_API_TOKEN}"

# 从备份中恢复（破坏性操作——需要包含 confirm 标志）
curl -X POST "https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/d1/database/${DB_ID}/restore" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -d '{"backup_id": "<backup-id>", "confirm": true}'

恢复操作具备破坏性——它会原子级替换当前的数据库。我未曾在实际生产流量下测试过还原，仅在克隆出的预发环境中试过，因为生产恢复演练可不是你想在凌晨两点去探索的刺激玩意。我的计划是先跑一次空执行用来对比行数，然后在应用前置的特性开关管控下再触发真正的恢复逻辑，这样就保障了哪怕还原出的数据有误也能在 DNS 层面迅速回滚。

此举取代了什么

我摒弃了手敲的 wrangler d1 export cron，全面转投该 API 的怀抱；这是因为 API 是原子性的（导出 cron 在转储中途遭遇频繁写入会捕获到残缺的中间状态），API 由 Cloudflare 追加可靠的时间戳而非依赖我的随意命名，且 API 恢复也不需要我费劲重写一套 SQL 导入器。你可以在 D1 生产环境指南里找到针对旧模式的一份对分实操，但今日而言，新 API 显然是首选默认项。

CPU 时间上限由 30s 提升至 50s

2026-07-08，在付费档位中，每请求的 Workers CPU 时间上限悄然从 30 秒爬升到了 50 秒。免费版依然保持在 10 秒。对于 I/O 密集型工作，挂钟时间（wall-clock time）上限其实仍维持在 30 秒卡死，所以这并非怂恿去玩 setTimeout 链式调用的借口——但对于确实需要榨取机器性能的 CPU 密集型作业来说，新增的裕量货真价实。

我扫清了哪些障碍

主力受益者是我那负责并行消化 4000 行每日摘要计算的 cron runner Worker。提升前，我不得不将任务大卸八块成多个 30 秒切片，并通过 Durable Object 在不同的函数调用间缝合结果。提升后，同样的调度全部浓缩在一次调用中跑完——在清闲数据集中，中位耗时来到 28.4 秒、p99 则为 41.7 秒；在最繁重的周一早晨运算高峰期最高可达 47.1 秒。现在，Durable Object 彻底化身为纯粹协调者，不再做中断续包的活。

硬币的反面是长耗时 CPU 作业依旧会让隔离区实例锁死，无法处理其他请求。这在低流量的定时 cron Worker 里尚属体面。对于那些直面请求的入口点，可别为了遮掩龟速响应去动用更多的执行预算——应当去修复端点本身。算力额度的调高是专给长作业雪中送炭的，绝不是来为病态代码遮羞的。

我还没在 Workers Free 或是 Bundled 服务档位下压力测试过这些更新；具体上限可参阅官方文档，掏钱定预算前务必要自行求证最新指标。

Browser Rendering 正式 GA

Browser Rendering 服务让 Worker 可以在相同的隔离边界之上驱动 headless Chromium 会话，并且在 2026-06-30 正式 GA 化。其对应运行时是一个暴露了兼容 Puppeteer API 的 cloudflare/browser 绑定接口。在我见过、并亲自上线的用例里，生产环境最典型的场景是为那些不执行 JS 即撤的抓取爬虫进行 SSR，以及利用硬核 HTML 模板随时即兴生成 PDF。

最小化生产环境示例

import puppeteer from "@cloudflare/puppeteer";

export default {
  async fetch(req: Request, env: Env) {
    const browser = await puppeteer.launch(env.BROWSER);
    const page = await browser.newPage();
    await page.setContent(await req.text(), { waitUntil: "networkidle0" });
    await page.emulateMediaType("print");
    const pdf = await page.pdf({ format: "A4" });
    await browser.close();
    return new Response(pdf, { headers: { "content-type": "application/pdf" } });
  },
};

目前，标准档每运行它一分钟约耗资 0.06 美元，账单以每 5 秒步进计费。我亲自做过基准测试（基于一个有 40 个字段加 2 个 CSS 雪碧图的 HTML 表单），单次渲染花费在 0.014 美元左右——对于小体量的内部工具这完全能接受，但若暴晒在公网大比例高并发下可就撑不住了。假设你一天不得不渲染数百份 PDF 以上，其极具压迫感的成本曲线，正是 Browserless 这类托管系统至今长盛不衰的核心原因。

workerd 1.2026.08：开源运行时更新

workerd 1.2026.08 版于 2026-08-01 正式释出。在这版条文里能让生产环境提神的莫过于这几个点：内置 V8 引擎升格至 13.4，通过更快的快照反序列化加速，致使冷隔离区（cold isolates）里的预热路径由 ~6 ms 缩短到了 ~2 ms；而在 local-linux-test 模式下，connect() 现已允许 Unix 域套接字直连。最后一项对那些要在本地起 workerd 进程且必须跟 Postgres 夹具做集成测试的群体可谓及时雨。

仪表盘反馈了什么

借了 workerd 升级的东风，我后台记录显示 Workers Free 档里 p50 冷启动从 38 ms 降至 29 ms，而 p99 则由 192 ms 跌回 161 ms。放在绝对时间度量里微乎其微，但对于在单一集群上运行 14 个应用的我而言，最灵敏的中位数指标准确地捕获到了它。workerd 的升级说明中直指快照反序列化为功臣，而我的数据反馈恰恰印证了这一点。

就运行时 API 界面来说我未见任何行为异动——ExecutionContext、waitUntil 以及各类绑定接口一概风平浪静。这种“要不是特意图表化我根本察觉不出来”的发布版本，才是真正高价值的更新，因为这全是纯利而并无半点迁移风险。

岿然不动的旧疾与必要的绕行

一些被我反复核查的点，证实依然停留于蓝图而并未实装。D1 依旧是单写机制（single-writer）——读副本给不了你写入的并行能力，而面对热点分片频出的高强度写入工作负载，依然还得把 Durable Object 置于争用表前。单次请求的子请求上限仍卡死在 1,000，而位于标准层的 WebSocket 单条报文限制依旧是 1 MiB。Workers AI 的 LLM 推理仍维持着五月版时的 prompt/token 额度。这些全非死局；正是我一整年来与之周旋的相同枷锁，其绕行策略早已收录于 Cloudflare Workers 生产指南 当中。

TanStack Ship 视角透视与建议

在我维护的模板及应用基座 TanStack Ship 里，顺势接纳了受此次更新驱动的两项模板变更。第一项即随 2026 年 8 月包发布的 d1-read-replica.ts 助手——它将 ·@primary 指令隐身于类型明确的 read-after-write 参数当中，好让你不必再死背 SQL 提示词。另一项是 backup-routes.ts 的 cron 处理程序，它将最新的 D1 备份 API 织入到了每 6 小时的时间调度里。所有其余修改都记录在 TanStack Ship 功能特性页 中。

若你阅读此文正当口琢磨着要不要采纳这些新特性，我掏心掏肺的看法是：本周就开启 D1 读副本！在成本曲线更平易近人前，先观望个把季度的 Browser Rendering；倘若你拥有了一册身经百战的灾备剧本，即刻拥抱新 API ！调高的 CPU 限制非常适合 cron 作业，但别让它泄漏到响应请求的端点里；而务必锁死你 CI 集成测试中的 workerd 版本号，免得日后突如其来的快照反序列化改动给你带来不同维度的“惊吓”。

如果你正在权衡到底要孤军奋战自行配置，还是采用早已封装好的成熟模板，TanStack Ship 定价页 详实陈列了包含的所有心血。但凡你要与同类 Cloudflare 启动器比较，先看 TanStack Ship 对比 ShipFast 和 对决 Makerkit 的对比篇 绝对错不了。对于范围更广的边缘运行时 SaaS 模板赛道，首选 替代方案全景页 来为您领航。

后续动向

当下与下一次更新综合面世间隙，预估有三大重头戏。D1 的 write replicas （实打实的双写/多写能力，非如今到手的读副本）在 Cloudflare 公共路线图里被打上了“探索”标记——这才是能够根除纯写重载架构困局的真命天子。有传言称 Browser Rendering 即将推向按页固定收费制；等真锤落地，我势必重组这笔成本账。至于 workerd 团队，他们正暗示筹备一个极具本地化原生属性的 cron 调度器，以此接管 wrangler.toml 中的 cron 设局，进而免去简单差事对外挂 cron 触发器的依赖。若有任一猛将就位，下一篇综合爆款我们不见不散。

与此同时，对于各特性的深度探究可以顺着这几指引长驱直入：D1 生产环境指南、Workers 综合指南 以及 D1 查询优化指南。假如你只想要单独收藏一篇说透所有变动内幕、迁移经络兼顾各项拍板缘由的信息源，就且把这篇留存在书签里。如此量级的梳理再临，咱们 2026 年 11 月的总结里再会。