migration.sql 文件标记为安全，会话显示其含 4 条语句，随后在命令行运行安全与否（safe-not-safe）检查。工具使用查询解析库（libpgquery）17 的 WebAssembly 版本解析，共 301 字符。逐行结果：第1行添加常量列默认值安全，现代 PostgreSQL（Postgres）版本中字面量默认值仅改元数据不重写行；同行并发创建索引 userscreatedatidx 安全不阻塞写入；第4行无高风险模式匹配安全；第8行验证约束安全，用于更安全外键或检查约束上线的第二步。

运行 npx safe-not-safe check 检查 migration.sql，通过 libpg_query 17 (wasm) 解析出 4 条语句，共 301 字符。

[Ln 1] 安全：常量列默认值（add-column-constant-default）。字面默认值在现代 Postgres 中仅变更元数据，不重写已有行。

[Ln 1] 安全：并发索引构建（create-index-concurrently）。userscreatedat_idx 构建时不阻塞普通写入。

[Ln 4] 安全：未匹配高风险模式（no-high-risk-pattern）。该语句无发布范围阻塞、重写或滚动风险。

[Ln 8] 安全：约束验证（validate-constraint）。VALIDATE CONSTRAINT 用于更安全外键或检查约束滚动发布的第二步。

安全——未发现阻塞模式。被检查语句避开了发布规则集中的常见锁、重写与滚动陷阱。

社区肯定浏览器端静态迁移安全检查的轻量便利，但不少人质疑其规则覆盖不全，认为安全性高度依赖数据库实际状态与规模，动态内省或更完整工具更可靠。

认为轻量静态检查对捕捉明显风险有用

• 作者基于支持多产品团队时开发者只关心“安全与否”的诉求，将规则引擎移植为浏览器内无遥测工具；有用户赞赏在提交 CI 前本地捕捉低级风险的价值，部分团队也认为在手工破坏性迁移场景下此类工具能辅助审查。（认可度：较多人）
• > 在到达 CI 前于本地捕捉明显的迁移风险非常实用（@rohansx）

认为静态规则引擎不完整且有漏判

• 多位指出安全性取决于原列类型、外键关联、表大小与活动等非 DDL 因素，纯规则易漏判如添加无默认非空列等常见陷阱；质疑当边缘案例不断叠加时，不如直接用大模型或实时内省。（认可度：较多人）
• > 改列类型到底是无操作还是排他锁重写，取决于原列类型，静态规则看不到（@orf）

认为应转向动态内省或完整零停机工具

• 有用户构建针对实时 schema 内省锁行为的系统，或开发自动双 schema 同步的零停机迁移工具，认为让数据库自己报告动作并结合生产指标才准确；另有用户列举各语言生态中限制破坏性操作的现有库作为参考。（认可度：较多人）
• > 迁移 linter 给不了足够安心，工具应保证不锁库且支持新旧 schema 同时部署（@fabianlindfors）

有价值的补充

• 锁队列本身比 DDL 更可怕：即使 ADD COLUMN 瞬间完成，若排在长查询后等待，后续所有查询会堆积，设锁超时加重试比聪明工具更救急（@kettlecrisp99）
• 部分团队用拒绝自动生成破坏性迁移的 schema 管理工具，使手工迁移成例外从而更受审查，此时静态检查辅助价值显现（@agubelu）
• 工具名称梗来自《硅谷》剧集的“热狗或不是热狗”应用，主打安全与否的二元判断（@vira28）
• 可供参考的开源项目：Ruby 的 strong_migrations、Go 的 onwardpg、pglockanalyze 锁分析、reshape 零停机工具、schematic 等（合并自多位评论者）