一条 ALTER TABLE 语句在我的部署过程中导致一个 Worker 服务宕机。没有维护窗口，没有优雅的回退机制——只有当实时流量冲击损坏的数据库模式时，铺天盖地的 500 错误。
D1 的底层是 SQLite，而 SQLite 的 ALTER TABLE 是任何关系型数据库中限制最多的之一。你只能添加列。基本上仅此而已。不能删除列，不能更改类型，不能重命名——除非完全重建表。Cloudflare 的文档提到了这一点，但他们并未充分说明在生产环境中它会多么迅速地给你带来麻烦。那个让我惊醒的具体错误如下：
错误：D1_ERROR：无法添加没有默认值的非空列 [ 代码：1 ]
我试图向一个正在使用的表中添加 campaign_id TEXT NOT NULL（活动 ID 文本类型，非空）。SQLite 立即拒绝——因为一旦该列出现，现有行就会违反约束。迁移 halted，Worker 的代码期望该列存在，而每个访问该表的请求都失败了。事后看来，修复方法显而易见：在任何新列上始终将 NOT NULL（非空）与 DEFAULT（默认）值配对使用，或者先接受可空，稍后再加强约束。不太明显的是 何时 默认值方法不够好——具体来说，当空字符串或零在你的数据模型中语义不正确时。这就是“扩展-收缩”模式发挥作用的地方：创建具有你真正想要模式的新表，复制数据，删除旧表，然后重命名。这需要四条 SQL 语句，并且是在 D1 中进行类型更改或真正删除列的唯一安全路径。
自 2025 年初以来，我已经在 3 个生产环境的 D1 数据库上运行了这个流程。真正能拯救你的纪律是枯燥的：首先应用于本地环境（wrangler d1 migrations apply --local），在每次迁移后使用 PRAGMA table_info(...) 进行验证，并将迁移保存在编号的平面文件中，在你和 SQL 之间不使用任何花哨的工具。五条 wrangler 命令涵盖了我遇到的所有场景。
我在 dailymanuallab.com 上写了完整的细分说明——包括完整的“扩展-收缩” SQL、我为每个步骤运行的确切 wrangler 命令，以及在接触生产环境之前如何验证列状态。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
