改远端库结构前先确认库身份与回滚

更新于 2026-07-15

**`db:push` 这类直接改远端数据库持久结构的操作，执行前必须先确认「这是测试库、共享库还是生产库」以及有无 migration 与回滚能力 —— 它改的不是本地代码，是所有人共用的持久结构。**

为什么不能默默执行

  • 会真实执行 DDL（新增字段、唯一索引），可能短暂锁表，影响所有连接该库的用户。
  • 若项目没有正式 migration 和自动回滚流程，一旦误改生产/共享数据无法回退。
  • 无法确认库的用途时，默认按「可能是生产」对待。

授权要精确到变更清单

授权只覆盖已检查过的变更（例如 4 个字段 + 1 个唯一索引）；执行前重新检查 diff，出现额外变更（删表/删字段/改历史数据）就立即停止。

判据：操作是否触及「远端持久结构」。改本地文件、跑本地测试不需要这种授权；db:push 到远端需要。

共享库里可能有别的分支的表

实测：给共享 Neon 库补一个字段时，发现库里有当前分支 schema 不认识、但已有 4 行数据的 video_details 表（别的分支在用）。此时用 --accept-data-loss 强行对齐 schema，就会为了修一个字段误删别人的数据。

正确处理：

  • 用只增加字段的幂等迁移（ALTER TABLE ... ADD COLUMN IF NOT EXISTS）补字段，不动其他表。
  • 启动防线改成「执行增量迁移 / 校验」，而不是每次拿整个分支 schema 强推共享库。

一条更普适的判据：共享资源的操作要按「最小变更集」授权，而不是按「让当前分支跑起来」授权。 前者的失败模式是多改一点，后者的失败模式是删掉别人的数据。

相关