从“一家店”到“百店同台”：多商户入驻的管理挑战

当平易客外卖系统从服务单一品牌扩展为支持多商户入驻时，一个核心问题浮出水面：如何让上百家商户、骑手、平台运营方在同一个微信外卖订餐小程序中高效协作，却互不干扰？传统模式下，权限管理不过是“管理员”与“用户”的二元对立；但在多商户场景中，每个商户老板都希望拥有独立的菜单、订单、财务后台，同时又要遵循平台统一规则。这种复杂的权限需求，若用简单的角色划分硬撑，最终只会导致数据泄露或操作混乱。

深挖根源：为什么权限管理成为多商户系统的“七寸”？

问题本质在于数据隔离粒度不够细。我见过不少系统，商户A的客服人员误操作修改了商户B的商品库存，原因就是权限模型只区分了“商户管理员”和“商户员工”，却没有在跑腿系统中为不同商户的“员工”打上数据标签。更隐蔽的是，当平台推出跨商户营销活动（如满减券共享）时，权限边界瞬间模糊——既要允许活动数据在一定范围内可见，又要防止商户窥探彼此的定价策略。这迫使平易客团队在底层权限引擎中，引入了基于“租户-角色-资源”的三层动态模型。

技术拆解：平易客的“三权分立”权限架构

在平易客外卖系统的代码层面，我们放弃了传统RBAC（基于角色的访问控制）的静态绑定，转而采用ABAC（基于属性的访问控制）配合动态策略引擎。具体来说：

• 租户级隔离：每个入驻商户拥有独立的数据空间，哪怕是同一张数据库表，也通过“tenant_id”字段物理隔离。商户A的订单详情页，绝不会因为URL参数错误而渲染出商户B的数据。
• 角色粒度细化：不再只有“老板”和“员工”两种角色。针对微信外卖订餐小程序的后台，我们预置了店长、厨房管理员、配送调度员、客服专员等8种基础角色，每种角色默认绑定30余项操作权限。比如“厨房管理员”只能查看待出餐订单，无权修改商品价格。
• 操作级审计：所有权限操作（如修改店铺营业时间、提现）都会被记录到不可篡改的审计日志中。一旦出现纠纷，平台方可以精确追溯到具体操作人和操作时间。

注意，这里有一个容易被忽视的设计：权限的“继承”与“覆盖”机制。例如，平台可以统一禁止所有商户在凌晨1点-6点修改商品信息（防止恶意刷单），但商户老板可以针对其“客服专员”角色单独开放“查看历史订单”权限——这就是属性级别的动态覆盖。

对比分析：为什么传统方案在跑腿场景中失灵？

拿市面上一些开源跑腿系统来对比，它们大多采用“菜单级权限”——只控制某个用户能否看到“订单管理”这个菜单项。但在实际运营中，这种粗粒度带来灾难：外卖骑手登录后，理论上只能看到自己接的订单，但如果系统只隐藏了菜单，而通过API接口强行调用，仍能获取全平台订单列表（因为后端未做数据级过滤）。平易客的做法是在API网关层植入数据范围过滤器，当骑手调用“获取订单列表”接口时，网关自动附加“WHERE assign_driver_id = 当前用户ID”条件。这一层过滤，比任何前端菜单隐藏都安全。

给你的实操建议：部署权限体系时的四个关键落点

1. 优先实现“最小权限”默认配置：新入驻商户的管理员账号，默认只拥有查看基础数据、修改本店营业时间的权限。提现、删除商品等敏感操作，必须手动二次开启。
2. 预留“临时授权”通道：例如，商户老板可能需要让供应商临时查看库存数据。建议在平易客系统中增加“24小时时效权限”功能，不需要修改角色绑定。
3. 定期审计“僵尸角色”：我曾见过客户系统中有130个从未使用过的自定义角色，它们反而成了安全漏洞。建议每季度清理一次，合并冗余角色。
4. 利用微信生态的天然隔离：在微信外卖订餐小程序端，用户端权限其实很简单（无需登录即可浏览），但后台管理必须绑定微信企业身份，避免密码共享导致越权。

多商户权限管理没有银弹。但平易客通过数据隔离+动态策略+操作审计的三层防护，让每个入驻商家既能感受到“独立运营”的自由，又不脱离平台统一的管控框架。这或许就是专业外卖系统与通用电商系统之间，最本质的分水岭。