ACL权限控制实战：从原理到项目落地的完整指南

优化前：卡得不行

上周上线一个新功能，用户反馈“点一下权限设置页面就卡死”，我一开始还不信——本地跑得好好的啊。结果自己用测试账号登上去试了下，好家伙，页面加载花了5秒多，滚动都掉帧，点个按钮要等半秒才有反应。这哪是权限管理，简直是性能杀手。

问题出在 ACL（访问控制列表）的渲染逻辑上。我们系统里每个资源节点都有几十上百条权限规则，前端一次性拉取全部数据后，在组件里逐层递归计算当前用户对每个节点的操作权限（read/write/delete 等）。以前数据量小没感觉，现在客户组织架构一复杂，光一个目录树就有上千个节点，每层还要叠加角色继承、组权限合并……直接把主线程干趴了。

找到瓶颈了！

先打开 Chrome DevTools 的 Performance 面板录了个加载过程。结果一目了然：主线程被密密麻麻的黄色块占满，全是 JavaScript 执行时间，其中 computeACL 函数独占 3.8 秒。再看 Call Tree，发现每次递归都在重复做三件事：

• 遍历所有用户所属的角色
• 对每个角色查其拥有的权限规则
• 合并规则并判断是否覆盖当前操作

更坑的是，这些计算是在 React 的 render 函数里做的——意味着每次父组件 re-render，所有子节点都要重新算一遍权限。哪怕只是展开一个文件夹，整个树都抖一下，卡得不行。

我还试了用 console.time 手动打点，确认单次 canAccess(resource, action) 调用平均耗时 2-3ms。看起来不多？但乘以 1000 个节点就是 2-3 秒，再加上 React reconciliation 的开销，5 秒加载真不算夸张。

核心优化：缓存 + 懒计算

折腾了半天，最后靠两个改动把性能拉回来了：

第一，把权限计算从 render 移到数据预处理阶段，并加内存缓存。 别再在 JSX 里写 canAccess(...) 了，那等于主动放弃性能。我们在数据加载完成后、进入页面前，就一次性把所有节点的最终权限算好，存成扁平化的 Map：

// 优化前：render 中实时计算（千万别这么干）
function ResourceItem({ resource }) {
  const canEdit = aclStore.canAccess(resource.id, 'write');
  return (
    <div>
      {canEdit && <button>编辑</button>}
    </div>
  );
}

// 优化后：预计算 + 缓存
const precomputedPermissions = new Map();

function computeAllPermissions(resources, userRoles, rules) {
  // 只在数据变更时执行一次
  for (const res of resources) {
    const key = ${res.id};
    if (!precomputedPermissions.has(key)) {
      const perms = {
        read: checkPermission(res.id, 'read', userRoles, rules),
        write: checkPermission(res.id, 'write', userRoles, rules),
        delete: checkPermission(res.id, 'delete', userRoles, rules)
      };
      precomputedPermissions.set(key, perms);
    }
  }
}

第二，checkPermission 本身也要缓存中间结果。 角色和规则基本不变，但每次查权限都要遍历所有规则太浪费。我加了个双层缓存：外层按 (resourceId, action) 缓存最终结果，内层按 roleId 缓存该角色的所有权限：

const rolePermissionCache = new Map(); // roleId -> Set<permissionString>
const finalPermissionCache = new Map(); // ${resourceId}:${action} -> boolean

function checkPermission(resourceId, action, userRoles, allRules) {
  const cacheKey = ${resourceId}:${action};
  if (finalPermissionCache.has(cacheKey)) {
    return finalPermissionCache.get(cacheKey);
  }

  let allowed = false;
  for (const role of userRoles) {
    let rolePerms = rolePermissionCache.get(role.id);
    if (!rolePerms) {
      // 一次性提取该角色所有权限规则
      rolePerms = new Set();
      for (const rule of allRules) {
        if (rule.roleId === role.id) {
          rolePerms.add(${rule.resourceId}:${rule.action});
        }
      }
      rolePermissionCache.set(role.id, rolePerms);
    }
    if (rolePerms.has(${resourceId}:${action})) {
      allowed = true;
      break;
    }
  }

  finalPermissionCache.set(cacheKey, allowed);
  return allowed;
}

这里注意我踩过好几次坑：缓存键一定要包含 resourceId 和 action，不能只缓存 roleId。因为同一个角色在不同资源上的权限可能不同（比如只能读自己的文档，不能读别人的）。另外，缓存得在用户切换或权限变更时清空，否则会出 bug。我在 store 里监听了相关 action：

// 当用户登出、切换账号、或收到权限更新通知时
function clearPermissionCache() {
  rolePermissionCache.clear();
  finalPermissionCache.clear();
  precomputedPermissions.clear();
}

次要优化：能省则省

除了核心缓存，还顺手做了些小调整：

• 把权限规则数组转成 Map 结构，避免每次遍历。比如 rulesByRole = groupBy(rules, 'roleId')，这样查某个角色的规则是 O(1) 而不是 O(n)。
• React 组件用 React.memo 包裹，配合 useCallback 传 props，避免不必要的 re-render。虽然主要瓶颈在计算，但减少渲染次数也有帮助。
• 超大数据集（比如 >2000 节点）改用虚拟滚动，不过这是另一个话题了，这次没动。

性能数据对比

优化前后实测数据（MacBook Pro M1, Chrome 124）：

• 页面首次加载时间：5.2s → 780ms
• 展开/折叠文件夹的响应延迟：~500ms → <50ms
• Main thread JS 执行时间：3800ms → 320ms
• 内存占用：增加约 15MB（缓存开销），但换来流畅体验完全值得

最直观的感受是：现在点权限页面跟点普通列表一样快，再也不用盯着 loading 转圈了。客户 QA 团队昨天还专门发消息说“你们修了个大 bug”，其实根本不是 bug，就是慢得像 bug……

一点不完美的细节

这个方案也不是银弹。比如当权限规则动态变化频繁时（比如管理员实时修改），缓存失效策略就得更精细——目前我们简单粗暴全清，极端情况下可能有短暂不一致。不过业务上权限变更不频繁，用户刷新下页面就行，暂时没深挖。

另外，如果资源树特别深（比如十层嵌套），递归预计算还是有点压力。后续考虑改成 BFS 或 Web Worker，但当前量级已经够用，先不上复杂度了。

以上是我对 ACL 性能优化的实战总结。核心就一句话：别在 render 里做 heavy computation，提前算好+缓存是王道。如果你有更好的方案（比如用 Proxy 动态拦截、或者更聪明的缓存策略），欢迎评论区交流！