Laravel迁移是基于时间戳顺序执行的版本化脚本机制，非自动同步工具；必须用php artisan make:migration生成文件以确保时间戳唯一、类名匹配、框架预填正确，避免手动修改时间戳或文件名导致执行错乱。
Laravel 迁移不是数据库结构同步工具，而是基于时间戳顺序执行的版本化脚本机制 —— 它不检测 SQL 语义冲突，也不自动跳过已存在表，出错必须靠人工干预和规范流程兜底。
怎么生成迁移文件才不会乱序或重名
时间戳是 Laravel 执行顺序的唯一依据，手动改文件名里的日期（比如把 2024_05_20_103022_create_users_table.php 改成 2024_05_19_...）会导致本地和团队环境执行错乱。
- 永远用
php artisan make:migration create_posts_table --create=posts或php artisan make:migration add_status_to_posts --table=posts生成，让 Artisan 自动打上当前毫秒级时间戳 - 加
--create或--table参数不只是省事，它会自动在up()里预填Schema::create()或Schema::table()框架，避免手误写反 - 多人协作时，如果 Git 合并出现两个同名但不同时间戳的迁移（如
add_status_to_posts_2023_05_10_142300.php和add_status_to_posts_2023_05_10_142500.php），必须删掉一个，并确认down()逻辑仍能对称回滚
执行迁移时报 “Base table or view not found” 怎么快速定位
这通常不是数据库连不上，而是迁移脚本和当前数据库状态脱节：Laravel 尝试对一个不存在的表做操作（比如加外键、改字段），但 migrations 表里却记着这条迁移“已执行”。
- 先查
SELECT * FROM migrations WHERE migration LIKE '%add_avatar%';，确认该迁移是否真在库中记录为已执行 - 再查
SHOW TABLES LIKE 'users';，看目标表是否存在；如果表被手动删过，但迁移记录还在，就必然报这个错 - 别直接删
migrations表里的记录 —— 正确做法是先php artisan migrate:rollback --step=1回退最后一批，再php artisan migrate重试 - 如果 rollback 也失败并报
Class XXX does not exist，说明类名/文件名不匹配或 autoloader 没更新，立刻运行composer dump-autoload
修改已有字段类型为什么有时不生效
Laravel 默认 Schema 构建器不支持直接改字段类型（如把 string 改成 text），Schema::table(...)->change() 必须依赖 doctrine/dbal 扩展，且 MySQL 版本、引擎、字符集都可能拦住它。
- 先确认已安装：
composer require doctrine/dbal（Laravel 10+ 需显式装） - 改字段必须用
$table->string('title')->change();，不能只写$table->string('title');—— 后者是新增字段 - MySQL 中如果原字段有索引、外键或 FULLTEXT，
change()很可能静默失败或报错SQLSTATE[HY000]: General error: 1025，此时得手动用DB::statement()写原生ALTER TABLE -
timestamps()生成的是DATETIME类型，不是TIMESTAMP；如果硬要改成TIMESTAMP，得弃用timestamps()，手写$table->timestamp('created_at')->useCurrent();
生产环境跑 migrate 为什么总被警告 “--force”
这是 Laravel 的安全锁：默认禁止在生产环境执行任何迁移，防止误操作炸掉线上表结构。它不看你 APP_ENV 是什么，只认 APP_DEBUG=false 且 APP_ENV=production 的组合。
- 上线前必须加
--force：例如php artisan migrate --force，否则命令直接退出 - 但加了
--force不代表万事大吉 —— 如果迁移里有Schema::dropIfExists()或DB::statement('TRUNCATE')，依然可能锁表数秒甚至更久，务必避开流量高峰 - 高频写入表（如订单、日志）建议拆成两步：先加字段（
nullable）、发版、再用另一批迁移设默认值或补数据，避免长事务阻塞 - 千万别在生产环境用
migrate:fresh或migrate:refresh，它们会清空所有表，没有后悔键
最常被忽略的一点：迁移文件里写的 up() 和 down() 必须严格对称，但 Laravel 不校验这点。比如 up() 里加了索引，down() 却忘了删，下次 rollback 看似成功，其实索引还挂着 —— 这种残留问题往往要等半年后查慢查询才暴露出来。
