本地生活平台搭建扩多业务时若每模块独立后台登录运营要记多套 URL 与账号。架构上宜统一身份与单点入口业务按 scope 授权可见菜单——不写岗位 RBAC 模型只谈同一登录能否看到多业务订单与导出。结论统一 admin 入口 biz scopeadmin_user - session menu filter(all_modules, user.enabled_biz) orders query(biz_type in user.scopes)登录与会话defadmin_login(username,password):userauth.verify(username,password)sessioncreate_session(user.id,scopesuser.biz_scopes)returnsession菜单过滤defvisible_modules(session):return[mforminALL_MODULESifm.codeinsession.scopes]订单查询deflist_orders(session,biz_typeNone,page1):types[biz_type]ifbiz_typeelsesession.scopesreturnorder_repo.query(biz_typestypes,pagepage)验收同一账号可见已开通业务菜单未开通业务不可见且 API 403导出 respect scope。光合同城边界光合同城统一后台管理多模块交付验收写清登录入口与业务 scope私有化源码交付。小结本地生活平台搭建多业务共用一套后台登录靠统一会话与 biz scope少切换、少重录。导出 API 与 scopedefexport_orders(session,start,end):typessession.scopesreturnsettlement_repo.export(biz_typestypes,startstart,endend)未授权biz_type即使猜到 URL 也 403审计 log 记录导出人、范围、行数。与单模块升级首期 scope 仅waimai合约升级后session.scopes.append(paotui)不必新发账号体系。菜单随 scope 变订单库不分。会话刷新scope 变更后旧 session 宜强制刷新或 re-login避免缓存菜单与授权不一致。安全边界本文不写岗位 RBAC 细模型只描述同一登录多业务 scope 的架构边界与产品口径一致。压测多 scope 下列表 API 带biz_type in (...)索引避免全表扫。光合同城统一后台、多模块 scope、私有化交付商务规则由客户确定。小结本地生活平台搭建多业务共用一套后台登录scope 驱动菜单与导出扩模块不重造账号体系。SSO 与外部 IdP可选若客户已有 IdP宜映射到同一admin_user.idscope 仍本地配置勿为 SSO 再建平行订单库。审计defexport_orders(...):audit.log(usersession.user_id,scopessession.scopes,rowslen(data))returndata列表性能(biz_type, created_at)复合索引分页强制limit上限防一次导出拖库。小结补述本地生活平台搭建一套登录多 scope是扩模块的最低成本路径并行多套 admin 是技术债不是「灵活」。迁移旧系统账号若客户从旧单模块系统迁移宜做legacy_user_id映射表合并到同一admin_user而不是为新模块新建平行账号。迁移脚本跑完后用同一账号登录应能看到授权范围内全部已开通业务菜单与订单列表避免「新模块像另一套系统」的割裂感。培训与文档交付文档宜含登录 URL、scope 含义、各 biz_type 导出示例、未开通业务隐藏策略。运营新人只看一份文档即可查单培训成本随业务数线性而非指数增长。扩模块要不要重新发账号本地生活平台搭建扩多业务时若每模块独立后台登录运营要记多套地址财务收多套导出格式。统一登录加业务范围可见菜单是扩模块的最低成本路径。首期范围仅外卖合约升级后追加跑腿范围不必新发账号体系菜单随范围变订单库不分。导出接口未授权的业务类型即使猜到地址也应拒绝访问审计记录导出人、范围、行数。范围变更后旧会话宜强制刷新避免缓存菜单与授权不一致。本文只谈同一登录多业务范围的架构边界不写岗位权限细模型。从旧单模块迁移时宜做旧用户标识映射合并到同一管理员账号避免新模块像另一套系统。培训文档宜含登录地址、业务范围含义、各业务类型导出示例。新人只看一份文档即可查单扩第三、第四业务时培训成本线性而非指数增长。