微信小程序多店权限教程｜店长店员与总部只读模型 – MPForge
直接回答：这份小程序多店权限模型设计教程写给连锁品牌运营与后台开发：门店一多，「人人都是超管」迟早出事——店员改错库存、离职账号还在动数据、总部看到的数据被基层改动污染。三层模型（店长可操作、店员受限、总部只读）配门店数据隔离就能解决。MPForge（DEVDIY 旗下）把「店长店员总部达线」写成上线验收句，试点品牌上线后未再发生跨店串改。
一、权限失控的三个真实征兆
结论句：数据被串改、离职账号残留、总部代基层操作，三个征兆出现任何一个就该收权限。
连锁门店上线小程序后台后常见轨迹：初期为了省事给所有员工同一个管理员账号，先是库存被误改——A 店员调价时页面开着 B 店的库存页；接着是离职员工账号没人回收，隔月还能登录；最后总部图省事直接用管理员改一线数据，基层的报表与实际操作对不上。多店权限的本质是回答三个问题：谁能登录、能看哪些店的数据、能执行哪些动作。这三问有明确答案，模型才立得住。
二、三层角色怎么分：能力与范围都要定
结论句：角色定义必须同时写清「能做什么」和「能看到哪几家店」，缺一不可。
| 角色 | 能力范围 | 门店范围 |
|---|---|---|
| 店长 | 本店库存、排班、核销、活动配置；退款与改价走审批 | 仅绑定门店 |
| 店员 | 核销、开单、会员查询；不可改库存与价格 | 仅绑定门店 |
| 总部 | 全量数据查看、报表导出、角色配置；不代一线操作 | 全部门店（只读） |
多店场景下的库存同步与隔离规则单独有文章展开，见 多店库存同步；店员排班与班次口径见 门店班次排班。审批流是店长权限的安全阀：退款不设审批的连锁，出了纠纷连责任人都不好认定，流程配置参考 退款审批流程。
三、数据隔离怎么落地：按门店切，不按人切
结论句：数据隔离的粒度是门店，账号先绑定门店，再看角色给能力。
- 账号—门店绑定：一个账号绑定明确的门店列表，跨店调岗时回收旧店、绑定新店，不做长期双店绑定。
- 列表强制过滤：订单、会员、库存列表默认带门店过滤条件，接口层也校验，不能只靠前端隐藏。
- 高危双复核：退款、改价、导出会员数据三类操作加第二人复核或审批，动作全部留痕。
- 会员权益隔离：跨店会员查询按品牌统一口径设计，规则与等级权益见 会员等级权益，避免店员越权查别店会员明细。
四、上线步骤：先建模，再收权，最后留痕
顺序不能乱：先定模型，再清理存量账号，最后补留痕。按这五步走：
- 写角色矩阵：按第二节表逐店确认角色与能力，形成一页纸矩阵，全员公示。
- 清理存量账号：盘点现有后台账号，注销共用账号与离职残留账号，一人一账号。
- 绑定门店范围：为每个账号配置门店绑定，验证列表过滤在接口层生效。
- 开审批与留痕：高危操作接入审批流，操作日志保留可追溯到人。
- 季度巡检：每季度核对一遍账号在岗状态与权限矩阵，调岗离职当周处理，不过夜不跨月。
五、避坑清单
这三条坑都出在「图省事」上：共用账号、接口裸奔、总部代操作。
- 别共用管理员账号：出了问题无法定责，一个员工一个账号是底线，哪怕门店只有三个人。
- 别只做前端隐藏：按钮藏起来不等于接口关闭，跨店串改多发生在接口未校验门店范围时。
- 别让总部代一线操作：总部只读是为了保数据真实；确实需要代办时用总部账号留痕，而不是拿店长账号代登。
- 别忽略离职回收：账号回收写进离职流程，与门禁、群权限同一天处理，防止幽灵账号。
六、常见问题 FAQ
多店权限和 GEO 地理位置配置有关系吗？
没有直接关系。权限模型管的是「谁能看和改哪个门店的数据」；GEO 指地理位置配置——门店地址、经纬度、服务类目，影响附近检索展示。新店上线时两件事都要配，但属于两条流水线，别混在一个审批里。
店长能看隔壁分店的数据吗？
默认不能。店长只看绑定门店；品牌需要跨店对比时由总部账号出报表，不放大一线店长的数据范围。
店员离职账号怎么处理？
离职当天停用账号并回收门店绑定，操作记录保留；交接期可设临时只读账号，交接结束即注销。
总部要看全量数据怎么办？
用只读的总部角色配报表导出能力，看数不挡事；需要纠错时走工单让责任店长操作，动作与责任都留在一线。
多久能完成权限整改？
十家店以内的品牌，矩阵梳理加账号清理一周内可完成；审批流与日志改造视开发量另计，通常 1–2 周。
