danyang-match/运营管理后台与组织权限体系详细设计.md

# 丹阳公益婚恋服务平台
# V1.0 运营管理后台与组织权限体系详细设计

版本：V1.0  
适用范围：平台管理员、妇联、工会、公益服务中心、公益红娘、审核员、活动管理员、风控员、志愿者  
核心目标：统一后台、统一账号、按角色授权、按组织隔离、敏感权限最小化、关键操作可审计

---

# 第一章 设计目标

V1.0后台不是单纯的数据管理工具。

它必须同时承担：

- 用户管理
- 资料审核
- 匹配规则管理
- 公益红娘管理
- 活动管理
- 举报风控
- 组织管理
- 工作人员管理
- 权限管理
- 数据统计
- 安全审计

后台设计必须解决以下核心问题：

1. 谁可以登录
2. 谁可以看到哪些菜单
3. 谁可以看到哪些用户
4. 谁可以处理哪些任务
5. 谁可以查看敏感信息
6. 不同组织之间如何隔离
7. 多角色人员如何授权
8. 工作人员离职如何立即失效
9. 重大操作如何审计
10. 如何避免“一个管理员什么都能看”

核心原则：

> **一个后台，一套账号，多角色、多权限、多组织数据范围。**

---

# 第二章 V1后台总体架构建议

推荐：

> **公益红娘工作台、运营管理后台、平台管理后台使用同一个响应式Web应用。**

通过：

```text
账号
+
角色
+
权限
+
数据范围
```

决定用户看到什么。

而不是开发三套完全独立后台。

---

# 第三章 为什么推荐统一后台

统一后台可以减少：

- 三套登录
- 三套用户体系
- 三套权限代码
- 三套组件
- 三套部署
- 三套维护

技术上统一。

业务上：

> 不同角色看到不同工作界面。

---

# 第四章 后台入口

统一：

```text
/admin
```

或正式域名：

```text
https://admin.example.com
```

登录后根据权限进入对应首页。

---

# 第五章 Operator统一账号模型

所有工作人员统一：

```text
operators
```

包括：

- 平台管理员
- 机构管理员
- 审核员
- 公益红娘
- 活动管理员
- 风控员
- 志愿者

不要为红娘、管理员、志愿者分别做独立账号表。

---

# 第六章 Operator基本属性

至少包含：

```text
operatorId
name
organizationId
status
roles
permissions
lastLoginAt
```

---

# 第七章 OperatorStatus

建议：

```text
active
disabled
locked
expired
```

含义：

### active

正常。

### disabled

人工停用。

### locked

安全锁定。

### expired

临时账号已到期。

---

# 第八章 一个Operator可以拥有多个角色

例如：

某公益服务中心负责人：

```text
organization_admin
+
activity_manager
```

某工作人员：

```text
matchmaker
+
activity_manager
```

允许。

但权限最终取：

> 已授权角色的权限合集 + 数据范围限制。

---

# 第九章 角色与权限必须分离

角色：

```text
matchmaker
```

是一组权限模板。

权限：

```text
matchmaker.service.view
```

才是真正的操作能力。

不要在代码里写：

```text
if role == matchmaker
```

决定所有行为。

---

# 第十章 V1默认角色

建议：

