首先我们知道在创建对象时construct会自动执行

PHP中的构造函数（constructor）是在创建对象时自动调用的一个特殊方法。它的主要目的是初始化对象，为对象的属性分配内存并设置初始值。构造函数的名称必须与类名相同。例如：

class MyClass {
    public $property;

    // 构造函数
    public function __construct() {
        $this->property = "Hello, World!";
    }
}

// 创建对象时，构造函数会被自动调用
$obj = new MyClass();
echo $obj->property; // 输出: Hello, World!

在上面的例子中，当我们使用 new MyClass() 创建了一个 MyClass 类的实例时，__construct() 方法自动被执行，初始化了 $property 属性。

那为什么thinkphp明明index()未执行，为什么通过 Request::action可以获取到action index()？

class admin extends BaseController
{
     //当创建对象时会被调用
    public function __construct()
    {
        echo Request::action();
        //定义一个键值数组用于列表信息
         $data =[
            '用户管理'=>[
            '/admin/usercenter'=>'用户中心',
         '/admin/useradd'=>'管理员管理'
        ]
  
        ]; 
   
        View::assign('left',$data);
        View::assign('title1','管理中心');
    }
    public function index()
    {
        return view('login',['title'=>'管理员登录']);
    }
}

Request::action() 能够在执行 index() 方法时返回 "index"，其本质原因是 ThinkPHP 框架在处理 HTTP 请求时，遵循了一套精心设计的流程来管理请求上下文。下面是这一过程的关键步骤，解释了为何 Request::action() 能够正确返回当前 action 名称：

1. 路由解析：当一个 HTTP 请求到达时，ThinkPHP 首先会根据请求的 URL 进行路由解析。路由系统会识别出请求应该映射到哪个控制器类（Controller）的哪个方法（Action）上。这个解析过程确定了当前请求的目标 action。
2. 创建 Request 实例：在处理请求的初期，ThinkPHP 会创建一个 Request 类的实例。这个实例中包含了请求的所有信息，包括从路由解析得到的控制器和 action 名称。这个实例在整个请求生命周期中都是可访问的。
3. 存储 action 名称：解析出的 action 名称会被保存在 Request 实例的内部。虽然你直接调用的是静态方法 Request::action()，但这个方法内部实际上是从已经存在的 Request 实例中检索 action 名称。这意味着即使在执行具体的 action 方法（如 index()）时调用 Request::action()，它也能访问到之前解析并保存的 action 名称。
4. 静态方法的便捷访问：尽管底层数据存储在 Request 的实例中，但通过静态方法 Request::action() 提供了一个全局、无须实例化的访问点。这使得在任何需要的地方，都可以方便地获取到当前 action 名称，而不需要显式地传递或重新获取 Request 实例。

综上所述，Request::action() 能够在执行 index() 方法时返回 "index"，是因为 ThinkPHP 框架在请求处理的早期阶段就已经完成了 action 名称的解析和存储，并通过静态方法提供了一种便捷的访问方式，确保了该信息在整个请求生命周期内的一致性和可访问性。

不是静态方法吗，那不是直接访问类中的静态方法吗？

确实，当调用 Request::action() 时，它看起来像一个静态方法调用，但实际上 ThinkPHP 内部实现了一些机制来桥接静态调用到具体的实例数据。虽然表面上是通过静态方法的形式调用，但背后的操作逻辑涉及到对已存在的 Request 实例的访问。

在 ThinkPHP 或类似的框架中，静态方法如 Request::action() 往往是作为一个便捷的访问入口，用于快速获取请求相关的数据。这些静态方法内部通常会使用类似单例模式的设计，通过 Request::instance() 或类似方法获取当前请求的共享实例（即使它是非静态成员），然后从这个实例中读取或操作数据。

因此，虽然语法上是静态调用，但实际上框架背后做了以下工作：

• 确保每个请求都有一个全局可访问的 Request 实例，这个实例保存了所有关于当前请求的信息。
• 静态方法 Request::action() 内部使用这个全局实例（而非静态变量）来获取 action 名称，确保了它能够反映出实际的请求上下文。

所以，尽管从代码书写形式上看是静态方法调用，但实际上访问的 data（例如 action 名称）是存储在每个请求生命周期内的 Request 实例中，并通过框架提供的静态方法接口进行了抽象和简化访问。

全局实例

在PHP中，尤其是提到像ThinkPHP这样的框架时，全局实例的概念通常体现为通过依赖注入容器或者单例模式管理的类实例。这里通过一个简化的例子来说明如何在PHP中创建一个全局可访问的实例，类似于ThinkPHP框架中 Request实例的处理方式：

示例：模拟一个简单的全局日志记录器

假设我们想要在PHP项目中创建一个全局的日志记录器，使得任何地方都能轻松地记录日志，而无需每次手动创建日志对象。

步骤 1: 定义日志记录器类

class Logger {
    private static $instance;

    private function __construct() {}

    // 获取日志记录器的单例实例
    public static function getInstance() {
        if (null === self::$instance) {
            self::$instance = new self();
        }
        return self::$instance;
    }

    public function log($message) {
        echo "Logging: " . $message . PHP_EOL;
    }
}

这里，Logger类使用了单例模式，确保只有一个日志记录器实例存在。

步骤 2: 在应用中使用全局日志记录器

function someFunction() {
    $logger = Logger::getInstance();
    $logger->log("This is a log message from someFunction.");
}

function anotherFunction() {
    $logger = Logger::getInstance();
    $logger->log("Another log message from anotherFunction.");
}

someFunction();
anotherFunction();

在这个例子中，无论在 someFunction还是 anotherFunction中，我们都是通过调用 Logger::getInstance()来获取日志记录器的同一个实例，并记录日志。这就是一个全局实例的应用，它允许我们在不传递实例作为参数的情况下，在应用的任何位置访问和使用这个日志记录器。

总结

通过单例模式或依赖注入容器，PHP应用可以创建和管理全局可访问的实例，如同ThinkPHP框架中的 Request实例一样。这样的设计提高了代码的可维护性和复用性，同时减少了对象创建和传递的复杂度。