功能级访问控制缺失的隐患与RBAC权限模型落地实践

1. 功能级访问控制缺失，到底是个什么问题

1.1 先从一次线上故障说起

去年我接手了某个业务管理系统的二次开发，功能模块倒不复杂，用户、订单、统计、权限四大块，技术栈就是很常见的PHP后端加一套管理后台。刚接手没几天，运营同事跑过来反馈一个问题：有个普通客服账号，竟然能点开“导出全量订单”的按钮，把十几万条订单数据直接拉走。

我当时第一反应是查路由和控制器，结果发现后端接口根本没有做权限判断——登录就行，是个人都能调。整个系统的权限控制只做到了菜单级，也就是“你看得到哪些菜单”，至于菜单里的按钮、接口、操作，全是裸奔状态。换句话说，认证做了，授权等于没做。

这个事给我提了个醒：功能级访问控制的缺失，在PHP项目里不是个别现象，而是大量中小型后台系统里普遍存在，甚至很多系统上线跑了两三年都没被人发现，直到出了数据泄露或者误操作的线上事故才回过头来补课。

所谓功能级访问控制，很多人会叫它功能权限、操作权限、按钮级权限，本质上就是解决“某个登录用户能不能执行某个具体操作”的问题。它和菜单级权限最大的区别在于粒度：菜单级只管到“你能进哪个页面”，功能级要管到“你能在这个页面里按哪个按钮、调哪个接口、执行哪个动作”。

1.2 功能级访问控制的定义与核心诉求

先说清楚功能级访问控制到底在控制什么。以订单模块为例，常见的功能点包括：查看订单、新增订单、编辑订单、删除订单、导出订单、作废订单、审核订单。这七个动作就是七个功能点，每个功能点对应一个或者多个后端接口。

功能级访问控制要做的事，就是为每一个功能点建立明确的授权规则。某个用户拥有“订单导出”权限，他才能调用导出接口；没有这个权限，接口直接拒绝，返回403或者其他约定的错误码。前端按钮隐藏不隐藏是体验问题，后端接口拦截不拦截才是安全问题。这句话我希望所有PHP开发者都记住：前端隐藏按钮只算UI优化，后端校验权限才算真正的访问控制。

核心诉求拆开看有三层。第一层是拦截能力，系统必须能在请求到达业务逻辑之前，对用户身份和权限做一次判定，无权请求直接挡在外面。第二层是配置能力，管理员能够通过后台界面给角色分配或回收权限，而不需要改代码、发布版本。第三层是审计能力，每次权限拦截失败都应该被记录，方便安全事故追溯和权限配置纠错。

1.3 功能级访问控制在认证与授权体系中的位置

很多初学者会把“登录”和“权限”混为一谈，我见过不少项目，代码里到处是if ($user) { 放行 }这种写法，以为用户登录了就能操作一切。这是一个非常危险的误解。

认证（Authentication）解决的是“你是谁”，授权（Authorization）解决的是“你能做什么”。功能级访问控制属于授权层面的工作，它依赖认证的结果——也就是当前登录用户的身份信息——但它和认证是两套完全不同的机制。

一个完整的权限链路通常是这样的：请求进来，先做会话校验，拿到当前用户；然后做角色解析，拿到用户拥有的角色集合；再做权限匹配，判断角色是否被授予了当前功能点的权限；最后决定放行还是拒绝。功能级访问控制就落在第三环。如果这一环缺失，整个授权链路就没闭合，无论前面会话做得多么健壮，对内部功能来说都等于没有锁。

2. 功能级访问控制缺失的典型症状与根因分析

2.1 典型症状表现：症状清单与危险信号

功能级访问控制缺失的系统，表面上看起来一切正常，但症状其实藏在细节里。我把实际项目里反复踩到的几类表现整理成了一份清单，你可以对着自己手里的系统自查。

第一类是接口裸奔。后台管理系统的接口没有统一鉴权中间件，任何一个登录用户都能通过拼URL的方式直接访问其他角色的操作接口。比如普通员工知道了一个管理员的接口路径，直接request一下就能执行。这类问题最常见，也最致命。

