ThinkPHP 官方不内置数据库迁移功能，需使用第三方扩展 topthink/think-migration；安装执行 composer require topthink/think-migration（TP6/TP7 推荐 4.x），再运行 php think migrate:install 初始化迁移表，迁移文件须置于 database/migrate/ 目录且类名严格遵循时间戳格式，up() 和 down() 方法需保证可逆，生产环境迁移前须验证回滚、字段兼容性及大表索引安全。
ThinkPHP 本身不内置数据库迁移（Migration）功能，官方未提供类似 Laravel 的 php artisan migrate 机制；要实现版本化数据库变更管理，必须借助第三方扩展或自行封装 —— 最常用、维护较活跃的是 topthink/think-migration。
如何安装并初始化 think-migration 扩展
该扩展是 ThinkPHP 官方生态中事实上的迁移标准方案，适配 TP6 和 TP7（注意：TP5.x 需用旧版 topthink/think-migration:2.x，且不兼容 PHP 8.1+）。
- 运行
composer require topthink/think-migration（TP6/TP7 推荐 4.x 版本） - 执行
php think migrate:install创建migration表（用于记录已执行的迁移文件） - 迁移文件默认生成在
database/migrate/目录下，需确保该目录可写 - 若项目使用多数据库连接，需在命令后加
--connection=xxx指定连接名
创建和编写迁移文件的关键细节
迁移文件本质是 PHP 类，继承自 think\migration\Migrate，必须实现 up() 和 down() 方法。框架通过类名中的时间戳前缀（如 20230101000000_create_user_table.php）控制执行顺序。
- 类名必须严格匹配
YYYYMMDDHHIISS_describe格式，否则php think migrate无法识别 -
up()中用$this->table('name')->create()或->addColumn()等链式方法定义结构，避免直接写 SQL（除非用$this->execute()） -
down()必须可逆：删除表用$this->dropTable('name')，删字段不能只写dropColumn而不检查字段是否存在（否则回滚失败） - 不要在迁移中调用模型（
UserModel::create()），因为迁移阶段模型可能尚未加载或配置未就绪
执行迁移时常见报错与绕过方式
实际运行 php think migrate 或 php think migrate:rollback 时，多数失败源于环境或设计偏差，而非语法错误。
立即学习“PHP免费学习笔记（深入）”；
-
[PDOException] SQLSTATE[HY000]: General error: 1005 Can't create table：通常是外键约束失败，检查关联表是否已存在，或在up()中调整建表顺序 -
Class 'xxx' not found：迁移类被自动加载失败，确认composer dump-autoload已执行，或类文件未放在database/migrate/下 -
SQLSTATE[42S01]: Base table or view already exists：说明迁移逻辑未判断表是否存在，应在up()开头加if (!$this->hasTable('xxx')) { ... } - 执行
rollback报错“no migration to rollback”：是因为migration表里没有记录，或当前迁移未成功写入该表（比如up()中途抛异常）
生产环境迁移必须手动验证的三件事
迁移不是开发玩具，上线前必须人工核对，自动化脚本无法覆盖所有边界。
- 检查
down()是否真能还原：本地执行一次migrate再rollback，确认表/字段/索引完全消失 - 确认字段类型兼容性：例如把
VARCHAR(255)改成TEXT是安全的，但反过来可能截断数据；TP 的changeColumn()在 MySQL 中实际是ALTER TABLE ... MODIFY，有隐式转换风险 - 大表加索引必须加
ALGORITHM=INPLACE（MySQL 5.6+）或改用 pt-online-schema-change，直接跑迁移会导致锁表 —— 这点think-migration不处理，得自己在up()里用$this->execute("ALTER TABLE xxx ADD INDEX ... ALGORITHM=INPLACE")
迁移文件一旦推送到团队共享仓库，就不该修改内容，只能追加新迁移；重命名、编辑已执行的迁移文件，会导致 migration 表记录与文件不一致，后续所有人执行都会出错。
