Navicat 不支持直接读取 Git 分支中的 SQL 文件，必须先通过 Git 切换到目标分支并确保脚本存在于本地工作区，再在 Navicat 中手动打开执行；执行前需校验编码、替换占位符、确认依赖顺序，并在隔离测试库中验证结果。
Navicat 本身不支持直接读取 Git 分支里的 SQL 文件
这是最常被误解的一点：navicat 是数据库客户端工具，不是版本控制系统客户端。它没有内置 git 集成，不能像 vs code 那样自动拉取 feature/login 分支下的 schema_v2.sql 并执行。你看到的“在 navicat 里打开 git 文件”实际只是手动打开了本地磁盘上某个时刻 checkout 出来的文件。
验证脚本前必须先 checkout 到目标分支并确保文件存在
Git 分支是逻辑概念，脚本内容只在你本地工作区落地后才可被 Navicat 访问。常见错误是直接双击 Navicat 的“打开 SQL 文件”按钮，却忘了自己还在 main 分支，打开的其实是旧版本脚本。
- 用终端或 Git GUI 切换到目标分支：
git checkout develop - 确认脚本路径正确且已更新：
git status查看migration/202405_add_user_status.sql是否在暂存区或工作区 - 如果脚本在子模块或远程路径（如
origin/release/v2.1），必须先git fetch && git checkout -b release-v2.1 origin/release/v2.1，否则 Navicat 打开的是空文件或报错File not found
在 Navicat 中安全执行脚本的关键操作
直接点击“运行”按钮执行未审核的分支脚本，极易导致生产库结构错乱。Navicat 不校验 SQL 语义，也不区分 DDL/DML 上下文。
- 务必勾选
SQL 编辑器 → 设置 → 运行前提示确认，避免误触执行 - 对含
DROP TABLE或ALTER TABLE ... DROP COLUMN的脚本，先用EXPLAIN（MySQL）或pg_prepared_statement（PostgreSQL）模拟执行——但 Navicat 不支持，需切到命令行验证 - 执行前手动替换占位符：比如脚本里写的是
CREATE TABLE ${env}_users，得先替换成CREATE TABLE dev_users，否则 Navicat 会报语法错误 - 注意字符编码：Git 默认 UTF-8，若 Navicat 连接配置为
gbk，中文注释或字段名会导致Incorrect string value
真正可靠的验证流程是“Git → 本地文件 → Navicat 连接指定库 → 手动比对”
所谓“验证”，本质是确认该分支脚本在目标库上能成功执行且结果符合预期。Navicat 只承担最后一环的执行和查询职责，中间链路必须人工闭环。
- 建一个临时测试库（如
myapp_dev_feature_x），用 Navicat 新建连接指向它 - 把分支脚本拖进 Navicat SQL 编辑器，检查是否有未提交的本地修改干扰（比如多了一行
DELETE FROM users;） - 执行后立即查
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'myapp_dev_feature_x';，对比主干库的表数量 - 关键字段变更必须人工核对：
DESCRIBE users;看status字段是否新增、类型是否为TINYINT(1)而非VARCHAR(10)
分支脚本往往依赖前置迁移序号或版本标记，Navicat 不解析这些元信息——漏掉 001_init.sql 就直接跑 002_add_index.sql，大概率报 Table 'users' doesn't exist。
