Laravel Passport client_credentials下Bearer令牌控制器接口未认证

根据你描述的「闭包路由可正常通过、控制器路由返回Unauthenticated」的特征，问题根因基本可以排除Passport基础配置、请求头传递的问题，聚焦在控制器层隐式挂载的认证逻辑上，按以下步骤逐一排查即可解决：

• 检查目标控制器的构造函数隐式中间件
  打开ApiController类文件，查看类构造函数代码。如果存在$this->middleware('auth:api')类的通用认证逻辑，会在控制器方法执行前额外触发用户维度的认证校验。Client Credentials模式签发的令牌不关联任何系统用户实体，必然触发认证失败。而闭包路由不经过控制器构造流程，所以能正常通过校验。
  修复方式：删除构造函数中通用的用户认证中间件，或针对va_bills方法单独排除认证逻辑。
• 排查路由组的全局挂载中间件
  打开app/Providers/RouteServiceProvider.php，查看api路由组的配置定义，确认是否给所有/api路径的路由默认挂载了auth:api中间件。如果控制器路由被划入了带全局用户认证的路由组，哪怕路由定义上单独配置了client_credentials中间件，全局挂载的认证逻辑依然会优先触发报错。
  修复方式：将该测试路由移出带有全局auth:api的路由组，或在全局配置中针对需要客户端凭据认证的路径排除用户校验逻辑。
• 清理本地缓存的旧配置
  你已经修改了中间件注册规则、认证守卫配置，如果之前执行过路由缓存、配置缓存命令，旧的缓存规则会导致实际运行的中间件队列和预期配置不一致。依次执行以下命令清理缓存：

  php artisan route:clear
  php artisan config:clear
  php artisan cache:clear
  

• 澄清.htaccess配置的适配误区
  当前使用php artisan serve启动本地开发服务，该服务是PHP内置开发服务器，完全不解析Apache的.htaccess规则，这段配置在本地测试环境不生效。而闭包路由可以正常访问的事实，已经证明Authorization请求头可以正常传递，这部分配置不是问题根因，仅在后续部署到Apache环境时需要保留。
• 兜底校验逻辑
  如果完成以上步骤依然报错，可以临时在CheckClientCredentials中间件的处理逻辑中，打印当前请求携带的Authorization头值，确认控制器路由场景下是否真的收到了正确的Bearer令牌，排除因路由优先级匹配偏差，导致请求落到其他带用户认证逻辑的路由上。

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