同一套程序管多个站点，用户分组和权限怎么互相隔离

同一套内容系统管多个站点时，用户分组与权限怎么互相隔离？答案是分两层设计：第一层是站点边界，决定一个账号能看见哪几个站点；第二层是分组边界，决定它在这些站点里能做哪类动作。两层混在一起谈，就会出现「只想让外部作者投稿，结果他能改别人的稿子」这类问题。

站点边界先定，再定角色

多站点管理下所有站点共用一套程序与数据库，账号体系也是共用的，因此第一步不是分配权限而是划范围：这个账号归属哪些站点，跨站是否允许登录。做法是按组织而不是按人建范围，例如「品牌站组」含主站与两个活动站，「代理站组」含若干客户站。范围定了之后，角色才有作用对象，否则「运营」这个词在两个站点里含义不同，权限无法核对。

分组要落到能读的页面

用户组与 VIP 分组管的是可访问范围，不是职务名称。把分组写成能被验证的描述才有效：能进后台哪几个菜单、能看哪些栏目的草稿、能发布还是只能提交。下表给出一套常见的分层方式，右侧两列是隔离的关键判据。

分组的判据是可核验的动作集合：让每个分组做一次典型操作，看能不能成功，再让它做一次越界操作，看是否被挡。能验的分组才是隔离，验不了的分组只是命名。

跨站复用一个账号的三种风险

第一种是权限叠加：账号在甲站是编辑、在乙站是管理员，登录后界面按最高权限展示，操作时容易把乙站的习惯带到甲站。第二种是审核链断裂：外部作者提交的内容在单站点里会走内容审核，跨站时若乙站没开同一环节，同一篇稿件在两站的上线结果不同。第三种是回收困难：合作结束后只删掉一个站点的关系，账号仍能进另一个站点。对应做法是高危操作域默认关闭，备份与升级这类全站级动作不分配给日常分组；权限调整按站点逐条记录，定期把不再合作的账号从所有站点里一并回收。

改权限前后的三个动作

改之前先做数据备份，把当前账号与分组关系连同内容一起留一份；改完抽查两件事，一是新分组能否做完分配给它的任务，二是原来能进的人是否被正确挡在外面。删错文档时从回收站恢复，比从备份回档代价小得多，但回收站有保留周期，发现误删要当天处理。

常见问题

问：分组已经按角色拆开了，还需要按站点划范围吗？ 答：需要。角色说明能做什么，范围说明在哪里能做。同一套程序管多站点时，缺了范围这一层，角色权限会对所有站点同时生效。

问：VIP 分组和后台的用户组是一回事吗？ 答：不是同一用途。两者管的是可访问范围，用户组针对后台操作权限，VIP 分组针对前台读者能看到的内容层级，例如付费专栏与非付费内容。设计时分别定义，不要用一套分组同时承担两类判断。

问：外部作者能不能只开放一个站点？ 答：可以，把投稿关系限定在该站点，同时确认这个站点开启了内容审核环节。只给提交不给发布，配合审核才形成完整链路。