```text
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

用于：

> 只读统计。

例如机构负责人只看运营数据。

不能：

- 修改用户
- 审核
- 封禁
- 查看敏感资料

---

# 第二十章 权限模型

建议采用：

```text
RBAC
+
Data Scope
+
Sensitive Permission
```

三层。

---

# 第二十一章 第一层：RBAC

决定：

> 能不能做某类操作。

例如：

```text
activity.create
```

---

# 第二十二章 第二层：Data Scope

决定：

> 可以对哪些数据做。

例如同样拥有：

```text
activity.view
```

平台管理员：

> 全平台。

机构管理员：

> 本机构。

---

# 第二十三章 第三层：Sensitive Permission

决定：

> 是否允许查看高敏感字段。

例如：

```text
user.sensitive.identity.view
```

必须单独授权。

---

# 第二十四章 数据范围枚举

建议：

```text
platform
organization
assigned
self
activity_scope
```

---

# 第二十五章 platform范围

可以访问：

> 全平台符合权限的资源。

主要：

- super_admin
- platform_admin
- 特定risk_operator

---

# 第二十六章 organization范围

只能访问：

```text
resource.organization_id = operator.organization_id
```

---

# 第二十七章 assigned范围

只访问：

> 明确分配给自己的任务。

例如红娘：

```text
service.assigned_operator_id = currentOperator
```

---

# 第二十八章 self范围

只管理：

> 自己账号相关数据。

---

# 第二十九章 activity_scope

用于临时工作人员。

例如：

志愿者账号只允许：

```text
activity_id IN operator_activity_assignments
```

---

# 第三十章 Data Scope不能靠前端实现

错误：

前端不显示其他组织。

正确：

服务端SQL/Service就必须加范围。

否则用户手工改URL仍可能访问。

---

# 第三十一章 组织模型

组织表：

```text
organizations
```

类型：

```text
platform
women_federation
trade_union
charity_center
volunteer_team
civil_affairs_partner
other
```

---

# 第三十二章 组织层级

V1建议：

> 最多支持简单父子组织。

例如：

```text
平台运营主体
│
├── 妇联
├── 工会
└── 公益服务中心
```

不建设复杂无限级政府组织树。

---

# 第三十三章 organization字段建议

```text
id
parent_id
name
type
status
contact
created_at
```

---

# 第三十四章 OrganizationStatus

```text
active
disabled
```

disabled后：

- 组织人员不能继续新业务
- 现有服务进入转交
- 数据不删除

---

# 第三十五章 跨组织用户数据问题

用户属于：

> 平台用户。

而不是天然属于某个妇联/工会。

因此：

> 不建议给User加唯一organization_owner。

---

# 第三十六章 组织和用户的关系

应该通过：

- MatchmakerService
- ActivityRegistration
- ReviewTask分配
- Organization授权

建立业务关系。

而不是：

```text
user.organization_id
```

直接把用户“归属”某组织。

---

# 第三十七章 为什么用户不应归属组织

一个用户可能：

- 参加工会活动
- 接受公益服务中心红娘帮助
- 被平台统一审核

因此用户是：

> 平台主体数据。

组织只有：

> 特定服务访问权。

---

# 第三十八章 后台一级菜单

统一建议：

```text
工作台
用户管理
资料审核
匹配管理
公益红娘
活动管理
举报风控
数据统计
组织人员
权限管理
系统设置
审计日志
```

---

# 第三十九章 菜单动态生成

根据：

```text
currentOperator.permissions
```

动态显示。

没有：

```text
risk.report.view
```

就不显示：

> 举报风控。

---

# 第四十章 工作台按角色变化

同一个：

```text
/dashboard
```

根据角色显示不同卡片。

---

# 第四十一章 Reviewer工作台

显示：

```text
待审核
已领取
今日已完成
退回待复审
```

---

# 第四十二章 Matchmaker工作台

显示：

```text
新服务
待首次处理
今日待跟进
等待用户
服务中
```

---

# 第四十三章 Activity Manager工作台

显示：

```text
报名中活动
待审核报名
今日活动
待签到
近期活动
```

---

# 第四十四章 Risk Operator工作台

显示：

```text
高风险举报
待处理举报
风险用户
待处理申诉
```

---

# 第四十五章 Platform Admin工作台

显示：

```text
待审核资料
待处理举报
红娘待分配
活动报名待审核
异常账号
```

不做炫酷大屏。

---

# 第四十六章 用户管理模块权限

建议：

```text
user.list.view
user.detail.view
user.status.change
user.sensitive.view
user.relationship.summary.view
user.activity.summary.view
user.matchmaker.summary.view
```

---

# 第四十七章 用户列表默认字段

显示：

```text
用户ID
展示名
性别
年龄
区域
实名认证
资料审核
婚恋状态
账号状态
注册时间
```

不显示：

- 完整手机号
- 身份证
- 聊天
- 举报详情

---

# 第四十八章 用户列表搜索

支持：

```text
用户ID
展示名
脱敏手机号/授权手机号搜索
```

手机号搜索：

> 仅授权人员。

---

# 第四十九章 用户详情Tab

建议：

```text
基础信息
婚恋资料
审核记录
匹配摘要
活动摘要
红娘服务
账号状态
```

风险信息：

> 有权限才出现。

---

# 第五十章 用户详情不展示完整聊天

明确禁止普通用户管理页面加：

> 聊天记录Tab。

聊天只能在风控案件场景下按权限访问。

---

# 第五十一章 敏感身份入口

独立：

```text
查看实名信息
```

点击：

> 权限校验 + 访问原因 + 审计。

---

# 第五十二章 默认脱敏

显示：

```text
姓名：张**
身份证：320***********1234
手机号：138****1234
```

---

# 第五十三章 查看完整身份

只有：

```text
user.sensitive.identity.full
```

权限允许。

V1建议极少授权。

---

# 第五十四章 资料审核菜单

权限：

```text
review.list.view
review.claim
review.process
review.reject
review.history.view
```

---

# 第五十五章 Reviewer只能处理审核

不能因为能看审核页：

> 就拥有user.status.change。

---

# 第五十六章 审核任务数据范围

平台统一审核时：

```text
platform
```

如果未来机构自行审核：

可以按：

> assigned / organization

控制。

V1建议核心实名资料审核由平台统一标准管理。

---

# 第五十七章 匹配管理菜单

权限：

```text
match.stats.view
match.list.view
match.rule.view
match.rule.manage
match.rule.activate
```

---

# 第五十八章 普通管理员不需要看所有用户匹配详情

匹配详情属于较高隐私业务数据。

默认后台重点看：

- 聚合统计
- 规则
- 异常

不是：

> 谁喜欢了谁的全部流水。

---

# 第五十九章 查看特定Match

只在：

- 用户投诉
- 风控
- 服务处理

等必要场景开放。

---

# 第六十章 Match Rule权限

只有少数平台角色：

```text
match.rule.manage
```

可以修改。

机构管理员不能修改全局算法。

---

# 第六十一章 公益红娘模块权限

```text
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若负责红娘：

