Laravel core通过Guzzle请求Lumen log服务提示core_db.logs表不存在

问题根因 #

这是本地同环境下运行多个Laravel/Lumen项目的典型环境变量污染问题，触发逻辑如下：

• 你两个服务都部署在localhost下，共用同一组php-fpm worker进程。Laravel/Lumen会把.env里的配置项写入$_ENV/$_SERVER超全局变量，而php-fpm的worker进程是复用的，不会在每次请求结束后清空超全局变量。
• 当core服务处理请求时，当前fpm worker的超全局变量会被写入core的数据库配置（DB_DATABASE=core_db）。此时core通过Guzzle调用log服务的接口，该请求刚好被同一个fpm worker处理。
• Lumen默认使用Dotenv::createImmutable()加载.env，逻辑是如果超全局变量中已存在同名配置项，就不会再加载自身.env里的对应配置，所以log服务此时读取到的DB_DATABASE是core服务的core_db，自然找不到core_db.logs表。
• Postman请求正常是因为请求直接打到log服务，处理请求的fpm worker此时超全局变量是干净的，会正常加载log服务自身的.env配置。

解决方案 #

临时快速修复（优先验证） #

直接在log服务侧强制指定数据库连接，跳过被污染的全局配置：

1. 给Log模型显式指定连接，在模型中新增一行属性：

// 值为log服务config/database.php里你配置的数据库连接名，默认是mysql
protected $connection = 'mysql';

2. 修改验证规则里的unique规则，强制指定连接名：

// 连接名和上面保持一致，格式为 连接名.表名
'key' => 'required|unique:mysql.logs,key',

彻底修复环境变量污染 #

二选一即可：

• 方案1：本地给两个服务配置独立虚拟主机，比如core.test和log.test，分别绑定独立的fpm池，避免worker进程跨项目复用。如果用artisan serve启动服务，分别用不同端口启动：core跑php artisan serve --port=8000，log跑php artisan serve --port=8001，Guzzle请求地址改成http://localhost:8001/store即可。
• 方案2：修改log服务的bootstrap/app.php，强制覆盖超全局变量加载自身.env：
  把默认的env加载逻辑替换为：

// 强制覆盖已存在的环境变量，加载当前服务的.env配置
Dotenv\Dotenv::createUnsafeImmutable(base_path())->overload();

内容的提问来源于stack exchange，提问作者M a m a D