跨账号API资源授权与共享的最佳实践有哪些？

你的初始思路方向是合理的：将资源本身和授权逻辑拆分，没有把共享用户列表硬编码到文档集合中，避免了文档表的字段冗余，已经可以满足基础的跨账号共享需求。

• 代码逻辑存在低级错误：权限校验时读取的是res.params.id而非req.params.id，实际运行会出现权限校验永远失败的问题
• 缺少权限分级设计：当前只判断「是否有访问权」，没有预留读/写/管理员等权限位的扩展空间，后续新增操作权限需要重构表结构
• 没有所有者权限兜底逻辑：如果teams集合漏加了文档所有者的权限记录，所有者本人也无法访问自有文档，不符合常规产品逻辑
• 存在冗余数据库查询：两次独立查询（先查权限再查文档）会产生额外IO开销，且对只访问自有资源的用户来说，完全不需要查询teams集合，会拉低这部分占比最高的请求的响应速度
• 权限逻辑与路由耦合：每个路由都单独实现权限校验，后续调整权限规则需要修改所有相关路由，极易出现疏漏和逻辑不一致
• 没有缓存机制：高频访问同一资源的场景下，每次都查询数据库会造成不必要的性能浪费

1. 优先采用*RBAC（基于角色的访问控制）*模型设计权限表 #

替换原有teams集合，改用结构化的权限存储，兼顾灵活性和性能：

• docs集合保留owner字段存储所有者用户ID，作为最高权限的兜底判断条件
• 新增doc_permissions集合，核心字段为doc_id、user_id、role（枚举值：reader/editor/owner），每个用户对单文档的权限独立存储；后续需要支持团队授权时，可额外新增team_permissions集合，字段对应doc_id、team_id、role即可
• 权限校验采用MongoDB聚合查询一次完成，避免两次IO，同时对自有资源用户自动走短链路判断：

router.get('/doc/:id', async function(req, res, next) {
  const loggedInUserId = req.session.user.id;
  // 一次聚合查询同时完成文档查询和权限校验
  const doc = await db.docs.aggregate([
    { $match: { _id: req.params.id } },
    {
      $lookup: {
        from: 'doc_permissions',
        let: { docId: '$_id' },
        pipeline: [
          {
            $match: {
              $expr: {
                $and: [
                  { $eq: ['$doc_id', '$$docId'] },
                  { $eq: ['$user_id', loggedInUserId] },
                  // 写操作可修改为匹配editor/owner
                  { $in: ['$role', ['reader', 'editor', 'owner']] }
                ]
              }
            }
          }
        ],
        as: 'permissions'
      }
    },
    {
      $match: {
        $or: [
          // 所有者直接通过，无需权限表记录
          { owner: loggedInUserId },
          // 存在有效权限记录也通过
          { 'permissions.0': { $exists: true } }
        ]
      }
    }
  ]).next();

  if (!doc) {
    return next(new Error('resource not found or access forbidden'));
  }
  delete doc.permissions;
  return res.json(doc);
});

2. 权限逻辑抽离为通用中间件 #

将权限校验逻辑从路由中剥离，封装为可复用的Express中间件，避免逻辑散落在各处：

// 文档权限校验中间件，可传入所需的最低权限角色
const docAuth = (requiredRole = 'reader') => {
  return async (req, res, next) => {
    const loggedInUserId = req.session.user.id;
    const docId = req.params.id;
    // 复用上面的聚合校验逻辑
    const doc = await getDocWithAuthCheck(docId, loggedInUserId, requiredRole);
    if (!doc) {
      return next(new Error('resource not found or access forbidden'));
    }
    // 校验通过的文档挂载到req对象上，后续路由直接使用，无需重复查库
    req.doc = doc;
    next();
  }
}

// 路由使用示例，逻辑大幅简化
router.get('/doc/:id', docAuth('reader'), async (req, res) => {
  res.json(req.doc);
});

router.put('/doc/:id', docAuth('editor'), async (req, res) => {
  // 编辑逻辑直接操作req.doc即可
  const updatedDoc = await db.docs.findByIdAndUpdate(req.doc._id, req.body, { new: true });
  res.json(updatedDoc);
});

3. 针对性性能优化 #

• 给doc_permissions集合创建{doc_id: 1, user_id: 1}联合索引，权限查询的时间复杂度会降到O(1)，几乎不会增加额外开销
• 高频访问场景下可新增Redis缓存，以perm:{userId}:{docId}为key存储用户的权限信息，过期时间设1-5分钟，权限变更时主动删除对应缓存，进一步降低数据库压力
• 针对默认私有、公开资源等特殊场景，可单独做分支判断，跳过不必要的权限表查询

4. 预留扩展能力 #

• 后续要新增团队维度授权时，只需要在聚合查询中新增一层lookup关联团队权限表，判断用户所属团队是否有对应权限即可，现有逻辑无需改动
• 要新增细粒度操作权限（比如仅允许修改文档标题、不允许删除）时，只需要扩展role枚举值或者新增action_permissions字段即可，上层路由逻辑无需调整
• 分页查询文档列表时，可复用相同的聚合逻辑，一次查出用户有权限的所有文档，无需单独做过滤处理

内容的提问来源于stack exchange，提问作者Pardoner