第二类是按钮假隐藏。前端根据用户角色用v-if把某些按钮隐藏了，看起来是权限控制，实际上后端接口完全没做校验。真实场景里，懂技术的人可以通过浏览器开发者工具直接发起请求，按钮看不见根本不代表接口不存在。隐藏按钮只是让普通用户找不到入口，拦不住恶意调用。

第三类是简单的角色判断写死在代码里。比如每个控制器顶部写一行if ($_SESSION['role'] == 'admin')，然后就把整个控制器都放给管理员用。问题在于角色一多，这种散落的判断非常难维护。新增一个“运营专员”角色时，要翻遍全项目找这些硬编码判断，漏一个就是一个洞。

第四类是权限配置完全依赖数据库手动改。后台没有权限管理界面，管理员要新建角色只能直接操作数据库，改错一个外键或者漏插一条关联记录，轻则权限失效，重则把不该开放的权限发出去。

这四类症状只要中一条，我都建议尽快把功能级访问控制补上。它不一定会立刻出事故，但出事故只是时间问题。尤其是涉及订单、支付、用户数据、财务报表这类敏感操作的模块，权限漏洞等于把金库钥匙挂在门口。

2.2 根因一：把认证当授权，登录就是通行证

顺着症状往深处挖，第一根因往往是对认证和授权的概念混淆。很多业务系统最开始做的时候，登录是唯一的门槛，只要登录了就认为你是内部人员，内部人员默认拥有所有功能权限。这个假设在小团队、小系统里勉强跑得通，但系统一旦扩大，人员分工一复杂，问题立刻暴露。

我见过一个实际案例，某公司内部数据平台，初期只有三个开发人员使用，后台压根没有权限概念。后来公司规模扩大，运营、客服、财务都要用这个平台。产品经理图省事，给所有新入职员工统一开通账号，结果客服人员能看到全公司财务数据。这已经不是技术问题，而是管理问题。技术上的根因就在于最初设计时没有把授权独立出来，导致后续所有补救都是在给地基打补丁。

另外一个概念混淆是“角色”本身。很多系统默认“管理员”就是一个万能角色，只要判断是管理员就放行。但管理员也分业务管理员、运维管理员、审计管理员，不同管理员应该拥有不同功能的操作权。把角色当成一个黑盒，而不去拆解角色背后的功能权限集合，就会陷入权限粒度过粗的困境。

2.3 根因二：权限模型缺失与功能点管理混乱

再往下挖一层，第二个根因是整个项目里没有一套成体系的权限模型。

什么叫权限模型？就是你在设计阶段是否想清楚了“用户—角色—权限”之间的关系，是否梳理过业务系统里到底有哪些功能点，每个功能点的编码、名称、归属模块是什么。

我接触过的不少项目，权限表倒是建了，但表里面存的是菜单ID列表。菜单ID和功能操作混在一起，一个菜单下面挂三四个按钮，按钮权限却没法单独配置。产品的需求是“导出权限只给财务”，开发一看菜单级权限压根不支持，就只能在控制器里加一个临时判断，写死某个用户ID。这种临时判断越积越多，最后整个项目的权限逻辑变成一团乱麻。

功能点管理混乱的另一个表现是权限点编码没有规范。有人用order/export，有人用export_order，还有人直接用中文“导出”作为权限标识。权限点一多，重复、歧义、难以检索。后面做权限分配界面时，管理员根本分不清这些权限点对应什么功能。

所以，功能级访问控制真正难的不是写几行拦截代码，而是设计一套经得起业务演进的权限模型，并且把功能点梳理清楚。没有模型，代码写得再漂亮都是摆设。

3. 如何设计一套可落地的功能级访问控制模型

3.1 从RBAC模型说起：用户、角色、功能点

业界最成熟、落地最广泛的授权模型就是RBAC（基于角色的访问控制），它的核心思想是把“用户”和“权限”解耦，中间插入“角色”这一层。用户不再直接关联权限，而是通过角色间接获得权限。这样设计的好处是，当你需要调整一批用户的权限时，只需要改角色配置，不用逐个用户去操作。