可以：

- 看本机构服务
- 分配本机构红娘
- 看工作量

不能：

> 看其他机构服务。

---

# 第六十三章 活动管理权限

```text
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
```

---

# 第六十四章 发布和编辑分离

可以允许工作人员：

> 创建活动草稿。

但只有负责人：

```text
activity.publish
```

可以正式发布。

降低误操作风险。

---

# 第六十五章 取消活动属于高风险权限

```text
activity.cancel
```

必须：

- 二次确认
- 原因
- 审计

---

# 第六十六章 志愿者只给

```text
activity.checkin
```

和必要：

```text
activity.registration.basic_view
```

即可。

---

# 第六十七章 举报风控权限

建议细拆：

```text
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建议。

严重高风险时至少由高权限角色操作。

---

# 第七十章 聊天查看权限单独存在

```text
message.content.review
```

不能因为：

```text
risk.report.process
```

就自动获得全部聊天读取。

---

# 第七十一章 风控聊天读取必须案件关联

正确：

```text
Report
↓
Conversation Context
```

错误：

```text
用户详情
↓
所有聊天
```

---

# 第七十二章 组织人员菜单

权限：

```text
organization.list
organization.view
organization.create
organization.edit

operator.list
operator.create
operator.edit
operator.disable
operator.role.assign
```

---

# 第七十三章 organization_admin人员权限

只能管理：

```text
operators.organization_id = currentOrg
```

不能新增平台管理员。

---

# 第七十四章 机构管理员不能给自己越权

例如本机构最大允许：

```text
matchmaker
activity_manager
volunteer
```

机构管理员不能通过角色接口：

> 给自己super_admin。

服务端需要：

> Role Assignment Boundary。

---

# 第七十五章 角色分配边界

每个管理角色定义：

```text
assignable_roles
```

例如：

organization_admin可分配：

```text
matchmaker
activity_manager
volunteer
data_viewer
```

不能分：

```text
platform_admin
super_admin
```

---

# 第七十六章 权限管理菜单

只对：

```text
permission.manage
```

开放。

建议V1只有：

- super_admin
- 指定platform_admin

拥有。

---

# 第七十七章 系统角色

默认角色：

```text
system_role = true
```

不允许删除。

可以：

> 克隆后创建自定义角色。

---

# 第七十八章 自定义角色

例如：

```text
工会活动负责人
```

可以从：

```text
activity_manager
```

复制后精简权限。

---

# 第七十九章 不建议V1做复杂ABAC

不要建设：

- 表达式权限引擎
- 策略语言
- 动态属性规则系统

RBAC + 数据范围足够。

---

# 第八十章 权限命名规范

统一：

```text
module.resource.action
```

例如：

```text
user.detail.view
activity.registration.review
risk.user.ban
match.rule.manage
```

---

# 第八十一章 权限不能按按钮命名

错误：

```text
button_123
```

正确：

> 表达业务能力。

---

# 第八十二章 权限后端统一注解/中间件

例如：

```text
@RequirePermission("activity.publish")
```

或框架对应机制。

避免Controller手写大量：

```text
if role...
```

---

# 第八十三章 数据范围服务

建议独立：

```text
DataScopeService
```

输入：

```text
operator
resourceType
```

输出可访问条件。

---

# 第八十四章 示例：红娘服务查询

红娘：

```text
assigned_operator_id = me
```

机构管理员：

```text
organization_id = myOrg
```

平台管理员：

> 无组织限制。

---

# 第八十五章 示例：活动列表

志愿者：

> 只看被分配活动。

活动管理员：

> 本组织活动。

平台管理员：

> 全部。

---

# 第八十六章 用户数据访问不能简单按机构过滤

再次强调：

用户是平台用户。

机构只能通过：

> 具体服务关系

获取必要资料。

---

# 第八十七章 OrganizationAccessGrant建议

为未来跨组织协作，可预留：

```text
organization_access_grants
```

但V1如果业务简单：

> 暂不必建复杂授权表。

先通过业务对象关联授权。

---

# 第八十八章 用户与红娘的数据范围

红娘可看用户完整Matchmaker DTO的前提：

```text
存在有效service
AND
service.assigned_operator = currentOperator
```

---

# 第八十九章 用户与活动管理员的数据范围

活动管理员可看报名必要资料的前提：

```text
user registered activity
AND
activity belongs to currentOrg / authorized
```

---

# 第九十章 用户与审核员的数据范围

审核员可以看：

> 当前审核任务必要资料。

不能因此浏览用户全部红娘、活动、聊天历史。

---

# 第九十一章 用户与风控员的数据范围

风控员基于：

- Report
- RiskEvent
- Appeal

访问必要资料。

---

# 第九十二章 Data Minimization必须在后台体现

不是只有用户端隐私。

后台也应做到：

> 每个角色只看完成任务所需要的信息。

---

# 第九十三章 后台顶部Header

显示：

```text
当前组织
当前用户
通知
退出
```

不需要：

- 天气
- 时间大屏
- 欢迎词大Banner

---

# 第九十四章 Sidebar

宽度：

```text
220～240px
```

折叠：

> 可选。

桌面V1优先1280+。

---

# 第九十五章 后台页面统一结构

```text
PageHeader
↓
FilterBar
↓
Content
↓
Pagination
```

---

# 第九十六章 表格原则

默认：

```text
20条/页
```

可选择：

```text
20
50
```

100可作为技术支持但不必前台突出。

该分页属于UX配置，不是业务硬规则。

---

# 第九十七章 表格操作

每行最多：

```text
查看
处理
更多
```

不要一行放8个按钮。

---

# 第九十八章 高风险按钮

例如：

```text
封禁
取消活动
停用工作人员
```

放：

> 更多

或详情页。

并二次确认。

---

# 第九十九章 后台状态色

统一使用：

- 正常：绿色
- 待处理：橙色
- 风险：红色
- 普通：蓝/灰

不能所有异常都一片大红。

---

# 第一百章 数据统计模块权限

```text
analytics.overview.view
analytics.user.view
analytics.match.view
analytics.activity.view
analytics.matchmaker.view
analytics.risk.view
```

---

# 第一百零一章 机构统计范围

机构管理员只能看：

> 本机构参与产生的运营数据。

例如：

- 本机构活动
- 本机构红娘服务

不能看全平台完整用户数据。

---

# 第一百零二章 平台统计

platform_admin可看：

- 用户
- 匹配
- 活动
- 红娘
- 风控

全平台汇总。

---

# 第一百零三章 数据导出权限

建议：

```text
data.export
```

单独权限。

不要：

> 能看列表就能导出。

---

# 第一百零四章 为什么导出单独授权

Web页面：

> 有访问控制。

Excel下载后：

> 很难继续控制传播。

因此导出风险更高。

---

# 第一百零五章 V1限制导出范围

优先支持：

- 活动执行脱敏名单
- 必要运营统计

不提供：

> 全量用户数据库导出。

---

# 第一百零六章 导出内容必须脱敏

例如活动：

```text
活动编号
展示名
手机号后四位
报名状态
签到状态
```

---

# 第一百零七章 导出审计

记录：

```text
operator
export_type
filters
row_count
time
```

敏感导出建议：

> 水印。

---

# 第一百零八章 Audit模块菜单

权限：

```text
audit.view
audit.sensitive.view
audit.export
```

---

# 第一百零九章 普通管理员是否看Audit

可以看：

> 自己组织的普通操作日志。

高敏感日志：

> 平台安全角色。

---

# 第一百一十章 Audit记录操作

至少：

```text
登录
审核
用户状态修改
红娘分配
活动发布/取消
举报处理
风控处置
权限变更
工作人员创建/停用
敏感数据访问
系统配置修改
```

---

# 第一百一十一章 Audit不可由普通后台删除

审计日志：

> 不提供删除按钮。

---

# 第一百一十二章 SensitiveAccessLog

与普通Audit分开。

记录：

```text
谁
查看谁
什么敏感数据
为什么
什么时候
```

---

# 第一百一十三章 敏感访问理由

可使用标准：

```text
身份异常核验
举报调查
申诉处理
依法配合
其他
```

其他需要填写说明。

---

# 第一百一十四章 工作人员登录安全

V1至少：

```text
账号+密码
强密码
登录限频
失败锁定
Session超时
停用实时失效
```

---

# 第一百一十五章 MFA

建议优先给：

```text
super_admin
platform_admin
risk_operator（高权限）
```

启用。

如果V1研发周期紧：

> P1。

但架构预留。

---

# 第一百一十六章 Session有效期

工作人员后台建议：

> 比普通小程序更严格。

例如：

```text
空闲一定时间重新认证
```

具体时长待安全配置确定。

不要在业务代码写死。

---

# 第一百一十七章 高敏感操作再认证

P1可考虑：

> 查看完整身份证 / 修改权限 / 永久封禁

要求再次输入密码或MFA。

---

# 第一百一十八章 临时志愿者账号

支持：

```text
expires_at
```

活动结束后：

> 自动expired。

---

# 第一百一十九章 离职流程

工作人员离职：

```text
operator.status = disabled
↓
撤销所有Session
↓
停止API权限
↓
转交服务
↓
审计
```

---

# 第一百二十章 红娘离职服务转交

系统提示：

> 当前仍有18个未完成服务。

必须先：

- 批量重新分配
- 或管理员接管

不能只停账号。

---

# 第一百二十一章 机构人员停用

机构管理员可以停：

> 本机构普通人员。

不能停：

> 平台管理员。

---

# 第一百二十二章 平台管理员停用机构管理员

平台权限允许。

停用后：

> 该组织需重新指定负责人。

---

# 第一百二十三章 后台通知中心

工作人员通知：

```text
新审核任务
新举报
红娘任务分配
活动报名待审核
用户风险变化
权限/账号安全
```

---

# 第一百二十四章 通知按职责发送

不要：

> 每个管理员都收到所有消息。

例如：

活动报名：

> 活动管理员。

举报：

> 风控员。

审核：

> 审核员。

---

# 第一百二十五章 工作人员个人待办

建议：

```text
GET /operator/tasks
```

统一返回：

```text
review
matchmaker
activity
risk
```

属于自己的待办。

---

# 第一百二十六章 是否建设通用工单系统

V1不需要。

各业务有自己的Task实体。

Dashboard统一聚合即可。

---

# 第一百二十七章 平台超级管理员红线

即使是super_admin：

> 也不应该默认在普通页面看全部私人聊天。

技术超级权限：

≠

日常业务合理权限。

---

# 第一百二十八章 Break Glass机制建议

未来针对极特殊安全事件，可以有：

> 紧急访问。

例如高级安全负责人临时访问某敏感数据。

必须：

- 填写原因
- 强审计
- 可复核

V1可先预留理念，不一定做复杂系统。

---

# 第一百二十九章 系统设置权限

```text
system.config.view
system.config.manage
```

可配置：

- 推荐数量
- 活动功能开关
- 红娘功能开关
- 图片上限
- 风控基础配置

---

# 第一百三十章 不允许普通运营修改技术Secret

后台系统设置不要暴露：

- 数据库密码
- 微信Secret
- JWT Secret
- 云密钥

这些属于部署Secret。

不是运营配置。

---

# 第一百三十一章 Feature Flag

后台可见：

```text
活动服务
红娘服务
图片聊天
```

等业务开关。

---

# 第一百三十二章 系统维护模式

只有高权限人员：

```text
system.maintenance.manage
```

可开启。

开启：

> 用户端进入维护页。

必须二次确认。

---

# 第一百三十三章 用户账号状态修改

普通后台不能随意：

```text
normal → banned
```

必须走：

> RiskAction。

用户管理页可以提供：

> 查看状态

但封禁动作进入风控流程。

---

# 第一百三十四章 为什么不能User页面直接改状态

这样能保证：

- 有原因
- 有风控记录
- 可申诉
- 可审计

不会出现管理员随手改数据库状态。

---

# 第一百三十五章 用户资料人工修改

V1后台原则：

> 工作人员不直接替用户修改婚恋资料。

审核员只能：

- 通过
- 退回

用户本人修改。

---

# 第一百三十六章 特殊代录场景

如果未来服务老年/特殊用户需要工作人员代录：

必须独立：

> Assisted Entry流程。

V1普通后台不提供。

---

# 第一百三十七章 系统内部用户备注

是否允许管理员随意写“内部备注”？

建议非常谨慎。

只允许业务模块已有：

- 审核备注
- 红娘跟进
- 风控记录
- 活动异常

不要增加一个：

> 所有人都能写的“用户备注”。

容易形成不当标签。

---

# 第一百三十八章 组织权限矩阵概览

| 功能 | 平台管理员 | 机构管理员 | 审核员 | 红娘 | 活动管理员 | 风控员 | 志愿者 |
|---|---:|---:|---:|---:|---:|---:|---:|
| 用户基本列表 | 是 | 有限 | 审核相关 | 服务相关 | 报名相关 | 风控相关 | 否 |
| 实名敏感信息 | 单独权限 | 否 | 必要脱敏 | 否 | 否 | 单独权限 | 否 |
| 资料审核 | 可 | 按授权 | 是 | 否 | 否 | 否 | 否 |
| 红娘服务 | 管理 | 本机构 | 否 | 是 | 否 | 必要摘要 | 否 |
| 活动管理 | 管理 | 本机构 | 否 | 推荐活动 | 是 | 必要摘要 | 签到 |
| 举报风控 | 管理 | 默认否 | 否 | 转交 | 转交 | 是 | 转交 |
| 聊天正文 | 默认否 | 否 | 否 | 否 | 否 | 案件授权 | 否 |
| 权限管理 | 指定 | 有限 | 否 | 否 | 否 | 否 | 否 |
| 统计 | 全平台 | 本机构 | 自身工作 | 自身服务 | 本机构活动 | 风控 | 否 |

---

# 第一百三十九章 机构管理员的数据范围

核心：

> 本组织产生/被授权处理的业务。

例如：

```text
本机构活动
本机构红娘服务
本机构工作人员
```

不自动获得：

> 全平台婚恋用户库。

---

# 第一百四十章 平台管理员的数据范围

平台管理需要全局运营能力。

但敏感字段仍：

> 单独权限。

---

# 第一百四十一章 审核员的数据范围

审核任务。

不是：

> 全平台自由搜索用户。

---

# 第一百四十二章 风控员的数据范围

风险案件。

可以根据案件扩大必要上下文。

但每一步仍遵守：

> 最小必要。

---

# 第一百四十三章 跨机构红娘服务

如果用户申请平台统一红娘服务：

管理员可把Service分配给某合作机构。

此时：

> 该机构只获得该Service必要的数据访问。

---

# 第一百四十四章 Service结束后访问权限

服务完成后：

红娘是否无限期继续查看用户？

建议：

> 不应。

完成后保留服务历史摘要，但对完整婚恋资料的实时访问应按业务需要收缩。

V1可以先做到：

> 已完成服务只读。

未来再进一步做访问期限。

---

# 第一百四十五章 活动结束后志愿者权限

活动结束：

> 临时账号过期。

不能继续查看历史报名名单。

---

# 第一百四十六章 数据访问期限思想

权限不仅是：

> “有没有”。

未来还应考虑：

> “什么时候还有”。

V1重点先覆盖临时活动账号。

---

# 第一百四十七章 后台列表URL状态

筛选写Query：

```text
/reviews?status=pending&page=2
```

便于刷新恢复。

---

# 第一百四十八章 详情页必须URL可恢复

例如：

```text
/admin/users/{id}
/admin/reviews/{id}
/admin/reports/{id}
```

刷新后重新请求。

不能靠上一页传对象。

---

# 第一百四十九章 后台401

Session过期：

> 回登录。

如果页面有未保存表单：

优先保存非敏感草稿或提示。

---

# 第一百五十章 后台403

显示：

> 你没有访问该功能的权限。

不要：

> 白屏。

---

# 第一百五十一章 数据范围403

例如机构管理员手改其他组织activityId：

返回：

```text
ORGANIZATION_SCOPE_DENIED
```

---

# 第一百五十二章 敏感权限403

返回：

```text
SENSITIVE_ACCESS_DENIED
```

---

# 第一百五十三章 Operator账号异常

disabled：

> 当前账号已停用，请联系管理员。

locked：

> 当前账号因安全原因暂时锁定。

---

# 第一百五十四章 机构停用

组织被停用：

其Operator不能继续普通业务。

服务端登录/请求检查：

```text
organization.status
```

---

# 第一百五十五章 组织停用后的在途任务

管理员必须处理：

- 红娘服务转交
- 活动负责人调整
- 未完成工作

不能直接删除组织。

---

# 第一百五十六章 组织删除原则

不物理删除已有业务组织。

采用：

```text
disabled
```

历史Audit和活动仍能关联。

---

# 第一百五十七章 角色删除原则

系统角色：

> 不删除。

自定义角色如果已有人使用：

> 先解除关联或禁用。

建议roles增加：

```text
status
```

---

# 第一百五十八章 权限变更实时生效

管理员撤销某Operator：

```text
risk.user.ban
```

下一次请求：

> 立即不能使用。

不要等重新登录。

---

# 第一百五十九章 权限缓存

可以Redis缓存：

```text
operator_permissions:{id}
```

权限修改后：

> 立即失效。

---

# 第一百六十章 Session与权限分离

Token不建议把全部权限永久写死到长周期JWT中。

否则权限改了：

> 老Token还有效。

可：

- 短Token
- 权限版本
- Redis Session

确保及时生效。

---

# 第一百六十一章 Operator权限版本

可增加：

```text
permission_version
```

角色变化：

```text
version +1
```

Token/Session发现版本不一致：

> 重新加载权限。

---

# 第一百六十二章 登录日志

建议：

```text
operator_login_logs
```

记录：

- operator
- IP
- User Agent
- 成功/失败
- 时间

也可纳入Security Log。

---

# 第一百六十三章 异常登录提醒

P1：

如果：

- 新设备
- 异常IP
- 短时间多次失败

提醒管理员或本人。

---

# 第一百六十四章 Admin Header当前组织切换

如果某平台工作人员被授权多个组织：

可以：

> 切换工作上下文。

普通机构人员：

> 固定组织。

V1如无多组织Operator需求，可暂不做切换。

---

# 第一百六十五章 组织切换不能改变实际权限

切换只是：

> 数据上下文。

不能通过切组织获得未授权范围。

---

# 第一百六十六章 后台搜索全局能力

不建议做一个：

> 全局搜人/手机号/聊天/举报

超级搜索。

风险太高。

各业务模块：

> 在本模块内搜索。

---

# 第一百六十七章 用户搜索手机号

只有特定权限：

```text
user.phone.search
```

才能使用。

返回结果仍脱敏。

---

# 第一百六十八章 身份证搜索

V1原则：

> 普通后台不提供。

确因实名认证异常需要：

使用Identity模块受控查询。

---

# 第一百六十九章 统计匿名化

统计页尽量用：

> 聚合数据。

不需要显示具体用户。

---

# 第一百七十章 小样本隐私

如果某机构某条件只有1人：

后台统计也应避免为了图表直接暴露个体敏感信息。

V1可以先不做过细交叉分析。

---

# 第一百七十一章 后台批量操作

V1只谨慎支持：

- 批量活动报名审核（建议后期）
- 批量任务分配

不支持：

> 批量封禁用户

作为普通功能。

---

# 第一百七十二章 批量敏感操作风险

任何批量状态变化：

必须：

- 预览
- 二次确认
- Audit

---

# 第一百七十三章 用户封禁不支持普通批量

除非技术攻击场景由安全系统处理。

人工运营不需要：

> 选100人一键封禁。

---

# 第一百七十四章 后台操作Undo

高风险操作不要依赖：

> Toast后5秒撤销。

应该通过正式：

- revoke
- appeal
- restore

流程。

---

# 第一百七十五章 资料审核支持快捷操作

可以：

```text
通过
需修改
```

降低工作人员操作量。

严重拒绝：

放“更多”。

---

# 第一百七十六章 审核原因标准化

使用：

> review_reasons字典。

减少审核员每次自由发挥。

可以补充：

> 备注。

---

# 第一百七十七章 风控原因标准化

同样使用：

> resultCode / actionType。

便于统计和复核。

---

# 第一百七十八章 权限变更审计样例

例如：

```text
2026-08-28 14:32
管理员：李某
操作：修改张某角色
原角色：matchmaker
新角色：matchmaker + activity_manager
```

---

# 第一百七十九章 敏感访问审计样例

```text
2026-08-28 15:10
操作员：王某
查看：USR-xxx 实名信息
原因：身份异常核验
```

---

# 第一百八十章 后台权限测试矩阵

每个API至少测试：

```text
无Token
普通用户Token
错误Operator角色
正确角色错误组织
正确角色正确组织
敏感权限缺失
账号disabled
```

---

# 第一百八十一章 重点越权测试一

红娘手工请求：

```text
GET /admin/users/{id}/sensitive-identity
```

结果：

> 403。

---

# 第一百八十二章 重点越权测试二

志愿者请求：

```text
GET /admin/activities/other-activity/registrations
```

非授权活动：

> 403。

---

# 第一百八十三章 重点越权测试三

机构管理员请求：

> 其他机构红娘服务。

结果：

> ORGANIZATION_SCOPE_DENIED。

---

# 第一百八十四章 重点越权测试四

审核员请求：

```text
POST /admin/risk/users/{id}/actions
```

结果：

> PERMISSION_DENIED。

---

# 第一百八十五章 重点越权测试五

风控员无：

```text
message.content.review
```

访问聊天：

> 403。

---

# 第一百八十六章 重点越权测试六

机构管理员给自己分配：

```text
super_admin
```

必须：

> 拒绝。

---

# 第一百八十七章 重点实时权限测试

管理员把红娘账号disabled。

该红娘即使页面没刷新：

下一次API：

> ACCOUNT_DISABLED。

Session失效。

---

# 第一百八十八章 后台数据审计验收

必须能回答：

```text
谁审核了这个用户？
谁封禁了这个账号？
谁取消了这场活动？
谁看过这个用户的敏感身份？
谁给这个工作人员加了权限？
```

如果回答不了：

> 审计设计不合格。

---

# 第一百八十九章 后台UX验收

工作人员登录后5秒内应该知道：

> 今天有什么需要处理。

审核员不需要在：

> 用户管理 → 搜索 → 打开 → 找审核

才能工作。

直接：

> 工作台 → 待审核。

---

# 第一百九十章 后台安全UX原则

安全不能完全依赖培训。

界面本身必须减少错误：

- 危险按钮不突出
- 高风险操作二次确认
- 敏感字段默认脱敏
- 无权限入口不显示
- 数据范围自动限制

---

# 第一百九十一章 后台P0模块

```text
统一登录
Dashboard
用户管理
资料审核
红娘服务
活动管理
举报风控
组织人员
RBAC
审计
```

---

# 第一百九十二章 P1模块

```text
高级统计
敏感动态水印
MFA
临时活动账号
登录异常提醒
细化数据导出
权限复核
```

---

# 第一百九十三章 P2模块

```text
跨机构高级协同
审批式权限申请
Break Glass
自动权限到期
更高级合规审计
```

---

# 第一百九十四章 推荐后台代码模块

```text
admin/
  auth/
  dashboard/
  users/
  reviews/
  matches/
  matchmaker/
  activities/
  risk/
  analytics/
  organizations/
  operators/
  roles/
  permissions/
  audit/
  configs/
