技术调研：商家门店分管账号

1. 账号存储方案

决策

分管账号继续存放在 info_user，使用新的 user_type=5 表示“商家分管账号”，并通过 merchant_owner_id 关联唯一的商家主账号。

依据

商家端登录、JWT、Redis 会话、CID、语言和消息归属都以 InfoUser.userId 为中心，复用 info_user 可以保持现有认证与推送链路。
平台商家页固定传 userType=1，Mapper 使用 user_type = #{userType}；类型 5 天然不会进入商家列表、导出和商家数量统计。
user_type=4 已用于摊位商家，不能复用。

否决方案

分管账号仍使用 user_type=1，另加角色字段：所有按 user_type=1 统计、审核和导出的查询都必须额外排除分管账号，漏改一个入口就会污染平台商家管理。
单独建立完整账号表：需要复制登录、Token、CID、语言和消息体系，认证链路复杂且容易产生两套用户主键。

2. 双重停用状态

决策

复用 info_user.status 作为平台控制状态：0=正常、1=平台停用。
新增 subaccount_status 作为主账号控制状态：0=启用、1=主账号停用，只对类型 5 生效。
分管账号可用条件为：自身未删除、平台状态正常、主账号控制状态正常、所属主账号未删除且平台状态正常。

原因

如果主账号和平台共用一个可写状态，主账号可以重新启用平台强制停用的账号。两个状态必须独立，并由不同接口控制。

3. 店铺授权模型

决策

新增 merchant_subaccount_store 多对多关联表。授权保存时同时校验：分管账号的 merchant_owner_id 等于 pos_store.user_id。

原因

一个分管账号可负责多个店铺，一个店铺也可配置多个分管账号；JSON、逗号字符串或 info_user.store_id 都不能可靠表达该关系。

4. 权限校验边界

决策

在 ruoyi-system 建立统一的 MerchantStoreAccessService，每次业务请求从数据库读取当前账号和目标数据的真实门店归属：

主账号可访问 pos_store.user_id = 当前账号 的全部门店。
分管账号只可访问关联表中的有效门店。
订单以 pos_order.md_id、商品以 pos_food.md_id、分类和规格以其实际关联商品或门店为准。
新增店铺、分管账号管理、支付配置、结算和提现必须调用 requireOwner。

不把店铺集合写入 Token，也不依赖前端传入的主账号 ID，因此撤销授权后下一次请求立即生效。

5. 平台呈现

决策

不新增顶级“商家”行或独立商家审核流程。在平台 sjuser.vue 的主商家操作区增加“分管账号”入口，以对话框/抽屉展示该主账号的下属账号。

平台可以修改 info_user.status 以强制停用或恢复，但不能修改 subaccount_status、密码或店铺授权。

6. 在线状态与通知资格

决策

平台“在线”状态：Redis 中存在该账号的商家 App 或 PC 有效会话。
外部推送资格：账号满足全部启用条件、拥有目标店铺授权、存在商家 App 有效会话且 CID 非空。
任一可接收分管账号存在时，消息分别归属这些账号，主账号不重复接收。
没有可接收分管账号时，消息归属主账号并尝试主账号推送。
外部推送按 CID 去重；站内消息仍按账号分别入库。

商家登录成功时更新 last_login_at。停用账号时删除其商家 App/PC Redis 会话；分管账号的每次业务请求仍重新检查数据库状态，不能只依赖会话存在。

7. 现有代码风险与兼容措施

InfoUserController.shanglodeing 当前允许类型 1、3、4，且没有校验 status。实现时加入类型 5，并在签发 Token 前统一执行账号可用性检查。
PosStoreController.addmendian、PosFoodController.setposfood 等有效商家端写入口存在未声明 token 或信任请求体归属字段的情况。实现时按 Controller 规范补充 @RequestHeader String token，并从 Token 解析操作者。
平台商家列表、导出、统计仍使用 user_type=1，新增回归测试证明类型 5 不会出现或计数。
user_type=4 的摊位逻辑、类型 3 的夜市逻辑保持不变；不能把分管账号塞入现有单店 store_id 规则。
当前工作区已有订单状态和推送调整，实施时必须在其基础上接入通知路由，不能覆盖或回退这些未提交改动。

8. 安全要求

新接口使用明确 DTO 和 @RequestBody，App token 使用 @RequestHeader，不使用 Map 接收请求。
手机号、名称、密码和店铺 ID 集合在 Controller/Service 中显式校验；错误使用现有国际化机制。
密码沿用现有商家端 RSA 传输与存储兼容方式，禁止记录明文、密文或 Token。
所有 Mapper 使用参数绑定，不拼接用户输入 SQL。
批量授权在事务内完成；任一店铺越权时整体回滚。
通过实体真实归属校验订单、商品和退款，防止 IDOR（越权直接对象访问）。

research.md 5.1 KB Permalink History Raw