嘿，这个问题问到点子上了——直接修改vendor目录里的代码绝对是踩坑行为，下次composer update就会把你的修改覆盖得一干二净，团队协作也会出问题。针对你提到的League\OAuth2\Server\AuthorizationValidators下的类，我给你两个最靠谱的实现方案，都是Laravel生态里的标准玩法：

方案一：继承类 + 服务容器绑定替换（推荐） #

这是最安全、最符合Laravel设计理念的方式，核心思路是继承原类重写逻辑，再通过服务容器替换原接口的实现。

步骤1：创建自定义扩展类 #

在你的项目里新建一个扩展类，比如放在app/Extensions/OAuth2/CustomAuthorizationValidator.php，命名空间设为App\Extensions\OAuth2，然后继承目标类并重写需要修改的方法：

namespace App\Extensions\OAuth2;

use League\OAuth2\Server\AuthorizationValidators\DefaultAuthorizationValidator;

class CustomAuthorizationValidator extends DefaultAuthorizationValidator
{
    // 重写你需要自定义的方法，比如授权载荷校验方法
    public function validateAuthorizationPayload($payload)
    {
        // 保留原类的核心逻辑（可选，根据你的需求决定）
        parent::validateAuthorizationPayload($payload);
        
        // 这里添加你的自定义校验逻辑
        if (!isset($payload['custom_claim']) || empty($payload['custom_claim'])) {
            throw new \InvalidArgumentException('自定义声明custom_claim不能为空');
        }
        
        return $payload;
    }
}

步骤2：通过服务提供者替换绑定 #

接下来，我们要告诉Laravel：当需要用到原类对应的接口时，用我们的自定义类来替代。

可以新建一个专门的服务提供者（比如OAuthServiceProvider），或者用现有的AuthServiceProvider：

namespace App\Providers;

use App\Extensions\OAuth2\CustomAuthorizationValidator;
use Illuminate\Support\ServiceProvider;
use League\OAuth2\Server\AuthorizationValidators\AuthorizationValidatorInterface;

class OAuthServiceProvider extends ServiceProvider
{
    public function register()
    {
        // 将接口绑定到我们的自定义实现类
        $this->app->bind(
            AuthorizationValidatorInterface::class,
            CustomAuthorizationValidator::class
        );
    }
}

最后别忘了把这个服务提供者加到config/app.php的providers数组里，让Laravel加载它。

这样一来，框架里所有依赖AuthorizationValidatorInterface的地方，都会自动使用你的自定义类，完全不需要修改控制器里的代码——控制器里还是正常依赖注入接口就行，完美实现解耦。

方案二：Composer类映射替换（极端场景使用） #

如果原类没有提供对应的接口（这种情况比较少见），没法用接口绑定的方式，那可以用Composer的类映射优先级来强制加载你的自定义类。不过这个方法要谨慎，因为原包更新后，你的自定义类可能和新版本的类结构不兼容。

步骤1：复制并修改原类 #

把vendor/league/oauth2-server/src/AuthorizationValidators/DefaultAuthorizationValidator.php的代码复制到你的项目目录，比如app/Overrides/League/OAuth2/Server/AuthorizationValidators/DefaultAuthorizationValidator.php，然后在这个文件里修改你需要的逻辑。

步骤2：修改Composer配置 #

在composer.json的autoload部分添加类映射路径，让Composer优先加载你项目里的文件：

"autoload": {
    "classmap": [
        "app/Overrides/"
    ],
    // 保留你原有的autoload配置...
}

然后运行composer dump-autoload更新自动加载缓存，这样Composer加载类时会先找你app/Overrides下的文件，再去vendor目录找。

关于“从控制器中扩展该类”的疑问 #

不建议直接在控制器里做类扩展的操作——控制器的职责应该是处理请求、调用业务逻辑、返回响应，把扩展第三方类的逻辑放在控制器里会让代码变得臃肿，也不符合单一职责原则。

如果只是临时测试，你可以在控制器里直接实例化自定义的扩展类，但这绝对不是生产环境的最佳实践。还是推荐用上面的服务容器方案，把扩展逻辑抽离到单独的类里，通过依赖注入的方式使用。

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