ThinkPHP控制器基类扩展与统一业务逻辑实现优化

如果你计划从ThinkPHP 5升级到版本6，并且希望扩展一个控制器基类来统一处理登录、权限或公共数据，那么需要注意一个关键问题：直接沿用TP5的写法，可能导致依赖注入、中间件等核心功能失效。

这一问题的根源在于ThinkPHP 6的架构设计发生了根本性变化。框架移除了原有的 think\Controller 类，转而采用 think\controller\AbstractController 作为控制器的抽象基类。框架的核心能力，如容器绑定、AOP切面和中间件调度，现在都由 think\facade\App 驱动的实例化流程来管理。

如果自定义基类没有正确接入这个生命周期，可能会引发以下连锁问题：

• 控制器内常用的 $this->request、$this->app 等属性变为 null。
• 在构造函数中调用 validate() 等方法会报错，提示方法不存在。
• 配置好的中间件，其 beforeAction 钩子可能不会触发。
• 依赖注入完全失效，无法通过类型声明自动获取 UserService 等服务实例。

正确扩展控制器基类的三步写法（适用于TP6.1+）

要让自定义基类真正发挥作用，关键是使其参与到容器的管理流程中，并复用框架标准的初始化链路。具体需要遵循以下三个步骤：

• 首先，确保基类继承自 think\controller\AbstractController，而不是手动创建构造函数或沿用旧类。
• 其次，重写 initialize() 方法（注意不是 __construct() 构造函数），所有需要在控制器动作执行前运行的预处理逻辑都应放在这里。
• 最关键的一步：在 initialize() 方法的第一行，务必调用 parent::initialize()。这确保了框架内部的初始化工作（如请求对象绑定、中间件注册）不会被意外跳过。
• 对于需要统一处理的前置校验，优先考虑使用中间件；如果需要在基类中进行统一的数据组装，也应通过 $this->app->make('MyValidator') 这样的方式从容器获取实例，避免硬编码的 new 操作。

namespace app\controller;

use think\controller\AbstractController;

class BaseController extends AbstractController
{
    protected function initialize()
    {
        parent::initialize(); //  必须第一行
        $this->checkLogin();
        $this->assignCommonData();
    }

    protected function checkLogin()
    {
        if (empty(session('user_id'))) {
            $this->error('请先登录', '/login');
        }
    }
}

统一业务逻辑该放哪里？避免只依赖控制器基类

许多开发者容易陷入一个误区：试图将所有公共逻辑（如权限、日志、参数过滤、响应包装）都塞进 BaseController。这会导致基类迅速膨胀，难以维护。更合理的架构分层思路如下：

• 权限控制：交给单独的中间件（例如 app/middleware/AuthMiddleware.php），这样可以灵活地按路由或路由组启用，控制粒度更细。
• 请求参数预处理：例如字段解密、映射等，可以考虑扩展 think\Request 类的方法，或通过容器绑定自定义的 Request 类来覆盖默认实现。
• 统一异常响应：改写 app/exception/Handler.php 文件中的 render() 方法，这是处理全局异常和统一响应格式的最佳位置。
• 通用数据注入：像站点配置、用户基础信息这类数据，可以在一个视图中间件中统一调用 $this->view->assign()，这比在每个控制器的 initialize() 里重复赋值更清晰可控。

还有一个容易被忽略的细节：在TP6中，控制器实例是由容器为每个请求全新创建的。但请注意，initialize() 方法并不是构造函数，它不接收参数，也不参与依赖注入的自动解析。这意味着，所有需要在基类中使用的依赖，都必须显式地通过 $this->app->make() 获取，或者在其后具体的控制器方法中通过类型提示来注入。忽略这一点，即使基类写得再完善，程序也可能无法正常运行。