“no such table”或“base table or view not found”错误主因是laravel未连上预期数据库或迁移未成功执行：需确认.env中db_database指向已创建的空库，用php artisan tinker验证db连接，检查migrations表是否存在及记录数是否匹配迁移文件数，避免手动删表，优先用migrate:rollback回滚再重迁。
直接执行迁移用 php artisan migrate，但多数报错不是命令写错，而是环境、配置或迁移文件本身没对齐。
为什么 php artisan migrate 报 “No such table” 或 “Base table or view not found”
这不是命令问题，是 Laravel 没连上你预期的数据库，或者迁移没真正执行成功过。
- 检查
.env文件里的DB_DATABASE是否指向一个已创建的空库（Laravel 不自动建库） - 运行
php artisan tinker后执行DB::connection()->getPdo()，确认连接的是哪个库名和 host - 查
migrations表：如果表存在但无记录，说明迁移根本没跑过；如果记录数少于迁移文件数，说明中途失败卡住了 - 别手动删表再重跑——先用
php artisan migrate:rollback --step=1退一步，再migrate，避免状态错乱
php artisan migrate:fresh 和 migrate:reset 的关键区别
两者都清库，但触发逻辑和适用场景完全不同。
-
migrate:reset只回滚已记录在migrations表里的迁移，依赖该表完整性；如果表损坏或被清空，它就“失明” -
migrate:fresh直接DROP TABLE IF EXISTS所有表（不含migrations），然后重新跑全部up()—— 它不看migrations表，适合本地开发重置，但生产环境禁用 - 加
--seed参数时，fresh会自动调用db:seed；reset不会 - 想清库但保留某些表（比如
users）？不能靠这两个命令，得手写Schema::dropIfExists('xxx')在迁移里控制
迁移文件里 up() 和 down() 不对称的常见坑
很多报错源于 down() 写得不严谨，导致 rollback 失败，进而阻塞后续迁移。
- 添加字段时，
down()别只写$table->dropColumn('foo')—— MySQL 8.0+ 要求先禁用外键检查，或确保字段不存在再删，否则报SQLSTATE[HY000]: General error: 1091 Can't DROP 'foo' - 改列类型用
change()，但 SQLite 不支持，down()若没判断驱动类型，切换环境就崩 - 删除外键约束必须显式命名：建索引时用
->foreign('user_id')->references('id')->on('users')->onDelete('cascade')，删的时候得用dropForeign('table_user_id_foreign')，名字不对就报错 - 别在
down()里写DB::table('xxx')->truncate()—— 这不是 Schema 操作，rollback 状态无法追踪，且 truncate 不触发模型事件
迁移不是“写完就能跑”，核心是让 migrations 表与数据库结构始终严格一致。最常出问题的地方，往往不在命令怎么敲，而在 .env 配置是否生效、migration 文件是否被 autoload 发现、以及 down() 逻辑有没有覆盖所有 rollback 路径。