```

---

# 第一百九十五章 后端权限模块建议

```text
OperatorAuthService
PermissionService
RoleService
DataScopeService
OrganizationService
SensitiveAccessService
AuditService
```

---

# 第一百九十六章 权限判断标准流程

```text
请求
↓
Operator认证
↓
账号是否active
↓
Organization是否active
↓
是否拥有permission
↓
DataScope是否允许resource
↓
是否涉及sensitive permission
↓
允许业务Service执行
↓
必要时Audit
```

---

# 第一百九十七章 后台设计最终红线

严禁：

1. 所有工作人员共用一个admin账号  
2. 红娘拥有全部用户资料权限  
3. 普通管理员能浏览私人聊天  
4. 志愿者看到身份证  
5. 机构管理员看到其他机构全部数据  
6. 前端隐藏按钮代替后端权限  
7. 可以随意导出全量用户  
8. 权限修改没有审计  
9. 离职人员账号继续可用  
10. 用户封禁可以无原因直接修改数据库状态  

---

# 第一百九十八章 最终组织模型

```text
                 平台运营主体
                      │
        ┌─────────────┼─────────────┐
        │             │             │
       妇联           工会      公益服务中心
        │             │             │
   ┌────┴───┐     ┌───┴───┐     ┌───┴────┐
   │        │     │       │     │        │
