D1 数据库发布：迁移、本地验证与 Time Travel 恢复
分清本地与远程 D1，按兼容 schema 发布迁移，并把 Time Travel 作为需人工确认的最后恢复手段。
编辑与核验：橙宝书编辑团队 ·
远程 D1 与本地 D1 是两套状态
wrangler dev 默认使用本地数据。带 --remote 的命令会接触远程数据库，无法用关闭终端撤销。本教程展示发布门禁，但不会替你执行远程迁移或恢复。
发布原则
迁移可追踪
d1_migrations 记录已应用版本。应用向前兼容
恢复需确认
一条安全发布线
用稳定数据库名创建 migration
pnpm exec wrangler d1 migrations create APP_DB add_document_status生产操作优先使用稳定的 D1 database name，不要依赖可能被不同环境重用的 binding 名。检查新 SQL 文件；避免把不可回退的数据清理和应用代码切换塞进同一 migration。
先应用到本地数据库
pnpm exec wrangler d1 migrations list APP_DB --local
pnpm exec wrangler d1 migrations apply APP_DB --local运行 schema、读写、空库升级和已有数据升级测试。确认 migration 可在第二次检查时保持无待执行项，并验证失败时不会留下应用无法识别的半成品状态。
建立向前兼容发布顺序
先部署读取旧列并可选读取新列的代码，再远程应用“只新增”的 schema，随后启用新写入与回填。删除列、重命名或大规模数据重写放到单独变更窗口。AI 生成 SQL 必须经人工审查索引、默认值、NULL 与租户条件。
远程执行前做人工门禁
pnpm exec wrangler d1 migrations list APP_DB --remote核对账号、数据库名、环境、待执行文件、备份/恢复负责人、维护窗口与回滚版本。只有批准后才运行远程 migrations apply；教程和 AI 不应自动跨过这一步。
发布后验证业务而不是只看 exit 0
验证 schema 版本、关键读写、租户隔离、索引查询、错误率和慢查询。先灰度应用代码；出现数据库错误时先停止新版本流量和写入扩散，再决定前向修复还是恢复。
Time Travel 不是普通撤销
Time Travel 在远程 D1 上自动可用且不额外收费，但恢复会覆盖数据库当前状态。保留期还受计划限制：当前限制页列出 Free 为 7 天、Paid 为 30 天；执行前应以账号与最新官方限制为准。
pnpm exec wrangler d1 time-travel info APP_DB \
--timestamp '2026-08-27T02:30:00Z'此命令读取远程 D1 信息。先把本地时间转换成明确的 UTC/RFC3339，并让第二人核对事件时间、数据库和 bookmark。
恢复会丢弃恢复点之后的状态
Time Travel 适合数据库级灾难恢复，不适合撤销一名用户的一次误操作。单条或单租户错误优先用审计记录和补偿写入修复，避免把所有用户一起回退。
发布与恢复清单
- 本地空库与已有数据升级测试都通过。
- 应用代码在 migration 前后 schema 都能工作。
- 远程数据库名、账号、环境和 migration 列表由两人核对。
- 写入冻结、恢复点、恢复后数据处理和流量回退都有负责人。
- 生产验证覆盖读、写、租户隔离、错误率和关键查询，不只看 CLI 成功。
数据库选型背景见 D1、Supabase 与 Neon 对比；应用发布总门禁见生产上线检查。
官方来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。