39 KiB
丹阳公益婚恋服务平台
V1.0 运营管理后台与组织权限体系详细设计
版本：V1.0
适用范围：平台管理员、妇联、工会、公益服务中心、公益红娘、审核员、活动管理员、风控员、志愿者
核心目标：统一后台、统一账号、按角色授权、按组织隔离、敏感权限最小化、关键操作可审计
第一章 设计目标
V1.0后台不是单纯的数据管理工具。
它必须同时承担：
- 用户管理
- 资料审核
- 匹配规则管理
- 公益红娘管理
- 活动管理
- 举报风控
- 组织管理
- 工作人员管理
- 权限管理
- 数据统计
- 安全审计
后台设计必须解决以下核心问题：
- 谁可以登录
- 谁可以看到哪些菜单
- 谁可以看到哪些用户
- 谁可以处理哪些任务
- 谁可以查看敏感信息
- 不同组织之间如何隔离
- 多角色人员如何授权
- 工作人员离职如何立即失效
- 重大操作如何审计
- 如何避免“一个管理员什么都能看”
核心原则：
一个后台，一套账号，多角色、多权限、多组织数据范围。
第二章 V1后台总体架构建议
推荐：
公益红娘工作台、运营管理后台、平台管理后台使用同一个响应式Web应用。
通过：
账号
+
角色
+
权限
+
数据范围
决定用户看到什么。
而不是开发三套完全独立后台。
第三章 为什么推荐统一后台
统一后台可以减少：
- 三套登录
- 三套用户体系
- 三套权限代码
- 三套组件
- 三套部署
- 三套维护
技术上统一。
业务上：
不同角色看到不同工作界面。
第四章 后台入口
统一：
/admin
或正式域名：
https://admin.example.com
登录后根据权限进入对应首页。
第五章 Operator统一账号模型
所有工作人员统一：
operators
包括：
- 平台管理员
- 机构管理员
- 审核员
- 公益红娘
- 活动管理员
- 风控员
- 志愿者
不要为红娘、管理员、志愿者分别做独立账号表。
第六章 Operator基本属性
至少包含：
operatorId
name
organizationId
status
roles
permissions
lastLoginAt
第七章 OperatorStatus
建议：
active
disabled
locked
expired
含义：
active
正常。
disabled
人工停用。
locked
安全锁定。
expired
临时账号已到期。
第八章 一个Operator可以拥有多个角色
例如：
某公益服务中心负责人：
organization_admin
+
activity_manager
某工作人员：
matchmaker
+
activity_manager
允许。
但权限最终取：
已授权角色的权限合集 + 数据范围限制。
第九章 角色与权限必须分离
角色：
matchmaker
是一组权限模板。
权限：
matchmaker.service.view
才是真正的操作能力。
不要在代码里写：
if role == matchmaker
决定所有行为。
第十章 V1默认角色
建议：
super_admin
platform_admin
organization_admin
reviewer
matchmaker
activity_manager
risk_operator
volunteer
data_viewer
第十一章 super_admin
定位：
平台最高技术/系统管理权限。
权限包括：
- 系统配置
- 组织管理
- 权限管理
- 高级安全管理
不建议日常运营人员使用此账号。
第十二章 platform_admin
负责平台日常运营。
可管理：
- 用户
- 审核
- 红娘
- 活动
- 风控
- 统计
但是否有：
完整身份证查看
仍应单独授权。
第十三章 organization_admin
负责某一个参与组织。
例如：
- 妇联
- 工会
- 公益服务中心
只能管理：
本组织授权范围内的数据和工作人员。
第十四章 reviewer
负责：
用户资料审核。
可以：
- 查看审核资料
- 领取审核
- 通过
- 退回
- 拒绝
不能：
- 修改平台权限
- 查看聊天
- 任意封禁用户
- 管理其他机构
第十五章 matchmaker
负责：
- 红娘服务
- 查看服务用户必要资料
- 系统候选
- 人工推荐
- 跟进
- 活动推荐
不能：
- 查看身份证
- 查看聊天
- 直接封禁
- 修改匹配算法
- 管理权限
第十六章 activity_manager
负责：
- 创建活动
- 编辑活动
- 报名审核
- 签到管理
- 活动统计
- 现场异常上报
不能：
- 查看聊天
- 查看身份证
- 修改用户匹配关系
- 修改平台权限
第十七章 risk_operator
负责：
- 举报
- 风险事件
- 用户风险分析
- 风控处置
- 申诉处理
根据权限可以：
- 限制
- 暂停
- 封禁
敏感聊天访问：
仍应独立权限控制。
第十八章 volunteer
最低权限角色。
用于：
- 活动签到
- 简单现场辅助
只应看到：
当前活动必要信息。
第十九章 data_viewer
用于：
只读统计。
例如机构负责人只看运营数据。
不能：
- 修改用户
- 审核
- 封禁
- 查看敏感资料
第二十章 权限模型
建议采用：
RBAC
+
Data Scope
+
Sensitive Permission
三层。
第二十一章 第一层：RBAC
决定：
能不能做某类操作。
例如：
activity.create
第二十二章 第二层：Data Scope
决定：
可以对哪些数据做。
例如同样拥有：
activity.view
平台管理员：
全平台。
机构管理员：
本机构。
第二十三章 第三层：Sensitive Permission
决定：
是否允许查看高敏感字段。
例如：
user.sensitive.identity.view
必须单独授权。
第二十四章 数据范围枚举
建议：
platform
organization
assigned
self
activity_scope
第二十五章 platform范围
可以访问：
全平台符合权限的资源。
主要：
- super_admin
- platform_admin
- 特定risk_operator
第二十六章 organization范围
只能访问：
resource.organization_id = operator.organization_id
第二十七章 assigned范围
只访问：
明确分配给自己的任务。
例如红娘：
service.assigned_operator_id = currentOperator
第二十八章 self范围
只管理：
自己账号相关数据。
第二十九章 activity_scope
用于临时工作人员。
例如：
志愿者账号只允许：
activity_id IN operator_activity_assignments
第三十章 Data Scope不能靠前端实现
错误：
前端不显示其他组织。
正确：
服务端SQL/Service就必须加范围。
否则用户手工改URL仍可能访问。
第三十一章 组织模型
组织表：
organizations
类型：
platform
women_federation
trade_union
charity_center
volunteer_team
civil_affairs_partner
other
第三十二章 组织层级
V1建议：
最多支持简单父子组织。
例如：
平台运营主体
│
├── 妇联
├── 工会
└── 公益服务中心
不建设复杂无限级政府组织树。
第三十三章 organization字段建议
id
parent_id
name
type
status
contact
created_at
第三十四章 OrganizationStatus
active
disabled
disabled后：
- 组织人员不能继续新业务
- 现有服务进入转交
- 数据不删除
第三十五章 跨组织用户数据问题
用户属于：
平台用户。
而不是天然属于某个妇联/工会。
因此：
不建议给User加唯一organization_owner。
第三十六章 组织和用户的关系
应该通过：
- MatchmakerService
- ActivityRegistration
- ReviewTask分配
- Organization授权
建立业务关系。
而不是：
user.organization_id
直接把用户“归属”某组织。
第三十七章 为什么用户不应归属组织
一个用户可能：
- 参加工会活动
- 接受公益服务中心红娘帮助
- 被平台统一审核
因此用户是：
平台主体数据。
组织只有：
特定服务访问权。
第三十八章 后台一级菜单
统一建议：
工作台
用户管理
资料审核
匹配管理
公益红娘
活动管理
举报风控
数据统计
组织人员
权限管理
系统设置
审计日志
第三十九章 菜单动态生成
根据：
currentOperator.permissions
动态显示。
没有：
risk.report.view
就不显示：
举报风控。
第四十章 工作台按角色变化
同一个：
/dashboard
根据角色显示不同卡片。
第四十一章 Reviewer工作台
显示：
待审核
已领取
今日已完成
退回待复审
第四十二章 Matchmaker工作台
显示：
新服务
待首次处理
今日待跟进
等待用户
服务中
第四十三章 Activity Manager工作台
显示：
报名中活动
待审核报名
今日活动
待签到
近期活动
第四十四章 Risk Operator工作台
显示：
高风险举报
待处理举报
风险用户
待处理申诉
第四十五章 Platform Admin工作台
显示：
待审核资料
待处理举报
红娘待分配
活动报名待审核
异常账号
不做炫酷大屏。
第四十六章 用户管理模块权限
建议：
user.list.view
user.detail.view
user.status.change
user.sensitive.view
user.relationship.summary.view
user.activity.summary.view
user.matchmaker.summary.view
第四十七章 用户列表默认字段
显示：
用户ID
展示名
性别
年龄
区域
实名认证
资料审核
婚恋状态
账号状态
注册时间
不显示：
- 完整手机号
- 身份证
- 聊天
- 举报详情
第四十八章 用户列表搜索
支持：
用户ID
展示名
脱敏手机号/授权手机号搜索
手机号搜索：
仅授权人员。
第四十九章 用户详情Tab
建议：
基础信息
婚恋资料
审核记录
匹配摘要
活动摘要
红娘服务
账号状态
风险信息：
有权限才出现。
第五十章 用户详情不展示完整聊天
明确禁止普通用户管理页面加：
聊天记录Tab。
聊天只能在风控案件场景下按权限访问。
第五十一章 敏感身份入口
独立：
查看实名信息
点击：
权限校验 + 访问原因 + 审计。
第五十二章 默认脱敏
显示：
姓名：张**
身份证：320***********1234
手机号：138****1234
第五十三章 查看完整身份
只有：
user.sensitive.identity.full
权限允许。
V1建议极少授权。
第五十四章 资料审核菜单
权限：
review.list.view
review.claim
review.process
review.reject
review.history.view
第五十五章 Reviewer只能处理审核
不能因为能看审核页：
就拥有user.status.change。
第五十六章 审核任务数据范围
平台统一审核时：
platform
如果未来机构自行审核：
可以按：
assigned / organization
控制。
V1建议核心实名资料审核由平台统一标准管理。
第五十七章 匹配管理菜单
权限：
match.stats.view
match.list.view
match.rule.view
match.rule.manage
match.rule.activate
第五十八章 普通管理员不需要看所有用户匹配详情
匹配详情属于较高隐私业务数据。
默认后台重点看：
- 聚合统计
- 规则
- 异常
不是：
谁喜欢了谁的全部流水。
第五十九章 查看特定Match
只在：
- 用户投诉
- 风控
- 服务处理
等必要场景开放。
第六十章 Match Rule权限
只有少数平台角色：
match.rule.manage
可以修改。
机构管理员不能修改全局算法。
第六十一章 公益红娘模块权限
matchmaker.service.list
matchmaker.service.view
matchmaker.service.assign
matchmaker.service.claim
matchmaker.service.followup
matchmaker.candidate.view
matchmaker.recommend
matchmaker.service.complete
第六十二章 红娘管理员
organization_admin若负责红娘：
可以：
- 看本机构服务
- 分配本机构红娘
- 看工作量
不能：
看其他机构服务。
第六十三章 活动管理权限
activity.list
activity.view
activity.create
activity.edit
activity.publish
activity.cancel
activity.registration.view
activity.registration.review
activity.checkin
activity.feedback.view
activity.stats.view
第六十四章 发布和编辑分离
可以允许工作人员：
创建活动草稿。
但只有负责人：
activity.publish
可以正式发布。
降低误操作风险。
第六十五章 取消活动属于高风险权限
activity.cancel
必须：
- 二次确认
- 原因
- 审计
第六十六章 志愿者只给
activity.checkin
和必要：
activity.registration.basic_view
即可。
第六十七章 举报风控权限
建议细拆：
risk.report.list
risk.report.view
risk.report.process
risk.user.view
risk.user.warning
risk.user.limit
risk.user.suspend
risk.user.ban
risk.appeal.view
risk.appeal.process
risk.evidence.view
message.content.review
第六十八章 为什么风控要细拆
“查看举报”和“永久封禁”不是一个风险等级。
例如初级风控员：
可以：
- 查看
- 处理普通举报
但不一定拥有：
ban。
第六十九章 用户封禁建议双重保护
V1建议：
永久ban操作：
- 二次确认
- 填写原因
- Audit
是否需要双人复核：
初期可作为P1建议。
严重高风险时至少由高权限角色操作。
第七十章 聊天查看权限单独存在
message.content.review
不能因为：
risk.report.process
就自动获得全部聊天读取。
第七十一章 风控聊天读取必须案件关联
正确：
Report
↓
Conversation Context
错误：
用户详情
↓
所有聊天
第七十二章 组织人员菜单
权限：
organization.list
organization.view
organization.create
organization.edit
operator.list
operator.create
operator.edit
operator.disable
operator.role.assign
第七十三章 organization_admin人员权限
只能管理：
operators.organization_id = currentOrg
不能新增平台管理员。
第七十四章 机构管理员不能给自己越权
例如本机构最大允许：
matchmaker
activity_manager
volunteer
机构管理员不能通过角色接口：
给自己super_admin。
服务端需要：
Role Assignment Boundary。
第七十五章 角色分配边界
每个管理角色定义：
assignable_roles
例如：
organization_admin可分配：
matchmaker
activity_manager
volunteer
data_viewer
不能分：
platform_admin
super_admin
第七十六章 权限管理菜单
只对：
permission.manage
开放。
建议V1只有：
- super_admin
- 指定platform_admin
拥有。
第七十七章 系统角色
默认角色：
system_role = true
不允许删除。
可以：
克隆后创建自定义角色。
第七十八章 自定义角色
例如：
工会活动负责人
可以从：
activity_manager
复制后精简权限。
第七十九章 不建议V1做复杂ABAC
不要建设：
- 表达式权限引擎
- 策略语言
- 动态属性规则系统
RBAC + 数据范围足够。
第八十章 权限命名规范
统一：
module.resource.action
例如：
user.detail.view
activity.registration.review
risk.user.ban
match.rule.manage
第八十一章 权限不能按按钮命名
错误：
button_123
正确：
表达业务能力。
第八十二章 权限后端统一注解/中间件
例如：
@RequirePermission("activity.publish")
或框架对应机制。
避免Controller手写大量：
if role...
第八十三章 数据范围服务
建议独立：
DataScopeService
输入：
operator
resourceType
输出可访问条件。
第八十四章 示例：红娘服务查询
红娘：
assigned_operator_id = me
机构管理员：
organization_id = myOrg
平台管理员：
无组织限制。
第八十五章 示例：活动列表
志愿者：
只看被分配活动。
活动管理员：
本组织活动。
平台管理员：
全部。
第八十六章 用户数据访问不能简单按机构过滤
再次强调：
用户是平台用户。
机构只能通过：
具体服务关系
获取必要资料。
第八十七章 OrganizationAccessGrant建议
为未来跨组织协作，可预留：
organization_access_grants
但V1如果业务简单：
暂不必建复杂授权表。
先通过业务对象关联授权。
第八十八章 用户与红娘的数据范围
红娘可看用户完整Matchmaker DTO的前提：
存在有效service
AND
service.assigned_operator = currentOperator
第八十九章 用户与活动管理员的数据范围
活动管理员可看报名必要资料的前提：
user registered activity
AND
activity belongs to currentOrg / authorized
第九十章 用户与审核员的数据范围
审核员可以看：
当前审核任务必要资料。
不能因此浏览用户全部红娘、活动、聊天历史。
第九十一章 用户与风控员的数据范围
风控员基于：
- Report
- RiskEvent
- Appeal
访问必要资料。
第九十二章 Data Minimization必须在后台体现
不是只有用户端隐私。
后台也应做到：
每个角色只看完成任务所需要的信息。
第九十三章 后台顶部Header
显示：
当前组织
当前用户
通知
退出
不需要：
- 天气
- 时间大屏
- 欢迎词大Banner
第九十四章 Sidebar
宽度：
220～240px
折叠：
可选。
桌面V1优先1280+。
第九十五章 后台页面统一结构
PageHeader
↓
FilterBar
↓
Content
↓
Pagination
第九十六章 表格原则
默认：
20条/页
可选择：
20
50
100可作为技术支持但不必前台突出。
该分页属于UX配置，不是业务硬规则。
第九十七章 表格操作
每行最多：
查看
处理
更多
不要一行放8个按钮。
第九十八章 高风险按钮
例如：
封禁
取消活动
停用工作人员
放：
更多
或详情页。
并二次确认。
第九十九章 后台状态色
统一使用：
- 正常：绿色
- 待处理：橙色
- 风险：红色
- 普通：蓝/灰
不能所有异常都一片大红。
第一百章 数据统计模块权限
analytics.overview.view
analytics.user.view
analytics.match.view
analytics.activity.view
analytics.matchmaker.view
analytics.risk.view
第一百零一章 机构统计范围
机构管理员只能看：
本机构参与产生的运营数据。
例如：
- 本机构活动
- 本机构红娘服务
不能看全平台完整用户数据。
第一百零二章 平台统计
platform_admin可看：
- 用户
- 匹配
- 活动
- 红娘
- 风控
全平台汇总。
第一百零三章 数据导出权限
建议：
data.export
单独权限。
不要：
能看列表就能导出。
第一百零四章 为什么导出单独授权
Web页面：
有访问控制。
Excel下载后：
很难继续控制传播。
因此导出风险更高。
第一百零五章 V1限制导出范围
优先支持：
- 活动执行脱敏名单
- 必要运营统计
不提供：
全量用户数据库导出。
第一百零六章 导出内容必须脱敏
例如活动：
活动编号
展示名
手机号后四位
报名状态
签到状态
第一百零七章 导出审计
记录：
operator
export_type
filters
row_count
time
敏感导出建议：
水印。
第一百零八章 Audit模块菜单
权限：
audit.view
audit.sensitive.view
audit.export
第一百零九章 普通管理员是否看Audit
可以看：
自己组织的普通操作日志。
高敏感日志：
平台安全角色。
第一百一十章 Audit记录操作
至少：
登录
审核
用户状态修改
红娘分配
活动发布/取消
举报处理
风控处置
权限变更
工作人员创建/停用
敏感数据访问
系统配置修改
第一百一十一章 Audit不可由普通后台删除
审计日志：
不提供删除按钮。
第一百一十二章 SensitiveAccessLog
与普通Audit分开。
记录：
谁
查看谁
什么敏感数据
为什么
什么时候
第一百一十三章 敏感访问理由
可使用标准：
身份异常核验
举报调查
申诉处理
依法配合
其他
其他需要填写说明。
第一百一十四章 工作人员登录安全
V1至少：
账号+密码
强密码
登录限频
失败锁定
Session超时
停用实时失效
第一百一十五章 MFA
建议优先给：
super_admin
platform_admin
risk_operator（高权限）
启用。
如果V1研发周期紧：
P1。
但架构预留。
第一百一十六章 Session有效期
工作人员后台建议：
比普通小程序更严格。
例如：
空闲一定时间重新认证
具体时长待安全配置确定。
不要在业务代码写死。
第一百一十七章 高敏感操作再认证
P1可考虑：
查看完整身份证 / 修改权限 / 永久封禁
要求再次输入密码或MFA。
第一百一十八章 临时志愿者账号
支持：
expires_at
活动结束后：
自动expired。
第一百一十九章 离职流程
工作人员离职：
operator.status = disabled
↓
撤销所有Session
↓
停止API权限
↓
转交服务
↓
审计
第一百二十章 红娘离职服务转交
系统提示：
当前仍有18个未完成服务。
必须先：
- 批量重新分配
- 或管理员接管
不能只停账号。
第一百二十一章 机构人员停用
机构管理员可以停：
本机构普通人员。
不能停：
平台管理员。
第一百二十二章 平台管理员停用机构管理员
平台权限允许。
停用后：
该组织需重新指定负责人。
第一百二十三章 后台通知中心
工作人员通知：
新审核任务
新举报
红娘任务分配
活动报名待审核
用户风险变化
权限/账号安全
第一百二十四章 通知按职责发送
不要：
每个管理员都收到所有消息。
例如：
活动报名：
活动管理员。
举报：
风控员。
审核：
审核员。
第一百二十五章 工作人员个人待办
建议：
GET /operator/tasks
统一返回：
review
matchmaker
activity
risk
属于自己的待办。
第一百二十六章 是否建设通用工单系统
V1不需要。
各业务有自己的Task实体。
Dashboard统一聚合即可。
第一百二十七章 平台超级管理员红线
即使是super_admin：
也不应该默认在普通页面看全部私人聊天。
技术超级权限：
≠
日常业务合理权限。
第一百二十八章 Break Glass机制建议
未来针对极特殊安全事件，可以有：
紧急访问。
例如高级安全负责人临时访问某敏感数据。
必须：
- 填写原因
- 强审计
- 可复核
V1可先预留理念，不一定做复杂系统。
第一百二十九章 系统设置权限
system.config.view
system.config.manage
可配置：
- 推荐数量
- 活动功能开关
- 红娘功能开关
- 图片上限
- 风控基础配置
第一百三十章 不允许普通运营修改技术Secret
后台系统设置不要暴露：
- 数据库密码
- 微信Secret
- JWT Secret
- 云密钥
这些属于部署Secret。
不是运营配置。
第一百三十一章 Feature Flag
后台可见：
活动服务
红娘服务
图片聊天
等业务开关。
第一百三十二章 系统维护模式
只有高权限人员：
system.maintenance.manage
可开启。
开启：
用户端进入维护页。
必须二次确认。
第一百三十三章 用户账号状态修改
普通后台不能随意：
normal → banned
必须走：
RiskAction。
用户管理页可以提供：
查看状态
但封禁动作进入风控流程。
第一百三十四章 为什么不能User页面直接改状态
这样能保证：
- 有原因
- 有风控记录
- 可申诉
- 可审计
不会出现管理员随手改数据库状态。
第一百三十五章 用户资料人工修改
V1后台原则：
工作人员不直接替用户修改婚恋资料。
审核员只能：
- 通过
- 退回
用户本人修改。
第一百三十六章 特殊代录场景
如果未来服务老年/特殊用户需要工作人员代录：
必须独立：
Assisted Entry流程。
V1普通后台不提供。
第一百三十七章 系统内部用户备注
是否允许管理员随意写“内部备注”？
建议非常谨慎。
只允许业务模块已有：
- 审核备注
- 红娘跟进
- 风控记录
- 活动异常
不要增加一个：
所有人都能写的“用户备注”。
容易形成不当标签。
第一百三十八章 组织权限矩阵概览
| 功能 | 平台管理员 | 机构管理员 | 审核员 | 红娘 | 活动管理员 | 风控员 | 志愿者 |
|---|---|---|---|---|---|---|---|
| 用户基本列表 | 是 | 有限 | 审核相关 | 服务相关 | 报名相关 | 风控相关 | 否 |
| 实名敏感信息 | 单独权限 | 否 | 必要脱敏 | 否 | 否 | 单独权限 | 否 |
| 资料审核 | 可 | 按授权 | 是 | 否 | 否 | 否 | 否 |
| 红娘服务 | 管理 | 本机构 | 否 | 是 | 否 | 必要摘要 | 否 |
| 活动管理 | 管理 | 本机构 | 否 | 推荐活动 | 是 | 必要摘要 | 签到 |
| 举报风控 | 管理 | 默认否 | 否 | 转交 | 转交 | 是 | 转交 |
| 聊天正文 | 默认否 | 否 | 否 | 否 | 否 | 案件授权 | 否 |
| 权限管理 | 指定 | 有限 | 否 | 否 | 否 | 否 | 否 |
| 统计 | 全平台 | 本机构 | 自身工作 | 自身服务 | 本机构活动 | 风控 | 否 |
第一百三十九章 机构管理员的数据范围
核心：
本组织产生/被授权处理的业务。
例如：
本机构活动
本机构红娘服务
本机构工作人员
不自动获得：
全平台婚恋用户库。
第一百四十章 平台管理员的数据范围
平台管理需要全局运营能力。
但敏感字段仍：
单独权限。
第一百四十一章 审核员的数据范围
审核任务。
不是：
全平台自由搜索用户。
第一百四十二章 风控员的数据范围
风险案件。
可以根据案件扩大必要上下文。
但每一步仍遵守：
最小必要。
第一百四十三章 跨机构红娘服务
如果用户申请平台统一红娘服务：
管理员可把Service分配给某合作机构。
此时：
该机构只获得该Service必要的数据访问。
第一百四十四章 Service结束后访问权限
服务完成后：
红娘是否无限期继续查看用户？
建议：
不应。
完成后保留服务历史摘要，但对完整婚恋资料的实时访问应按业务需要收缩。
V1可以先做到：
已完成服务只读。
未来再进一步做访问期限。
第一百四十五章 活动结束后志愿者权限
活动结束：
临时账号过期。
不能继续查看历史报名名单。
第一百四十六章 数据访问期限思想
权限不仅是：
“有没有”。
未来还应考虑：
“什么时候还有”。
V1重点先覆盖临时活动账号。
第一百四十七章 后台列表URL状态
筛选写Query：
/reviews?status=pending&page=2
便于刷新恢复。
第一百四十八章 详情页必须URL可恢复
例如：
/admin/users/{id}
/admin/reviews/{id}
/admin/reports/{id}
刷新后重新请求。
不能靠上一页传对象。
第一百四十九章 后台401
Session过期：
回登录。
如果页面有未保存表单：
优先保存非敏感草稿或提示。
第一百五十章 后台403
显示：
你没有访问该功能的权限。
不要：
白屏。
第一百五十一章 数据范围403
例如机构管理员手改其他组织activityId：
返回：
ORGANIZATION_SCOPE_DENIED
第一百五十二章 敏感权限403
返回：
SENSITIVE_ACCESS_DENIED
第一百五十三章 Operator账号异常
disabled：
当前账号已停用，请联系管理员。
locked：
当前账号因安全原因暂时锁定。
第一百五十四章 机构停用
组织被停用：
其Operator不能继续普通业务。
服务端登录/请求检查：
organization.status
第一百五十五章 组织停用后的在途任务
管理员必须处理：
- 红娘服务转交
- 活动负责人调整
- 未完成工作
不能直接删除组织。
第一百五十六章 组织删除原则
不物理删除已有业务组织。
采用：
disabled
历史Audit和活动仍能关联。
第一百五十七章 角色删除原则
系统角色：
不删除。
自定义角色如果已有人使用：
先解除关联或禁用。
建议roles增加：
status
第一百五十八章 权限变更实时生效
管理员撤销某Operator：
risk.user.ban
下一次请求：
立即不能使用。
不要等重新登录。
第一百五十九章 权限缓存
可以Redis缓存：
operator_permissions:{id}
权限修改后：
立即失效。
第一百六十章 Session与权限分离
Token不建议把全部权限永久写死到长周期JWT中。
否则权限改了：
老Token还有效。
可：
- 短Token
- 权限版本
- Redis Session
确保及时生效。
第一百六十一章 Operator权限版本
可增加：
permission_version
角色变化：
version +1
Token/Session发现版本不一致：
重新加载权限。
第一百六十二章 登录日志
建议：
operator_login_logs
记录：
- operator
- IP
- User Agent
- 成功/失败
- 时间
也可纳入Security Log。
第一百六十三章 异常登录提醒
P1：
如果：
- 新设备
- 异常IP
- 短时间多次失败
提醒管理员或本人。
第一百六十四章 Admin Header当前组织切换
如果某平台工作人员被授权多个组织：
可以：
切换工作上下文。
普通机构人员：
固定组织。
V1如无多组织Operator需求，可暂不做切换。
第一百六十五章 组织切换不能改变实际权限
切换只是：
数据上下文。
不能通过切组织获得未授权范围。
第一百六十六章 后台搜索全局能力
不建议做一个：
全局搜人/手机号/聊天/举报
超级搜索。
风险太高。
各业务模块：
在本模块内搜索。
第一百六十七章 用户搜索手机号
只有特定权限：
user.phone.search
才能使用。
返回结果仍脱敏。
第一百六十八章 身份证搜索
V1原则：
普通后台不提供。
确因实名认证异常需要：
使用Identity模块受控查询。
第一百六十九章 统计匿名化
统计页尽量用：
聚合数据。
不需要显示具体用户。
第一百七十章 小样本隐私
如果某机构某条件只有1人：
后台统计也应避免为了图表直接暴露个体敏感信息。
V1可以先不做过细交叉分析。
第一百七十一章 后台批量操作
V1只谨慎支持：
- 批量活动报名审核（建议后期）
- 批量任务分配
不支持：
批量封禁用户
作为普通功能。
第一百七十二章 批量敏感操作风险
任何批量状态变化：
必须：
- 预览
- 二次确认
- Audit
第一百七十三章 用户封禁不支持普通批量
除非技术攻击场景由安全系统处理。
人工运营不需要：
选100人一键封禁。
第一百七十四章 后台操作Undo
高风险操作不要依赖：
Toast后5秒撤销。
应该通过正式：
- revoke
- appeal
- restore
流程。
第一百七十五章 资料审核支持快捷操作
可以：
通过
需修改
降低工作人员操作量。
严重拒绝：
放“更多”。
第一百七十六章 审核原因标准化
使用：
review_reasons字典。
减少审核员每次自由发挥。
可以补充：
备注。
第一百七十七章 风控原因标准化
同样使用：
resultCode / actionType。
便于统计和复核。
第一百七十八章 权限变更审计样例
例如：
2026-08-28 14:32
管理员：李某
操作：修改张某角色
原角色：matchmaker
新角色：matchmaker + activity_manager
第一百七十九章 敏感访问审计样例
2026-08-28 15:10
操作员：王某
查看：USR-xxx 实名信息
原因：身份异常核验
第一百八十章 后台权限测试矩阵
每个API至少测试：
无Token
普通用户Token
错误Operator角色
正确角色错误组织
正确角色正确组织
敏感权限缺失
账号disabled
第一百八十一章 重点越权测试一
红娘手工请求：
GET /admin/users/{id}/sensitive-identity
结果：
403。
第一百八十二章 重点越权测试二
志愿者请求：
GET /admin/activities/other-activity/registrations
非授权活动：
403。
第一百八十三章 重点越权测试三
机构管理员请求：
其他机构红娘服务。
结果：
ORGANIZATION_SCOPE_DENIED。
第一百八十四章 重点越权测试四
审核员请求：
POST /admin/risk/users/{id}/actions
结果：
PERMISSION_DENIED。
第一百八十五章 重点越权测试五
风控员无：
message.content.review
访问聊天：
403。
第一百八十六章 重点越权测试六
机构管理员给自己分配：
super_admin
必须：
拒绝。
第一百八十七章 重点实时权限测试
管理员把红娘账号disabled。
该红娘即使页面没刷新：
下一次API：
ACCOUNT_DISABLED。
Session失效。
第一百八十八章 后台数据审计验收
必须能回答：
谁审核了这个用户？
谁封禁了这个账号？
谁取消了这场活动？
谁看过这个用户的敏感身份？
谁给这个工作人员加了权限？
如果回答不了：
审计设计不合格。
第一百八十九章 后台UX验收
工作人员登录后5秒内应该知道：
今天有什么需要处理。
审核员不需要在：
用户管理 → 搜索 → 打开 → 找审核
才能工作。
直接：
工作台 → 待审核。
第一百九十章 后台安全UX原则
安全不能完全依赖培训。
界面本身必须减少错误：
- 危险按钮不突出
- 高风险操作二次确认
- 敏感字段默认脱敏
- 无权限入口不显示
- 数据范围自动限制
第一百九十一章 后台P0模块
统一登录
Dashboard
用户管理
资料审核
红娘服务
活动管理
举报风控
组织人员
RBAC
审计
第一百九十二章 P1模块
高级统计
敏感动态水印
MFA
临时活动账号
登录异常提醒
细化数据导出
权限复核
第一百九十三章 P2模块
跨机构高级协同
审批式权限申请
Break Glass
自动权限到期
更高级合规审计
第一百九十四章 推荐后台代码模块
admin/
auth/
dashboard/
users/
reviews/
matches/
matchmaker/
activities/
risk/
analytics/
organizations/
operators/
roles/
permissions/
audit/
configs/
第一百九十五章 后端权限模块建议
OperatorAuthService
PermissionService
RoleService
DataScopeService
OrganizationService
SensitiveAccessService
AuditService
第一百九十六章 权限判断标准流程
请求
↓
Operator认证
↓
账号是否active
↓
Organization是否active
↓
是否拥有permission
↓
DataScope是否允许resource
↓
是否涉及sensitive permission
↓
允许业务Service执行
↓
必要时Audit
第一百九十七章 后台设计最终红线
严禁：
- 所有工作人员共用一个admin账号
- 红娘拥有全部用户资料权限
- 普通管理员能浏览私人聊天
- 志愿者看到身份证
- 机构管理员看到其他机构全部数据
- 前端隐藏按钮代替后端权限
- 可以随意导出全量用户
- 权限修改没有审计
- 离职人员账号继续可用
- 用户封禁可以无原因直接修改数据库状态
第一百九十八章 最终组织模型
平台运营主体
│
┌─────────────┼─────────────┐
│ │ │
妇联 工会 公益服务中心
│ │ │
┌────┴───┐ ┌───┴───┐ ┌───┴────┐
│ │ │ │ │ │
活动管理员 红娘 活动人员 负责人 红娘 志愿者
平台层：
审核员
风控员
平台管理员
具体实际组织结构可调整，但权限模型保持一致。
第一百九十九章 最终权限模型
Operator
│
├── Organization
│
├── Roles
│ ↓
│ Permissions
│
├── Data Scope
│
└── Sensitive Permissions
↓
Audit Log
第二百章 最终设计原则
整个运营管理后台必须坚持：
后台统一，权限分开。
用户属于平台，不属于某个工作人员或某个组织的私人资源。
角色决定能做什么，数据范围决定能对谁做。
敏感信息永远需要额外权限。
红娘、审核员、活动人员、风控员职责必须分离。
志愿者始终使用最低权限。
机构合作不等于数据全共享。
工作人员离职，权限必须立即消失。
任何高风险操作必须可追溯。
任何权限设计都必须同时在服务端执行，不能只靠前端隐藏。
最终后台不是为了让管理员“什么都能看到”，而是为了做到：
每个人只看到完成自己工作所需要的内容，只能做自己被授权做的事情，而且做过的关键事情都能被追溯。
这才是公益婚恋平台能够由多个组织、多个工作人员长期共同运营，而不会随着人员增加逐渐失控的基础。