ThinkPHP数据库迁移工具使用技巧_升级后的版本控制实操-ThinkPHP-PHP中文网

thinkphp迁移问题核心在于version比对机制与环境适配：需检查migration表和文件前缀一致性，up()中避免直接create()，用dropifexists()+create()或原生sql判断表存在；时间戳冲突应统一生成命令；tp8已移除内置迁移，须改用phinx等标准工具。

thinkphp数据库迁移工具使用技巧_升级后的版本控制实操

ThinkPHP 的迁移工具默认只执行「未标记为已完成」的迁移文件，它靠 migration 表里的 version 字段和文件名前缀比对。如果手动改过文件名、删过记录、或之前执行失败但残留了记录，就会跳过或卡住。

实操建议：

先查数据库里 migration 表，确认当前最新 version 值，再核对 database/migrations/ 下文件名前缀是否严格递增（如 20230101000000_create_users_table.php）
用 php think migrate:status 看每条迁移的执行状态，Pending 才是待执行，Missing 表示文件已删但记录还在
别直接删 migration 表数据——用 php think migrate:rollback --step=1 回退再重跑更安全
如果只是想强制重跑某次迁移，删掉对应记录 + 对应文件，再重新 php think migrate:refresh

这是最典型的「没判断环境就硬建表」导致的。迁移的 up() 方法不是部署脚本，它必须能反复执行不报错，尤其在 CI/CD 或多环境同步时。

实操建议：

不要在 up() 里直接 Schema::create()，改用 Schema::dropIfExists() + Schema::create() 组合，或者更稳妥地用 Schema::hasTable() 判断后再建

注意：ThinkPHP 6.1+ 的 Schema 类不支持 hasTable()，得手写原生 SQL 查 information_schema.tables，例如：

Db::query("SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = ? AND table_name = ?", [config('database.database'), 'users'])

如果只是加字段，优先用 Schema::table()，避免整表重建；字段类型变更（如 string → text）需显式调用 change()，否则会被忽略

时间戳重复不是 ThinkPHP 的 bug，而是多人本地生成迁移时没同步时间。迁移顺序只认文件名前缀，同时间戳下字母序决定先后（000000 在 000001 前），但一旦有人提交了 000000，另一个人再生成同时间戳的文件，Git 合并就容易错乱。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

实操建议：

统一约定生成命令加秒级精度：用 php think make:migration add_status_to_orders --time=$(date +%Y%m%d%H%M%S)（Linux/macOS），Windows 可用 PowerShell 替代
CI 流水线里加检查：用 ls database/migrations/*.php | head -n 2 提取前两个文件名，正则提取时间戳，报警重复
真遇到冲突，别改已有文件时间戳——新建一个 20240501000002_fix_order_migration_order.php，在 up() 里补上缺失操作，再用 php think migrate:refresh --seed 全量重跑（仅限开发环境）

TP8 彻底移除了内置迁移模块，think-migration 第三方包也不再维护。这不是配置问题，是生态断层——官方把迁移交给了社区方案，比如 Laravel-style 的 robmorgan/phinx 或自研轻量工具。

实操建议：

立刻停用所有 TP 自带迁移命令，改用 composer require phinx/phpmig 配合 phinx.yml 配置，入口命令变成 vendor/bin/phinx migrate
旧迁移文件不能直接复用：Phinx 要求类名匹配文件名（CreateUsersTable），且构造函数必须接收 $console 参数；TP 的 up()/down() 方法签名也不同，需重写
如果不想换工具，可降级锁死 TP7.3，但要注意 PHP 8.2+ 兼容性已在 TP7.3 中部分失效，长期风险明确

迁移的本质是版本化的 SQL 变更，不是框架功能。越晚切到标准工具，后期补救成本越高，尤其是跨大版本升级时，时间戳、类加载、连接池这些细节全得手动对齐。