小程序多角色权限（员工端和管理端）怎么设计

小程序用户量大了之后，权限就会变成大问题：员工能看老板的数据、店长能改其他店的订单、临时工有离职员工的权限……权限设计是中大型小程序的隐形地基，做不好后期到处漏。 这篇讲清怎么设计才规范。

什么时候要做多角色权限

不是所有小程序都要做复杂权限。出现以下情况建议做：

• 有员工/管理员操作（不只是客户用）。
• 多门店或多部门（数据要隔离）。
• 不同岗位看到的功能不同（财务/运营/客服）。
• 涉及敏感数据（订单/客户/资金）。

简单的小程序（如纯展示或单店主）不用做复杂权限，加个管理员密码即可。

角色体系的典型设计

以连锁零售小程序为例：

角色设计要先理清组织架构，再分配权限。

RBAC 权限模型

RBAC（Role-Based Access Control） 是权限设计的标准模型：

用户 → 角色 → 权限
（张三）→（店长）→（订单查看/修改/删除）

三层权限

三层都要做，缺一不可。

权限配置表

把权限做成可配置（而不是硬编码）：

多端入口方案

方案 A：单小程序多角色

• 客户、员工、管理员都用同一小程序。
• 登录后按角色显示不同界面。
• 优点：开发成本低、用户体验统一。
• 缺点：审核复杂（要说明各角色权限）、界面切换复杂。

方案 B：客户端 + 员工/管理端分开

• 客户用一个公开小程序。
• 员工/管理员用单独小程序（不对外发布）。
• 优点：职责清晰、便于审核、安全。
• 缺点：要维护两套。

方案 C：客户端小程序 + 管理后台 Web

• 客户用小程序。
• 员工/管理员用 Web 后台（PC 端）。
• 优点：管理操作适合 PC、功能丰富。
• 缺点：要做 Web 端。

多数连锁和平台型项目选方案 C——客户端小程序 + PC 后台。

数据权限的实现

数据权限是权限设计的难点：

按组织架构隔离

门店A 的店长 → 只能查 store_id = A 的数据
门店B 的店长 → 只能查 store_id = B 的数据
总部 → 查所有数据

按用户归属隔离

员工张三 → 只能查 owner_id = 张三 的订单
店长李四 → 查本店所有订单

数据权限的实现要点

• 每个查询都要带数据范围条件。
• 后端做权限校验（不能只靠前端隐藏）。
• 数据范围要可配置（按角色 + 部门）。

安全要点

1. 后端权限校验

前端隐藏菜单不等于权限——黑客能直接调接口。所有数据操作后端必须校验权限。

2. 操作日志

敏感操作（删除、改价、提现）要记录日志：

• 谁操作的。
• 什么时候操作的。
• 操作前后数据。

3. 权限变更审计

• 角色权限变更要记录。
• 用户角色变更要审计。
• 防止超管滥用。

4. 弱权限场景

• 临时员工：权限有时效（到期自动收回）。
• 离职员工：及时注销账号。
• 共享账号：尽量避免，要审计。

成本影响

权限设计的复杂度直接影响开发成本：

常见误区

• 不做权限：所有员工都能看所有数据。
• 前端做权限：只在前端隐藏，后端不校验，被接口直接攻击。
• 权限硬编码：改一个权限要改代码，不可维护。
• 忽视数据权限：做了菜单权限但忘了数据权限。
• 离职不注销：离职员工账号继续可用。
• 超管太多：人人都超管，等于没权限。

怎么开始

1. 梳理组织架构（角色 + 层级）。
2. 定义角色权限表（菜单 + 操作 + 数据）。
3. 选多端方案（单小程序 / 分开 / 小程序+Web）。
4. 设计权限框架（RBAC + 可配置）。
5. 实现后端权限校验。
6. 加操作日志和审计。
7. 上线后定期清理无效账号。

广州市汉诺雷斯（HNREIS）做过多角色权限的中大型小程序，能帮你设计规范的 RBAC 权限体系。把你的组织架构和业务场景告诉我们，我们给出方案与报价。