功能级访问控制在RBAC模型里的落地，就是把原来RBAC中抽象的“权限”具体化为功能点。一个角色拥有哪些权限，不再是一句模糊的“管理员拥有全部权限”，而是明确到“管理员角色拥有订单审核、订单导出、订单作废这三个功能点”。

在具体设计上，我习惯把功能点分成两类：一类是基础功能，比如查看列表、查看详情，这类权限通常默认开放给所有登录用户，只需要做简单的登录态校验；另一类是敏感操作，比如删除、导出、审核、转账、作废，这类权限必须显式配置，默认不开放。这个区分非常重要，它决定了权限系数和默认安全策略。

RBAC模型的落地还涉及一个“最小权限原则”。每个角色只应该拥有完成工作所必需的最少功能权限。客服角色只需要订单查看和订单备注功能，就不应该把订单删除和订单导出放进客服角色里。最小权限原则听起来简单，做起来最难，因为业务方总喜欢“先全部给上，后面再说”，但后面基本上不会再回头收紧权限，风险就在这种宽进宽出的过程中累积。

3.2 权限点编码规范与清单维护

功能点管理是整套方案的基石。我强烈建议在项目里建立一份统一的权限点清单，每新增一个接口或者操作，都同步更新这份清单。权限点编码建议用“模块:动作”的格式，比如order:view、order:create、order:delete、user:export、statistics:view。

用冒号分割的好处在于：第一，模块归属清晰，权限点一多不会乱；第二，代码里做通配匹配很方便，比如超级管理员可以配置*:*，某模块管理员可以配置order:*；第三，权限点字符串可以直接用在中间件和注解里，读代码的人一看就知道这个接口需要什么权限。

维护权限点清单时可以建一张表，字段包括权限点编码、权限点名称、所属模块、备注说明。举个例子：

权限点编码	权限点名称	所属模块	备注
order:view	查看订单列表/详情	订单模块	登录用户默认拥有
order:export	导出订单数据	订单模块	敏感操作，需单独授权
order:delete	删除订单	订单模块	敏感操作，需单独授权
user:reset_password	重置用户密码	用户模块	仅管理员角色可用

这张表不仅是开发文档，也是后续权限分配界面的数据来源。我见过有些团队把权限点清单维护在需求文档里，代码和文档脱节，最后代码里加了新接口，文档里却没有记录。更靠谱的做法是把权限点清单作为代码的一部分，用迁移脚本或者配置文件维护，保证新增权限点时强制走版本管理流程。

3.3 核心表结构设计与权限判定逻辑

权限模型的表结构，常规一套是五张表：用户表、角色表、权限表、用户-角色关联表、角色-权限关联表。如果用户和角色是多对多，角色和权限也是多对多，这个结构可以从一而终地支撑中小型业务系统。

设计时有一个小技巧：在权限表里增加一个type字段，区分菜单权限和功能权限。菜单权限用来控制左侧导航栏渲染，功能权限用来控制按钮和接口。两者分开管理，互不干扰。我之前见过很多系统把菜单和操作混在同一张表里，结果做菜单管理时功能点也被带着改，做功能授权时又找不到对应的菜单节点，非常难受。

权限判定逻辑的核心只有一段话：拿到用户角色集合，通过角色集合取到权限点编码集合，再判断目标权限点编码是否在这个集合里。伪代码大概是：

$user = $request->currentUser(); $roleIds = $user->getRoleIds(); $permissionCodes = PermissionCache::getByRoleIds($roleIds); $hasPermission = in_array('order:export', $permissionCodes, true);

这里我特意提到了PermissionCache，因为权限判定是高频操作，几乎每个接口都要做一次权限查询。如果不加缓存，每次请求都要join三四张表查权限，数据库压力会在高并发场景下迅速放大。缓存策略后面专门讲，表结构先按这五张表来设计，简单、清晰、可扩展。

3.4 权限缓存策略设计

权限缓存是整个权限方案里非常容易被忽视、又非常影响体验的一环。权限数据的特征是读多写少：管理员调整角色权限的频率很低，但每个用户每次请求都可能触发权限读取。所以天然适合用缓存来加速。

