Laravel跨应用调用API时错误访问非目标数据库表问题

核心原因分析 #

报错提示找不到abc.subscriptions表，但该表实际存在于def数据库中，说明abc.test应用自身触发了对subscriptions表的查询，而非请求到def.test的API执行查询（Postman调用def正常，证明def的API逻辑无问题）。最可能的情况是abc.test中发送请求的客户端不是HTTP客户端，而是错误调用了本地代码（比如直接执行def的控制器方法），导致用abc的数据库连接去查询不存在的表。

具体排查与解决步骤 #

1. 确保使用正确的HTTP客户端发送请求 #

abc.test必须用Guzzle等HTTP客户端发送请求到def.test的API，不能直接调用本地控制器或服务：

• 引入正确的Guzzle命名空间：

  use GuzzleHttp\Client;
  

• 构造函数注入或直接实例化Guzzle客户端：

  // 方式1：构造函数注入
  public function __construct(Client $client)
  {
      $this->client = $client;
  }
  
  // 方式2：方法内直接实例化
  public function create(): View
  {
      if(!session()->has('license')){
          $client = new \GuzzleHttp\Client();
          $response = $client->request('POST', 'http://def.test/api/service',[
              'form_params' => [
                  'license_key' => base64_encode(config('def.license'))
              ],
          ]);
          // 可选：将响应数据存入session
          session(['license' => $response->getBody()->getContents()]);
      }
      return view('auth.login');
  }
  

2. 检查abc.test的路由与中间件 #

排查是否有路由或中间件意外触发了subscriptions表的查询：

• 检查routes/web.php中login路由的配置，确认没有绑定到错误的控制器方法；
• 检查全局中间件或路由组中间件，看是否有代码调用了Subscription模型或执行了相关数据库查询。

3. 定位触发查询的具体代码 #

查看Laravel日志的完整堆栈信息，找到具体触发查询的代码行：

• 打开storage/logs/laravel.log，找到对应报错条目，查看Stack trace部分，定位到业务代码的行数；
• 如果abc.test中存在Subscription模型，全局搜索项目中的Subscription::，排查未预期的调用。

4. 验证请求确实发送到def.test #

在def.test的getSubs方法开头添加日志，确认是否收到abc.test的请求：

public function getSubs(Request $request)
{
    \Log::info('Received request from abc.test', $request->all());
    // 原逻辑...
}

如果def.test的日志中没有收到请求，说明abc.test的请求根本没发出去，而是在本地执行了错误代码。

内容的提问来源于stack exchange，提问作者Muzakir Nur