ThinkPHP 如何实现权限控制

时间：2026-08-23 | 作者：白桃企划师 | 阅读：0

前言

在 ThinkPHP 里做权限控制，真正要处理的不是“有没有登录”这么简单，而是把身份校验、Token 传递和权限判断接成一条完整链路。本文按请求经过系统的顺序来拆解认证与授权的分工，再结合中间件示例说明基础实现方式，以及哪些部分还只是演示代码、哪些才是实际项目必须补齐的能力。

在 ThinkPHP 项目里做权限控制，最容易混淆的就是“认证”和“授权”这两个环节：前者解决“你是谁”，后者解决“你能做什么”。如果只校验登录状态，不做权限判断，很多接口依然可能被越权访问；反过来，权限设计得再细，没有稳定的身份校验也落不了地。

这篇文章按一条完整请求链路来拆解：先看用户登录后 Token 是怎么产生和传递的，再看服务端如何在中间件里拦截请求，最后落到角色与权限校验。读完你可以判断一个 ThinkPHP 权限方案是否只是演示级写法，还是已经具备进入实际项目的基本结构。

权限控制为什么要分认证和授权

在 ThinkPHP 里做接口保护，通常要分成两个步骤处理：

认证：先确认用户身份

认证对应的是登录态校验，目标是确认当前请求到底是谁发起的。常见流程包括：

用户输入账号和密码，由系统校验凭据是否合法。
认证通过后，服务器生成一个 Token，比如 JWT，并返回给客户端。
客户端保存这个 Token，常见位置包括 LocalStorage 或 SessionStorage，后续请求继续携带它。

这一层的结果只有一个：服务端能不能识别出当前用户身份。

授权：再确认用户能访问什么

授权是在身份确认之后继续做的限制，解决的是“已登录用户是否有资格执行当前操作”。常见做法包括：

定义角色，例如管理员、编辑、访客。
给不同角色分配权限，例如访问某个页面、调用某个接口、执行某个操作。
在真正处理请求之前，检查当前角色是否具备对应权限。

也就是说，认证通过并不代表一定能访问目标资源，权限判断必须单独执行。

一次请求里的权限校验链路

把整个过程串起来看，ThinkPHP 权限控制一般会经过下面几步：

ThinkPHP 请求从登录到接口放行的权限校验链路图 — **ThinkPHP 权限校验链路**用流程图把登录、携带 Token、认证校验和授权放行串起来，便于区分 401 与 403。

用户登录成功后拿到 Token。
客户端后续每次发起请求，都在请求头中带上 Token。
服务端通过中间件或拦截器读取 Token，并验证其是否有效。
Token 有效后，解析或查出当前用户信息。
再根据用户角色、权限配置和当前访问动作，决定是否放行请求。

这条链路里，中间件是最适合承接逻辑的位置。因为它能在控制器执行业务逻辑之前统一拦截请求，把认证和授权从具体控制器代码里抽出来。

在 ThinkPHP 中用中间件落地

原始思路很直接：先做一个认证中间件校验 Token，再做一个授权中间件检查用户是否有权限访问当前动作，最后把两个中间件注册到应用中。

ThinkPHP 认证中间件与授权中间件的职责分工图 — **认证与授权中间件怎么分工**把两个中间件的输入、处理内容和输出结果拆开，方便读者理解为什么要分层。

认证中间件：校验 Token 并附加用户信息

认证中间件负责两件事：读取请求头里的 Authorization，以及根据 Token 找到对应用户。

// 认证中间件 AuthMiddleware.php
namespace appmiddleware;
use thinkRequest;
use thinkResponse;
use thinkfacadeCache;

class AuthMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        $token = $request->header('Authorization');
        if (!$token) {
            return Response::create('未授权', 'html', 401);
        }
        // 验证Token
        $user = Cache::get($token);
        if (!$user) {
            return Response::create('Token无效', 'html', 401);
        }
        // 将用户信息附加到请求对象上
        $request->user = $user;
        return $next($request);
    }
}

这段代码体现了一个基础实现思路：

如果请求头里没有 Token，直接返回 401。
如果 Token 无法在缓存里找到对应用户，也返回 401。
校验通过后，把用户信息挂到请求对象上，供后续授权中间件或控制器使用。

这里示例使用的是 Cache::get($token)。实际项目中，Token 也可能来自 JWT 解析结果，或者来自数据库、Redis 等会话存储。

授权中间件：按动作检查权限

授权中间件建立在认证通过的基础上运行，核心是根据当前用户和当前访问动作做权限判断。

// 授权中间件 AuthzMiddleware.php
namespace appmiddleware;
use thinkRequest;

class AuthzMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        $user = $request->user;
        if (!$user) {
            return Response::create('未授权', 'html', 401);
        }
        // 假设我们要检查用户是否有权限访问某个资源
        $hasPermission = $this->checkPermission($user, $request->action());
        if (!$hasPermission) {
            return Response::create('无权限访问', 'html', 403);
        }
        return $next($request);
    }
    protected function checkPermission($user, $action)
    {
        // 这里应该是查询数据库或者其他服务来验证用户权限的逻辑
        // 为了示例，我们假设所有用户都有权限
        return true;
    }
}

这部分要点也很明确：

如果认证中间件没有附带用户信息，继续返回 401。
如果用户已登录，但不具备当前动作权限，则返回 403。
checkPermission($user, $action) 是实际项目里最需要扩展的地方，通常会接角色表、权限表，或者接独立权限服务。

401 和 403 的语义也不要混用：401 表示身份未通过校验，403 表示身份已确认但没有访问权限。

中间件注册与控制器调用

把认证和授权逻辑拆好后，还要让 ThinkPHP 真正执行这些中间件。示例代码中给出了最基础的注册方式：

// 在config/middleware.php中注册中间件
return [
    appmiddlewareAuthMiddleware::class,
    appmiddlewareAuthzMiddleware::class,
];

// 在控制器中使用中间件
namespace appcontroller;
use thinkController;
use thinkRequest;

class Index extends Controller
{
    // 应用认证和授权中间件
    public function index(Request $request)
    {
        // 用户已通过认证和授权，可以执行业务逻辑
        return 'Hello, World!';
    }
}

这个结构说明了一个常见实践：把通用访问控制放到全局或路由层中间件里，让控制器只关注业务逻辑。这样做有两个直接好处：