我常用的策略是两层缓存。第一层是Redis或内存缓存，以角色为粒度，缓存每个角色拥有的权限点编码集合，key格式类似permission:role:{roleId}。第二层是用户维度，缓存用户ID到权限点编码集合的映射，key格式类似permission:user:{userId}，这样单次权限判断不需要先查角色再拼接权限，而是直接读取用户权限集合。

解决的问题在于缓存失效。角色权限一旦被修改，需要主动清理该角色涉及的缓存的用户权限。这个技术点实现时可以做成事件订阅：权限变更后，取出所有持有该角色的用户ID，逐个删除用户权限缓存。如果做了用户权限缓存，管理员调整权限后用户不能立即生效，大概率就是缓存没清理干净。

缓存过期时间也要设置，比如权限缓存加一个24小时的兜底过期，防止极端情况下缓存刷不干净造成权限残留。兜底过期和主动清除双管齐下，既能保证实时性，又能避免缓存雪崩。

4. 四种实现方案：手工判断、中间件、注解标记与策略模式

4.1 方案一：半手工Function Guard，小项目也能快速落地

功能级访问控制的实现，最简单粗暴的方式就是写一个权限判断函数，在每个控制器方法开头手动调用。这个方案我称之为半手工Guard。它适用于没有引入框架中间件机制的老项目，或者只有零星几个敏感接口需要控制的场景。

具体做法是封装一个全局可用的权限判断方法，例如：

function can($permissionCode) { $user = getLoginUser(); if ($user->isSuperAdmin()) { return true; } return in_array($permissionCode, $user->getPermissionCodes(), true); }

然后在需要控制的接口里手动调用：