活动管理员 红娘   活动人员 负责人   红娘     志愿者

平台层：
审核员
风控员
平台管理员
```

具体实际组织结构可调整，但权限模型保持一致。

---

# 第一百九十九章 最终权限模型

```text
Operator
   │
   ├── Organization
   │
   ├── Roles
   │      ↓
   │  Permissions
   │
   ├── Data Scope
   │
   └── Sensitive Permissions
          ↓
       Audit Log
```

---

# 第二百章 最终设计原则

整个运营管理后台必须坚持：

> **后台统一，权限分开。**

> **用户属于平台，不属于某个工作人员或某个组织的私人资源。**

> **角色决定能做什么，数据范围决定能对谁做。**

> **敏感信息永远需要额外权限。**

> **红娘、审核员、活动人员、风控员职责必须分离。**

> **志愿者始终使用最低权限。**

> **机构合作不等于数据全共享。**

> **工作人员离职，权限必须立即消失。**

> **任何高风险操作必须可追溯。**

> **任何权限设计都必须同时在服务端执行，不能只靠前端隐藏。**

最终后台不是为了让管理员“什么都能看到”，而是为了做到：

> **每个人只看到完成自己工作所需要的内容，只能做自己被授权做的事情，而且做过的关键事情都能被追溯。**

这才是公益婚恋平台能够由多个组织、多个工作人员长期共同运营，而不会随着人员增加逐渐失控的基础。