首先想到的是，这似乎是不必要的，因为我们在providers中定义了config/app.php来自动加载任何ServiceProvider，但事实证明有一种情况他们不会自动加载：
当我们从Laravel Queue开始工作时 - 配置中的ServiceProvider似乎完全被忽略，因此DI失败了target ... is not instantiable。
在运行时注册我的服务提供者工作确实有效。例如
App::register('MyServiceProvider');
在这种情况下，Laravel是否有理由不自动加载我的ServiceProvider？
PS：我也开了一个问题on github，因为如果这是设计的话，我不是。
答案 0 :(得分：1)
如果您通过URL定义环境，则不会从命令行自动识别这些环境 - 我在尝试运行迁移/种子时自己遇到此问题。
您可以以任何您喜欢的方式定义环境，因为环境定义接受了一个闭包，但是“开箱即用”您可以返回与机器名称或URL匹配的正则表达式。这里的示例 - environment config。
一种解决方案是在配置路径的app.php中定义服务提供者（这是默认配置，如果没有从命令行识别其他环境，将使用）或者如果您需要不同的设置对于不同的环境，您可以尝试按机器名称定义环境 - 这是您机器的主机名 - 在unix框中，您可以在命令行上看到echo $ HOSTNAME的内容。
OP的另一个解决方案
正如OP发现的那样，工匠在几乎所有允许你强制环境的命令上接受--env标志，所以你可以调用php artisan queue：work --env = local来强制它使用本地配置在工作队列时。
希望这有帮助