权限控制的核心在于中间件拦截和角色权限设计。第一步通过中间件在路由层面进行访问控制，如 isadmin 中间件判断用户角色是否为管理员，阻止非法访问；第二步引入角色与权限模型，将用户归类到具体角色，并为角色分配具体权限，实现灵活的动态权限管理；第三步通过 session 或 token 存储角色信息，在每次请求中解析并验证角色权限；第四步注意权限控制细节，如统一错误提示、及时更新权限缓存、对 api 接口进行权限校验，确保系统安全性与可维护性。

用户权限控制是大多数 Web 应用中不可或缺的一部分，而 Sublime 作为一个轻量级但功能强大的编辑器，虽然本身不是框架，但在实际开发中常常用来编写后端代码。如果你使用的是类似 Laravel、Express 或 Django 这样的框架，Sublime 可以很好地配合实现一个基础的用户权限控制系统。

这篇文章不讲理论太多，主要说说怎么在实际项目中从中间件到角色验证一步步搭建一个简单的权限控制逻辑。

中间件是权限控制的第一道防线

权限控制的第一步，通常是通过中间件（Middleware）来拦截请求。中间件就像是门口保安，能决定哪些人可以进哪个门。

比如你有一个后台管理页面，只允许管理员访问。这个时候你可以写一个

isAdmin

if (user.role !== 'admin') {
    return res.status(403).send('无权访问');
}

这个逻辑很简单，但它确实能挡住大部分越权操作。关键是：中间件要放在正确的路由位置上。别把所有逻辑都堆在控制器里，中间件就是干这个的。

几点建议：

• 把通用权限检查抽成中间件，方便复用
• 不要让中间件处理太复杂的业务逻辑
• 多个中间件可以串联使用，比如先认证再鉴权

用户角色与权限的设计不能太随意

很多新手一开始设计权限系统时喜欢直接用布尔值，比如

is_admin: true

比较合理的做法是引入“角色”和“权限”的概念：

• 用户属于某个角色（如 admin、editor、guest）
• 每个角色拥有多个权限（如 create_post、delete_post、view_dashboard）

这样做的好处是你可以在数据库里灵活配置权限，而不是硬编码在代码里。

举个例子：

• 角色 A 有权限 X 和 Y
• 角色 B 有权限 Y 和 Z
• 用户登录后根据角色获取对应的权限列表，之后在中间件或控制器中进行判断

这一步的关键在于：不要把权限判断写死，而是尽量动态化，便于后期扩展。

实现角色验证的具体方式

具体怎么验证角色？这里分几个步骤：

1. 用户登录成功后，把角色信息存入 session 或 token
2. 每次请求解析出当前用户的角色
3. 在中间件或控制器中进行角色判断

如果你用的是 JWT 做认证，可以把角色信息放进 token payload 里，这样每次请求都能解析出来。

如果是基于 Session 的系统，也可以在登录时将角色 ID 存入 session，后续请求读取即可。

举个 Express 的简单例子：

function isAdmin(req, res, next) {
    if (req.session.user.role === 'admin') {
        return next();
    }
    res.status(403).send('禁止访问');
}

这种方式虽然简单，但已经能满足大多数小型项目的权限需求了。

权限控制容易忽略的小细节

权限控制看起来简单，但有几个地方很容易被忽略：

• 未授权访问的错误提示要统一：别暴露太多内部信息，比如“您不是管理员”，不如直接返回 403。
• 权限缓存要及时更新：如果用户角色变更，记得清除旧的权限缓存，否则会出现权限不同步的问题。
• 接口也要做权限校验：很多前端开发者只在页面级别做了权限控制，但 API 接口没限制，这就很容易被绕过。

这些小问题平时不容易察觉，但上线后可能造成严重的安全漏洞。

基本上就这些。权限控制的核心其实并不复杂，关键是要把它贯穿在整个请求流程中，并且保持结构清晰，方便后期维护。