Drupal 8.x前置动作中间件控制器识别难题：求更优实现方案

我完全理解你遇到的问题——Drupal确实会把控制器包装成Closure对象，这和Symfony原生的处理方式不太一样，直接用instanceof肯定行不通。不过不用纠结反射或者冲突的Resolver，Drupal本身就提供了规范的解决方案，核心是利用它的控制器解析机制和事件订阅系统。

为什么你拿到的是Closure？ #

Drupal的路由系统在解析控制器时，会通过Drupal\Core\Controller\ControllerResolver把路由里定义的控制器（比如字符串形式的"my_module.controller::myMethod"）转换成Closure，这个Closure内部会绑定实际的控制器实例和方法，但直接从ControllerEvent里拿的话只能看到这个包装后的闭包。

符合Drupal规范的实现方式 #

正确的做法是通过事件订阅器监听KernelEvents::CONTROLLER事件，结合Drupal官方的ControllerResolverInterface解析原始控制器定义，这样既能拿到真实的控制器实例，又不会破坏Drupal的内部机制。

步骤1：定义事件订阅器服务

在你的模块的my_module.services.yml里注册订阅器，注入Drupal的控制器解析器：

services:
  my_module.controller_pre_action_subscriber:
    class: Drupal\my_module\EventSubscriber\ControllerPreActionSubscriber
    arguments: ['@controller_resolver']
    tags:
      - { name: event_subscriber }

步骤2：编写事件订阅器类

创建订阅器类，从请求属性中获取原始控制器定义，再用Resolver解析出真实实例：

<?php

namespace Drupal\my_module\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\ControllerEvent;
use Symfony\Component\HttpKernel\KernelEvents;
use Drupal\Core\Controller\ControllerResolverInterface;

class ControllerPreActionSubscriber implements EventSubscriberInterface {

  /**
   * @var \Drupal\Core\Controller\ControllerResolverInterface
   */
  protected $controllerResolver;

  public function __construct(ControllerResolverInterface $controllerResolver) {
    $this->controllerResolver = $controllerResolver;
  }

  public static function getSubscribedEvents() {
    // 设置优先级，确保你的逻辑在其他前置动作前执行
    $events[KernelEvents::CONTROLLER][] = ['executePreControllerLogic', 100];
    return $events;
  }

  public function executePreControllerLogic(ControllerEvent $event) {
    // 从请求属性中获取原始的控制器定义字符串
    $controllerDefinition = $event->getRequest()->attributes->get('_controller');
    if (!is_string($controllerDefinition)) {
      // 非字符串定义的情况（比如直接传入Closure），跳过处理
      return;
    }

    // 用Drupal的Resolver解析出真实的控制器实例
    $controller = $this->controllerResolver->getControllerFromDefinition($controllerDefinition);

    // 现在可以正常用instanceof判断控制器类型了
    if ($controller instanceof \Drupal\my_module\Controller\MyTargetController) {
      // 在这里执行你的前置逻辑，比如修改请求参数、权限检查等
      $event->getRequest()->attributes->set('pre_processed_flag', TRUE);
    }
  }
}

这个方案的优势 #

1. 完全符合Drupal规范：使用官方提供的ControllerResolverInterface，它已经处理了Drupal的服务容器、依赖注入等逻辑，不会和内部机制冲突。
2. 稳定性高：依赖的是Drupal的公开API，而非内部实现细节（比如Closure的静态变量结构），即使Drupal后续版本调整内部逻辑，你的代码也不会失效。
3. 兼容性好：不管你的控制器是类方法还是服务定义（比如_controller: 'my_module.controller:myMethod'），Resolver都能正确解析出实例。

对比你之前的两种方法 #

• 关于直接用Symfony的Resolver：你之前的问题是没用到Drupal扩展后的Resolver，通过依赖注入获取的ControllerResolverInterface实例就是Drupal的实现，完全兼容内部系统。
• 关于反射方法：虽然能临时解决问题，但属于依赖内部实现的hack，后续Drupal版本更新可能导致代码崩溃，不推荐在生产环境使用。

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