Laravel项目迁移至其他文件夹后执行命令报1146数据表不存在错误

这个报错和你复制项目文件夹、composer依赖没有关系，核心原因是Laravel在执行任何Artisan命令（包括php artisan migrate）时，都会先完成应用启动流程：加载所有服务提供者、全局中间件、注册所有Artisan命令，这个流程跑完才会执行你输入的具体命令逻辑。
只要启动流程里有直接执行的数据库查询逻辑，而查询对应的表还没创建，就会直接触发表不存在的报错，连迁移命令本身都跑不起来。常见的触发场景有这些：

• 在自定义服务提供者（比如AppServiceProvider的register/boot方法）中直接编写了查库逻辑，通常是取站点全局配置、导航栏数据这类需要全局共享的逻辑，没有做表存在校验
• 在全局中间件、路由文件的最外层（而非路由闭包、控制器方法内部）写了裸查库逻辑，框架启动时就会立刻执行，不需要匹配路由
• 自定义Artisan命令的构造方法里写了查库逻辑，框架启动时会实例化所有注册的Artisan命令，哪怕你跑的是migrate命令也会触发这段查询
• 安装的第三方扩展包的服务提供者默认会查询自身的配置表，你还没执行对应扩展的迁移创建表，就会提前触发报错
  你导入旧数据库后报错消失，本质是提前把查询依赖的表创建好了，让启动阶段的查询能正常执行，并没有解决根本问题。

• 第一步先定位报错位置：打开.env文件把APP_DEBUG设置为true，重新执行任意Artisan命令，从报错的调用堆栈里可以直接定位到具体是哪个文件、哪一行代码触发了查库逻辑。
• 对所有放在应用启动阶段执行的查库逻辑，增加表存在判断，表不存在时跳过查询、返回默认值即可，参考写法：

// 放在服务提供者boot方法中的全局配置查询示例
use Illuminate\Support\Facades\Schema;

public function boot()
{
    // 先判断表是否存在，不存在就不执行查询
    if (Schema::hasTable('system_configs')) {
        $siteConfig = ConfigModel::all()->pluck('value', 'key');
        view()->share('siteConfig', $siteConfig);
    }
}

• 不要把依赖数据库的逻辑写到服务提供者的register方法里，这个阶段框架的数据库连接、配置加载还未完全就绪，非常容易触发各类启动报错。
• 如果是第三方扩展包触发的报错，可以暂时在config/app.php的服务提供者列表中注释掉对应扩展的服务提供者，等跑完php artisan migrate把所有业务表、扩展表创建完成后，再取消注释即可。
• 排查路由文件、全局中间件中的代码，不要在文件最外层写直接执行的查库逻辑，这类逻辑应该放到控制器方法、中间件的handle方法内部，只有匹配到对应请求/命令场景时才执行。

内容的提问来源于stack exchange，提问作者ITtraders Nepal