ThinkPHP迁移失败主因是未安装think-migration扩展或部署时用了--no-dev参数；需检查composer.json、app/command.php配置，确认数据库连接与migration表状态，并注意SQL兼容性及数据安全操作。
迁移命令在服务器上执行失败：提示 Command "migrate" is not defined
ThinkPHP 自带的迁移功能不是默认启用的，本地能跑不代表服务器环境就支持。核心原因是 think-orm 的迁移命令依赖 think-migration 扩展包，而它不会随框架自动安装，也**不会被 composer install --no-dev 装上**——因为默认被列为 require-dev。
实操建议：
- 检查
composer.json中require-dev是否包含"topthink/think-migration": "^3.0"；若没有，运行composer require --dev topthink/think-migration - 上线部署时，**不能加
--no-dev参数**，否则迁移命令直接消失；生产环境需接受该扩展存在（它只提供命令，不参与运行时） - 确认
app/command.php是否注册了迁移命令类，标准写法是：return [think\migration\Command::class];
本地 migrate:run 成功，但服务器表结构没变
常见于数据库配置未生效或迁移记录表（migration）不同步。TP 的迁移靠 migration 表记录已执行的版本号，如果服务器上这个表为空、损坏，或指向了别的库，就会重复执行或跳过。
实操建议：
- 用
php think migrate:status对比本地和服务器输出，看哪些status是up或down；特别注意batch列是否一致 - 确认服务器
config/database.php中的database配置项是否正确，**别漏掉数据库名后缀（如_prod）导致连错库** - 若只是想强制重放，不要删
migration表，改用php think migrate:refresh；它会先回滚再重跑，且保持记录干净
migrate:rollback 报错：SQLSTATE[42000]: Syntax error or access violation
这通常是因为回滚操作里写了不兼容的 SQL，比如在 down() 方法中用了 DROP COLUMN，但 MySQL 版本低于 5.7.6（旧版不支持），或 SQLite 环境下尝试删主键字段。
实操建议：
- 避免在
down()中写原生 SQL；优先用迁移构造器，例如：$this->table('user')->removeColumn('score')->save(); - 如果必须用原生语句，先查目标服务器 MySQL 版本：
SELECT VERSION();，再确认语法支持情况 - SQLite 下禁用
DROP COLUMN，可改用“新建表 → 导数据 → 删旧表 → 改名”三步法，TP 迁移构造器已内置兼容逻辑
如何让迁移只同步结构，不碰已有数据
迁移本质是代码化的 DDL 操作，只要不主动调用 insert、update 等数据操作，就不会动数据。但容易被忽略的是：某些字段类型变更（如 VARCHAR(255) → TEXT）在 MySQL 中可能触发全表复制，锁表时间长；而添加非空字段又没设默认值，会直接失败。
实操建议：
- 新增字段一律设默认值，哪怕为
null：$table->string('remark')->nullable()->comment('备注'); - 修改字段长度前，先确认是否含数据；有数据时，
changeColumn在低版本 MySQL 上可能失败，建议拆成两步：先加新字段，再用Db::execute()迁移数据，最后删旧字段 - 上线前在测试库用
php think migrate:diff生成差异迁移文件，人工检查 SQL 内容，比盲跑更可靠
迁移不是“一键同步”，它是把数据库演进过程变成可版本管理的代码。真正麻烦的从来不是命令怎么敲，而是每次改字段前，有没有看过线上那张表里到底存了多少条记录、索引建没建、会不会锁几分钟。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