public function exportOrders() { if (!can('order:export')) { throw new ForbiddenException('无权导出订单'); } // 业务逻辑... }

这个方案好不好？好处是直观、易理解、没有框架耦合，PHP原生项目也能用。坏处是权限判断散落在各个控制器里，如果漏写一行判断，这个接口就裸奔了。人都会犯错，靠程序员自觉来保证安全，本质上是不可靠的。

所以我给这个方案的定位是：小项目、接口少、过渡期可以用，但团队一旦超过三个人、接口超过二十个，就不要再裸奔了。至少也要升级到统一拦截模式。

4.2 方案二：中间件统一拦截，推荐大多数项目采用

中间件模式是我最推荐的一种实现，也是目前主流PHP框架都支持的方式。中间件的核心价值在于把权限判断从业务代码里剥离出来，放到请求处理管道中统一执行。开发者只需要在路由或者控制器上声明当前接口需要的权限点编码，中间件自动完成校验。

用主流PHP框架的中间件语法来描述，大概是这样一个思路：

final class PermissionMiddleware { public function handle($request, $next, $permissionCode) { $user = $request->currentUser(); // 超级管理员直接放行 if ($user->isSuperAdmin()) { return $next($request); } // 权限校验 if (!$user->can($permissionCode)) { logAccessDenied($user, $permissionCode, $request->getUri()); throw new ForbiddenException('当前账号无权执行该操作'); } return $next($request); } }

路由里注册中间件时，中间件参数传权限点编码：

// 伪代码示意 Route::post('/order/export', 'OrderController@export') ->middleware('permission:order:export');

这个方案最核心的优点是拦截逻辑集中化，权限判断不会遗漏。新来的开发写一个新接口，只要按规矩声明权限点，中间件就会自动兜住底层安全。漏加中间件的问题依然可能存在，但概率比手工判断低很多，而且可以通过路由扫描做静态检查，把所有没有权限声明的接口筛选出来。

中间件里还应该加上访问日志，记录用户ID、权限点编码、请求路径、来源IP。这四件套是安全审计的必备信息，出了事故可以直接拉日志追责。

4.3 方案三：注解/声明式权限标记，让权限声明和代码融为一体

在中间件基础上再进一步，是使用注解或属性标记的方式来声明权限。开发者在控制器方法上直接标注需要的权限点编码，框架在启动阶段扫描注解并自动注册中间件。

引用一个PHP8风格的示例：

class OrderController extends Controller { #[RequiresPermission('order:export')] public function export() { // 业务逻辑 } }

注解方案的优势是代码极其直观，看一眼就知道接口的权限要求，也方便IDE插件做静态分析。权限点声明和业务代码放在一起，不怕路由配置丢失。

缺点是注解是某些框架的特有语法，框架升级可能带来兼容问题，而且注解方式的权限和路由配置分离，排查问题时需要先找路由再找控制器，多一跳。对团队来说，如果习惯了框架自带中间件，我不太建议单独为权限引入注解机制，除非项目里已经有成熟的注解路由体系。

4.4 方案四：策略模式与领域驱动的演进方向

项目继续膨胀到多个业务域时，简单的中跨件的权限点字符串会面临维护困难。权限点编码表越来越长，一个操作可能涉及多个权限点，甚至操作本身因为业务状态不同而需要不同的权限判断。这时候就值得引入策略模式和领域驱动设计的思想。

策略模式的做法是把权限判断封装成一个策略对象。每个功能点对应一个策略类，策略类负责判断当前用户在该业务场景下是否具备操作资格。例如订单作废这个操作，除了要检查“订单作废”权限点，还要满足“订单不能是已完成状态”这类业务规则，这种跨权限点和业务状态的复杂判断，单纯靠权限点集合是表达不了的，必须用策略对象来承载。

interface OperationGuard { public function check(User $user, OperationContext $context): void; } final class CancelOrderGuard implements OperationGuard { public function check(User $user, OperationContext $context): void { // 权限点校验 if (!$user->can('order:cancel')) { throw new ForbiddenException('无权作废订单'); } // 业务规则校验 if ($context->order->isCompleted()) { throw new BusinessRuleException('已完成订单不能作废'); } } }

这种方案的代价是类数量会明显增加，需要按照业务模块做好目录组织。适合业务规则复杂、权限判断不再单纯的系统。多数中小项目用不到这个复杂度，但知道这条演进路径是有好处的，至少从中间件升级到策略模式时不会无从下手。

四种方案对比下来，我给出的选择建议是：老项目零改动用方案一，新项目默认方案二，项目复杂起来了演进到方案四，注解方案看框架风格酌情使用。没有银弹，只有匹配当前团队和业务阶段的方案。

5. 实操：中间件方案完整落地实战

5.1 权限点清单模板：把功能点梳理清楚

这一节直接给一套可复用的实操方案。第一步永远是梳理权限点清单，没有清单谈实现都是空谈。

我整理过一套权限点清单模板，你可以直接参考这个格式来维护：

模块	权限点编码	操作名称	默认开放	备注
订单	order:view	查看订单列表	是	登录可见
订单	order:detail	查看订单详情	是	登录可见
订单	order:create	新建订单	否	客服角色可开
订单	order:edit	编辑订单	否	仅运营
订单	order:delete	删除订单	否	高危操作
订单	order:export	导出订单	否	限财务
订单	order:audit	审核订单	否	仅主管
用户	user:reset_password	重置密码	否	仅管理员

清单里的“默认开放”一列我建议用“白名单思维”来填。默认只开放查看类权限，所有写操作、导出操作默认关闭，谁需要谁申请。这个策略在业务侧可能看起来“麻烦”，但从安全角度永远值得。

5.2 核心实现：权限数据查询与中间件编写

权限点清单确定后，开始写代码。代码分两部分：权限数据查询能力，以及中间件拦截能力。

权限数据查询，我封装成用户模型上的一个方法，内部走缓存：

class User { private array $permissionCache = []; public function can(string $permissionCode): bool { // 超级管理员直接拥有全部权限 if ($this->isSuperAdmin()) { return true; } // 用户权限集合只解析一次 if (empty($this->permissionCache)) { $this->permissionCache = $this->resolvePermissions(); } return in_array($permissionCode, $this->permissionCache, true); } private function resolvePermissions(): array { // 先从Redis缓存读取 $cached = Redis::get('permission:user:' . $this->id); if (is_array($cached)) { return $cached; } // 缓存未命中，查询数据库并写回 $roleIds = $this->roles()->pluck('id')->all(); $permissions = Permission::whereHas('roles', function ($query) use ($roleIds) { $query->whereIn('id', $roleIds); })->pluck('code')->all(); Redis::setex('permission:user:' . $this->id, 86400, $permissions); return $permissions; } }

中间件这块，我在4.2节给了核心逻辑，实操时还要补充几个细节：第一，中间件必须放在认证中间件之后执行，确保当前用户已经取到；第二，异常返回要在框架的异常处理里统一转成JSON格式，方便前端处理；第三，判断失败的日志必须记下来，漏了这一步等于没有追溯能力。

路由注册时按功能点声明权限，这步是权限控制真正生效的地方。开发新接口时，应该把声明权限当成和校验参数一样基本的动作来做。我见过很多团队把权限声明当成可有可无的配置项，结果就是中间件拦截逻辑写得再完善，路由上不声明权限点也拦不住任何请求。

5.3 菜单与按钮级权限联动：后端权限如何驱动前端界面

后端权限做完，还要考虑和前端联动的问题。菜单级权限控制在功能级控制前面，它决定了用户登录后台后看到哪些菜单项。功能级控制在菜单之下，决定用户点进菜单后能操作哪些按钮。

我习惯在做菜单接口时直接把权限信息带回给前端。菜单接口返回的不只是菜单名称和路由，还有每个菜单下的按钮权限列表。前端拿到按钮权限列表后，用自定义指令或者条件判断来控制按钮展示。

后端返回示例：

{ "menu": [ { "name": "订单管理", "path": "/order", "permissions": ["order:view", "order:export", "order:delete"] } ] }

前端在渲染“导出”按钮时，检查order:export是否在权限列表里，不在就隐藏。注意，这里的前端隐藏只是用户体验优化，真正的安全拦截完全依赖后端中间件。这层关系的认知必须清楚：前端控制的是“入口可见性”，后端控制的是“操作合法性”。两者配合，功能级访问控制才算完整落地。

按钮权限联动还需要考虑权限点编码在前后端的一致性。我建议把权限点编码统一维护在前端常量文件里，和后端权限点清单保持一致。任何新增权限点都同时更新前后端两处。坚持不了这个纪律的话，权限点编码很快就会发散，前后端对不上，按钮权限会越管越乱。

6. 常见问题与排查技巧实录

6.1 权限修改后不生效：缓存清理与生效策略

权限相关的第一高频问题就是：管理员在后台给某个角色添加了权限，用户刷新页面后依然提示无权操作，过了好一阵子才生效。

这个问题的根源95%是缓存。前面讲到权限缓存用了用户维度和角色维度两层，管理员改的是角色-权限关联表，如果只清除了角色权限缓存，没有同步清除相关用户的权限缓存，用户拿到的就还是旧权限集合。

排查时先确认权限修改接口有没有触发缓存清理逻辑。我的建议是权限变更时做级联清理：先删除对应角色的权限缓存，再查出所有拥有该角色的用户ID，批量删除这些用户的权限缓存。这个操作要放在数据库事务提交之后执行，避免事务回滚但缓存已清的尴尬状态。

如果对实时性要求没那么高，也可以接受5分钟级别的延迟，那就在用户权限缓存的读取时加一个版本号机制。版本号变了，强制刷新权限缓存。我之前在某项目里就是这样做的：系统维护一份全局权限版本号，每次权限变更自动加一，用户每次请求权限时对比版本号，不一致就重新加载权限。这个方案在分布式环境下也很好用。

6.2 超级管理员的特殊通路：放行逻辑别滥用

超级管理员往往是权限系统里最容易出问题的角色。很多实现就是简单地判断一下角色编码等于admin，然后直接放行，代码确实好写，但隐患是：任何一个被误赋予admin角色的人，瞬间拥有系统所有权限，没有任何二次校验。

我建议超级管理员的特殊通路要做两个限制。第一，超级管理员角色设置为系统内置，不允许被分配给普通用户，而且数量极少；第二，超级管理员放行的同时也要记录操作日志，尤其是高危操作，比如删除数据、导出数据、修改他人密码。放行是权限设计的一部分，但不能成为事故追溯的盲区。

另外，很多项目的admin角色是通过数据库直接改出来的，一个不留神就把普通用户的角色字段改成了admin。所以我还建议在用户角色变更的操作上增加审计日志，记录操作人、变更前角色、变更后角色、变更时间。这几条记录在事故排查时价值极大。

6.3 缓存与权限实时性：如何平衡性能和及时性

权限缓存的实时性和性能永远是一个矛盾。缓存时间设短了，性能优势不明显；缓存时间设长了，权限变了不能及时生效。这个矛盾没有绝对解，只能根据业务场景做取舍。

我的实践建议分两层处理。对于普通功能权限，接受1分钟到5分钟的延迟就够了，不会有人强烈要求权限修改后毫秒级生效，毕竟管理员调整权限的频率本身很低。对于高安全敏感操作，比如支付、退款、删除，可以在请求时强制从数据库刷新一次权限，不走缓存。敏感操作频率低，牺牲一点性能换取绝对实时性是值得的。

缓存击穿也要防一下。极端情况下，某个热门角色下的权限缓存同时过期，大量请求同时穿透到数据库，会造成瞬间数据库压力飙升。处理方式很简单，在缓存读取时加互斥锁，缓存未命中的请求只有一个去查数据库，其余的先等锁。这块代码不多，但防护效果明显。

6.4 多应用与多租户场景：权限维度别硬塞一张表

公司发展到一定规模，后台系统往往不止一套，订单管理、用户管理、财务系统各自独立部署，但又共用一套账号体系。这时候如果每套系统都单独做一套权限模型，账号、角色、权限的数据同步就是噩梦。

共享账号体系下，我建议做一层应用维度的权限隔离。角色不再是一个全局概念，而是归属于某个应用，比如“订单后台”有审核员角色，“财务后台”有会计角色，两者各自管理各自的功能点。权限表里增加应用ID字段，用户在某应用下拥有的角色集合单独计算。

多租户场景更复杂一点，除了应用维度还要加租户维度。租户A的管理员不能操作租户B的数据，即使是同一个应用、同一个权限点，也必须先做租户隔离，再做功能级判断。功能级访问控制在多租户系统里的实施顺序是：先判断租户可见性，再判断功能权限，最后租户内的数据范围过滤。这个顺序绝对不能反，否则就会发生跨租户越权。

我在一个实际项目里就踩过这个坑。当时权限点判断通过了，但用户传了租户ID参数，后端直接用前端传的租户ID去查数据，结果A租户的管理员把请求里的租户ID一改，B租户的订单数据就查出来了。这已经超出了功能级访问控制的范畴，变成了越权漏洞。修起来不复杂，但暴露出的问题值得深思：权限控制从来不是单一维度的，功能级访问控制是其中最关键的一环，但不是全部。

7. 一点个人体会

整套方案梳理下来，我最大的体会是功能级访问控制的技术门槛其实不高，难的是把它当成一件正经事来对待。

很多PHP项目在早期阶段，权限都是“先跑起来再说”的态度。等到数据泄露事故出了、监管罚单下了、客户投诉来了，才匆忙补权限。可那时候业务代码已经铺开，路由已经写死，老板只给你一周时间，你会发现补权限比重新设计一套还要痛苦。与其到时候崩溃，不如每天加班一小时，从今天就开始把权限模型建起来。

另外一个体会是，权限系统做得好不好，最终看的是团队纪律。中间件写得再优雅，新接口不声明权限点也是白搭；权限点清单整理得再全，业务开发时顺手加接口不加清单，也会慢慢失守。我后来养成了一个习惯：代码评审专门盯权限声明，凡是新增或者改动的接口，必须能说清楚它需要哪些功能权限。这个习惯救过我好几次，你也值得试一试。

最后分享一个我个人的实现偏好：我在所有需要权限判定的地方，都会顺手写一条访问日志，哪怕只是简单的permission_denied级别。你可能会说这会影响性能，但实际打点成本极低，真到排查问题时，你才会庆幸当时记了这几行。功能级访问控制的最后一公里，不是代码写得多漂亮，而是出问题时你能快速定位、快速止血、快速追溯。