Laravel 的 migrate 命令提示“Nothing to migrate”是因为它只检查 migrations 表记录，不验证物理表是否存在；常见原因包括迁移记录缺失、文件命名或类名错误、up() 方法被条件跳过或静默失败。
php artisan migrate 提示 “Nothing to migrate” 但表确实没建
这是最常被误判为“命令没跑”的假象。Laravel 不看物理表是否存在，只查 migrations 表里有没有对应记录。
常见错误现象：
- 手动删过
modules表，但没清migrations表里的2023_05_10_120000_create_modules_table记录 - 迁移文件名写错（比如用了短横线
-而非下划线_），导致 Laravel 根本没扫描到它 - 类名不匹配：文件叫
create_modules_table.php，但类声明是class CreateModuleTable（少了个s）
实操建议：
- 进数据库执行
SELECT * FROM migrations WHERE migration LIKE '%modules%';，确认记录是否存在 - 运行
php artisan migrate:status，看该迁移是否显示为Ran - 用
php artisan make:migration create_modules_table重生成，别手写命名
执行 migrate 后表还是空，但没报错
说明迁移文件的 up() 方法执行了，但逻辑可能被跳过或失败静默——尤其是用了条件判断、环境检查或异常捕获却没抛出。
使用场景：
- 在
up()里写了if (app()->environment('production')) return;，而你正在本地开发 - 调用了
Schema::hasTable('modules')判断后直接return，但表其实不存在（因为判断写反了） - 用了
DB::statement()执行原生 SQL，但语法有错，MySQL 没报错（比如字段类型不兼容），只是跳过建表
实操建议：
- 打开
APP_DEBUG=true，确保所有 SQL 错误能暴露出来 - 在
up()开头加Log::info('create_modules_table running');，确认方法真被执行了 - 把迁移内容简化成最基础的
Schema::create('modules', ...)单独测试
php artisan migrate:fresh 也没建出 modules 表
migrate:fresh 是清库重建，但它不会绕过迁移文件本身的执行逻辑——如果那个创建 modules 表的迁移文件根本没被加载，或者 up() 里有致命错误（比如引用了未定义的类），它一样会失败或跳过。
容易踩的坑：
-
migrate:fresh默认只删业务表，不碰migrations和failed_jobs，但如果你之前手动删过migrations表，它就彻底失去状态依据 - 迁移文件依赖其他迁移（比如外键指向
users表），但users表迁移时间戳更晚，migrate:fresh仍按时间戳顺序执行，导致外键创建失败并中断 - 用了
--path参数但路径拼错，比如写成--path=database/migrations/2023_...，Laravel 会拼成database/migrations/database/migrations/...，然后静默忽略
实操建议：
- 先运行
php artisan migrate:status确认所有迁移都显示Pending，再跑fresh - 临时注释掉所有外键相关代码，验证
modules表能否单独建出来 - 用
php artisan migrate --path=2023_05_10_120000_create_modules_table.php单独执行该文件
Seeder 报错 “Base table or view not found: modules”
这个错误不是 Seeder 本身的问题，而是它启动时发现 modules 表不存在——说明 migrate 阶段压根没成功建表，或者建表被跳过了。
关键点在于：php artisan migrate --seed 是串行执行：先全部 migrate，再统一 run seeder。Seeder 不参与建表，也不修复迁移失败。
性能与兼容性影响：
- 如果
modules表是其他迁移的外键依赖目标，而它没建出来，后续所有依赖它的迁移都会失败，形成连锁中断 - SQLite 环境下，即使迁移文件写了
foreignId('user_id')->constrained()，若没在连接配置里启用PRAGMA foreign_keys = ON，建表也会静默失败
实操建议：
- 不要直接跑
--seed，先确保php artisan migrate明确输出了Creating modules table这类日志 - 检查
config/database.php中 SQLite 连接是否加了'options' => [PDO::ATTR_EMULATE_PREPARES => true]和初始化语句 - Seeder 里别假设表一定存在，加一层
if (Schema::hasTable('modules')) { ... }防御性判断
迁移真正卡住的地方，往往不在 SQL 语法，而在 Laravel 对 migrations 表那几行记录的绝对信任——它不校验表是否存在，只认记录。一旦状态和物理结构脱节，所有命令都会表现得“很安静”，但结果完全不对。
