用户管理

> 所属产品：LightApollo · 信息截止：2026-09-07（deep-rev）

1. 页面概览

1.1 是什么

「用户管理」页（对应前端源码 action/web/src/views/apollo/UsersPage.vue，页面标题「平台管理 · 用户管理」）是 LightApollo 独立账号体系的治理入口。LightApollo 拥有独立于 AIP/Foundry 的用户库与登录态（独立 apollo_token），本页只管理 Apollo 域内的账号与角色挂载：上半部分是一个带关键字过滤与客户端分页的用户列表，把每个用户的 ID、用户名、姓名、邮箱、角色标签、锁定状态与创建时间铺成一览表；操作入口只有两个——页头「新建用户」弹窗（后端当前仅支持 username/password 两个字段）与每行「分配角色」弹窗（勾选/取消即增删该用户的角色绑定）。页面在 TAD-11（细粒度 RBAC）批次 2 引入，配套「角色管理」页（定义角色与权限点）与「API Key 管理」页（为第三方程序发放 lap_ 开头访问凭据）构成平台管理组三条账号主线。

本页的定位是「账号创建 + 角色挂载」两个动作，而非完整的账号生命周期治理：与 AIP 管理后台的 UsersPage.vue（支持编辑、锁定/解锁、重置密码、删除）不同，Apollo 用户表只开放「读、建、挂角色」三类能力——后端没有注册 PUT /users/:id（改信息/重置密码）与 DELETE /users/:id（删除）路由，页面也因此不出现编辑、锁定、重置密码、删除按钮。也就是说：创建出来的账号一旦因连续登录失败被自动锁定（is_locked=true），没有任何页面入口可解锁或重置其密码，只能靠管理员直接改库，这是本页边界最需要先讲清的一点（详见第 8 章）。

从「输入→输出」看页面闭环：输入是管理员手动填写的用户名/密码，或对某个已有账号勾选的角色；输出是 POST /users、POST/DELETE /users/:id/roles[...] 对 Apollo users 表（bcrypt 密码哈希）与 user_roles 关联表的写操作，以及页面顶部提示条的成败反馈。整个过程都经过受保护 API：GET /users 需要 user:read 权限点，创建用户需要 user:write，而「分配/移除角色」走的是 role:write 权限点（绑定关系的语义归属「角色管理」，不是「用户管理」，首次用本页前最好先记住这一点，否则会发现有 user:write 却仍 403，见 5.4 与 7 章）。全部写操作都会落审计（见 5.4 审计一节）。

典型使用链路（管理员视角）：① 首次部署后 seed 自动建好 5 个内置角色（platform_admin、project_admin、developer、operator、viewer）并把 admin 用户绑定 platform_admin，用 admin 登录 Apollo（独立登录，见 login.md）；② 需要自定义授权边界时先到「角色管理」新建角色并勾权限点；③ 回本页「新建用户」为同事创建账号（此时只有用户名/密码，姓名邮箱留空）；④ 在该用户行「分配角色」挂上角色；⑤ 同事用账号密码到 /apollo/login 登录。若某账号连续 5 次输错密码会被自动锁定（状态列翻红「已锁定」），本页与全站都没有解锁/重置密码入口，只能改库恢复——建议把「账号锁定后的处理流程」写进运维手册。与 AIP 管理后台的差异：AIP 的 UsersPage.vue（/admin/users）支持编辑资料、锁定/解锁、重置密码与删除（当前登录用户删除按钮隐藏）；Apollo 用户管理刻意收窄为「读、建、挂角色」三件事，编辑/删除/解锁路由未注册，页面按钮也对应不渲染——两页虽同名，能力集与后端路由完全不同，跨产品切换时不要套用旧操作习惯。

1.2 核心价值/能力表

1.3 一句话总结

本页是「看账号、建账号、挂角色」的 LightApollo 独立账号治理控制台：只开放读/建/绑角色，刻意不提供编辑、删除、解锁与重置密码入口。

2. 访问入口

2.1 路由与菜单

相邻页（同属平台管理组）：角色管理 admin-roles.md（后，负责定义本页可勾选的角色与权限点）、API Key 管理 admin-api-keys.md。创建角色要先去「角色管理」，再回本页做分配。

2.2 认证与权限

• 路由 requiresAuth: true；登录态为独立 apollo_token（Bearer JWT），2026-09-12 修订后不再回退读取旧 aip_token。401 由响应拦截器清 token 并跳 /apollo/login（登录页自身 401 不跳转，避免死循环）。
• 页面访问与「读」接口需要 user:read（用户列表、查看详情），「写」接口按动作细分：POST /users 需 user:write，POST /users/:id/roles 与 DELETE /users/:id/roles/:roleId 需 role:write，分配弹窗加载角色列表需 role:read（后端统一 RequirePerm 中间件鉴权）。
• 403 时响应拦截器统一 alert('无权限执行该操作')，随后页面 catch 再以「…失败：」前缀提示（一次 403 会同时看到两条提示，见 7 章）。
• 内置超管：角色 platform_admin / project_admin 持有通配权限点 *:*，任何权限点校验直接放行；普通用户的有效权限为其全部角色 role_permissions（类型 ACTION_ACCESS）中 resource_name 的并集。
• 页面动作与权限点映射：列表与详情读 user:read；创建用户 user:write；分配/移除角色 role:write；分配弹窗的候选角色列表读 role:read。内置 5 角色中仅 platform_admin/project_admin（*:*）默认具备这些权限点——developer/operator/viewer 的 seed 权限清单不含 user/role/apikey 的任何权限点，即平台管理组三个页面（用户/角色/API Key）默认只对两类超管开放，普通开发/运维/只读角色打开本页即列表 403。需要下放管理权时，在「角色管理」建自定义角色勾选 user:read/user:write/role:read/role:write 即可。

2.3 端口与 API 前缀

• Apollo 后端端口 18082；Vite 开发代理把 /apollo-api 前缀 rewrite 为 /api 转发，客户端 baseURL 为 /apollo-api/v1。浏览器内实际请求如 /apollo-api/v1/users → 后端收到 /api/v1/users。
• 统一响应 envelope {code, message, data, request_id}：拦截器在 code===0 时把 response.data 解包为业务数据，页面 const { data } = await apiClient.get(...) 拿到的即是业务数据本身（列表页 data.items / 角色页裸数组等，见 5.3）。

3. 界面布局

+--------------------------------------------------------------------+
| 平台管理 · 用户管理                                    [新建用户]    |
| [操作结果提示条（v-if alert.message，右侧「关闭」，四型可选）]        |
+--------------------------------------------------------------------+
| ┌ 列表卡片 ──────────────────────────────────────────────────────┐ |
| │ 工具栏：[搜索用户名 / 姓名 / 邮箱]          共 N 个用户          │ |
| │ 表格列：ID | 用户名 | 姓名 | 邮箱 | 角色 | 状态 | 创建时间 | 操作 │ |
| │  · ID：等宽前 12 位 + …；用户名加粗                              │ |
| │  · 姓名/邮箱：缺省显示 '-'（新建用户不填这两字段）                │ |
| │  · 角色：role-tag 蓝底圆角（含「×」移除）+「未分配」灰字兜底       │ |
| │  · 状态：正常（绿）/ 已锁定（红）徽标                            │ |
| │  · 创建时间：YYYY-MM-DD HH:MM:SS（RFC3339 去 T 截 19）          │ |
| │  · 操作：[分配角色]                                             │ |
| │ 空态：加载中... / 暂无用户（可调整关键字）                        │ |
| │ 分页（totalPages>1 才显示）：上一页 | page / totalPages | 下一页  │ |
| └────────────────────────────────────────────────────────────────┘ │
+--------------------------------------------------------------------+
| ┌ 新建用户弹窗（modal-sm）───────────────────────────────────────┐ │
| │ 用户名（username）* [如 alice]   密码（password）* [初始登录密码] │ │
| │ modal-hint：后端当前仅支持 username/password 两个字段创建用户…   │ │
| │ [取消] [创建/提交中...]（点遮罩/「关闭」亦可关）                 │ │
| └────────────────────────────────────────────────────────────────┘ │
| ┌ 分配角色弹窗 ──────────────────────────────────────────────────┐ │
| │ 分配角色：{{username}}                                         │ │
| │ 空态：暂无可用角色，请先到「角色管理」创建。                     │ │
| │ 每角色一行 checkbox：role_name + （权限 N 个 / 无权限）           │ │
| │ [取消] [保存/保存中...]                                         │ │
| └────────────────────────────────────────────────────────────────┘ │
+--------------------------------------------------------------------+

各板块职责：

4. 交互元素

4.1 页头与操作结果提示条

4.2 「新建用户」弹窗

页面加载与每次成功写操作后都会 fetchUsers()；新建用户是唯一创建账号的入口，弹窗为小尺寸 modal-sm。

创建成功后后端返回 201，data 为 {id, username}；提示文案把 data.username 反填进消息。注意创建动作不自动分配角色——新账号默认无角色，直到在行内点「分配角色」。

4.3 搜索框（客户端关键字过滤）

4.4 用户列表表格

字段兼容说明：列表项按后端 userView 序列化字段读取（id/username/name/email/is_locked/created_at/roles 全小写），但 Vue 里统一经 uId/uUsername/uName/uEmail/uIsLocked/uCreatedAt/uRoles 六个兼容函数取值，|| 兜底旧接口的 PascalCase 变体（ID/Username/...），防止换后端后整表空渲染。

4.5 「分配角色」按钮与弹窗

候选列表来自 GET /roles（返回裸数组）；角色是全局定义（无项目/空间区分），因此分配动作不做任何「项目范围」校验（projectScopeAccessGuard 只作用于 /projects/:id/... 路径，见 5.4）。

4.6 「保存」差分计算与提交

这是本页最值得说清的一步：前端不做整表覆盖，而是按差分发幂等请求。

handleAssignRoles() 逻辑：① 从本地 users 数组里按 userId 找到该用户，取其当前角色 id 集合 current；② 取勾选目标集合 target；③ toAdd = 候选里「current 没有且 target 有」的角色，toRemove = 候选里「current 有且 target 没有」的角色；④ 若二者都为空，只关弹窗、不发任何请求、不提示；⑤ 否则 saving=true，toAdd 逐个 POST /users/:id/roles（body {role_id}，后端幂等），toRemove 逐个 DELETE /users/:id/roles/:roleId，全部成功提示 角色已更新：新增 N 个，移除 N 个（success）、关弹窗、fetchUsers()。

关键约束：差分基准是本地列表快照，不是服务端实时态。若两个管理员同时改同一账号、或上次保存部分失败后未刷新列表，本次差分基于的 current 可能过时——重按「保存」时对已成功绑定过的角色会再次发幂等 POST（后端 OnConflict DoNothing，不报错），对已被他人移除的角色再发 DELETE 会拿到 404「用户角色绑定不存在」而整体提示失败。多写操作场景下以服务端最终态为准，必要时整页刷新后再分配。

4.7 「×」快捷移除角色

该按钮不进入弹窗，是「单角色快速解绑」的快捷路径；对每个已挂角色都有独立「×」。解绑不影响该角色本身，也不影响该用户的其他角色。

4.8 分页控件

分页在客户端做：后端一次性返回全部用户（见 5.2），页面按 PAGE_SIZE=10 切片。工具栏计数 共 {{ filteredUsers.length }} 个用户 表示过滤后的数量。分页栏仅在 totalPages > 1 时渲染。

4.9 忙状态互斥（saving / creating / loading）

页面用三个布尔互斥位控制并发，任何进行中的写操作都会禁用相关按钮，防止重复提交：

互斥是按钮级而非路由级：saving 期间「分配角色」按钮与弹窗开关、搜索、翻页都不受影响；真正的并发防护依赖后端接口幂等/校验（见 5.4）。

5. 后端关联

5.1 API 客户端

action/web/src/api/apolloClient.js：axios 实例 baseURL /apollo-api/v1、timeout 30000ms、请求拦截器统一附 Authorization: Bearer <token>（仅取 apollo_token，不回退 aip_token）。响应拦截器：HTTP 2xx 且 envelope code===0 时把 response.data 解包为业务数据；HTTP 2xx 但 code!==0 拒绝；4xx/5xx 提取 body.message || body.error 写入 error.response.data.error 后 reject——401 清 token 并跳 /apollo/login，403 alert('无权限执行该操作')。页面 catch 统一用 err.response?.data?.error || err.message 取后端文案拼进「…失败：」提示。

5.2 端点表

路由注册于 action/products/apollo/server/server.go 810–815 行（/api/v1 protected 组，先经 access.Authn 再逐条 RequirePerm）。projectScopeAccessGuard 只对 /api/v1/projects/:id... 生效，不约束本页端点。

5.3 响应结构示例

GET /users（envelope code===0 解包后 data 为分页结构，页面取 data.items）：

{
  "code": 0,
  "message": "ok",
  "request_id": "8f1c2a9e-...",
  "data": {
    "items": [
      {
        "id": "3c0f0a1e-2b9d-4e6f-8a2b-5d7c1e0a9f3b",
        "username": "alice",
        "name": "",
        "email": "",
        "is_locked": false,
        "created_at": "2026-09-07T04:59:00+08:00",
        "roles": [
          {
            "id": 2,
            "role_name": "developer",
            "permissions": [
              { "id": 3, "role_id": 2, "permission_type": "ACTION_ACCESS", "resource_name": "deployment:read" },
              { "id": 4, "role_id": 2, "permission_type": "ACTION_ACCESS", "resource_name": "agent:read" }
            ]
          }
        ]
      },
      { "id": "7f2b...", "username": "admin", "name": "Administrator", "email": "admin@zyinfo.pro", "is_locked": false, "created_at": "2026-08-01T10:00:00+08:00", "roles": [ { "id": 1, "role_name": "platform_admin", "permissions": [ { "id": 1, "role_id": 1, "permission_type": "ACTION_ACCESS", "resource_name": "*:*" } ] } ] }
    ],
    "total": 2,
    "page": 1,
    "page_size": 20
  }
}

字段含义（userView 安全视图，toUserView 生成）：id 用户 uuid 主键；username 登录名（表内唯一）；name/email 可选（omitempty，未设置不出现，前端以 - 兜底）；is_locked 是否被锁定；created_at 创建时间；roles 该用户全部角色（Preload 关联，每项为 model.Role：id、role_name、permissions[]）。安全视图刻意剔除 HashedPassword、FailedLoginAttempts 等敏感字段——前端拿不到密码哈希，列表接口无泄漏面。

POST /users（201 Created）：

{ "code": 0, "message": "ok", "request_id": "…", "data": { "id": "3c0f0a1e-…", "username": "alice" } }

GET /roles（envelope 解包后为裸数组，区别于 /users 的 {items,...}）：

[
  { "id": 1, "role_name": "platform_admin", "permissions": [ { "id": 1, "role_id": 1, "permission_type": "ACTION_ACCESS", "resource_name": "*:*" } ] },
  { "id": 2, "role_name": "developer", "permissions": [ … ] }
]

POST /users/:id/roles（200）：data = {"user_id":"3c0f…","role_id":2}；若 body 里 role_id 缺省/为 0，返回 400（code:40001，message「role_id 不能为空」）。DELETE /users/:id/roles/:roleId（200）：data = {"user_id":"3c0f…","role_id":2,"deleted":true}；无绑定记录返回 404（code:40401 类，message「用户角色绑定不存在」）。

错误示例（409 用户名已存在）：HTTP 409，body {"code":40901,"message":"用户名已存在","request_id":"…"}（statusToCode 映射见 api.go）。前端经拦截器把 message 转写进 err.response.data.error，页面提示「创建用户失败：用户名已存在」。

5.4 关键机制

认证与权限点匹配。全部本页端点挂在 /api/v1 的 protected 组：先 access.Authn（Bearer JWT 或 X-API-Key，见 middleware.go；前端 apolloClient 仅取 apollo_token），再从 principal 解析有效权限集合，RequirePerm 做包含匹配——命中即放行，*:* 通配全部。非超管用户的有效权限 = 其全部角色的 role_permissions（permission_type='ACTION_ACCESS'）中 resource_name 的并集（resolvePermissions 还支持「跨产品 JWT 的 user id 在本库不存在时，用 username（sub，签名防篡改）反查本库同名用户」兜底）。把「分配角色」挂在 role:write 而非 user:write 是刻意的权限点边界：绑定/解绑语义属于「角色资源的授权管理」，因此只发 user:read/user:write 的账号无法执行分配（403），想要分配能力的角色须同时含 role:write（内置 platform_admin/project_admin 因 *:* 天然具备）。

envelope 与前端解析差异。成功响应统一 envelope；okPage 把列表包装成 {items,total,page,page_size}，而 ok 直接把数组/对象放进 data——这就是 GET /users 页面读 data.items、GET /roles 页面用 Array.isArray(data) 判断的原因。handleListUsers 虽支持 ?page=&page_size=，但服务端每次都返回全量（ListUsers 无 LIMIT），前端拿全量后再过滤/切片，PAGE_SIZE=10 仅是显示切片。用户量极大时首屏与每次刷新都会传整表（见 8 章）。

列表数据血缘。ListUsers 用 Preload("Roles").Order("username") 一次取出全部用户并带角色；userView 小写序列化；前端兼容层兜底 PascalCase。表格里的角色标签、权限计数都来自这个 roles[]——也就是创建用户在列表刷新前看不到自己、分配角色后行内角色标签立即更新都依赖每次成功写操作后的 fetchUsers() 全量重拉。

写操作语义：幂等绑定 vs 404 解绑。AssignRoleToUser 先查用户/角色存在（用户不存在/角色不存在），再用 ON CONFLICT (user_id,role_id) DO NOTHING 创建关联——重复绑定不报错；RemoveRoleFromUser 直接 Delete 并按 RowsAffected==0 判 404「用户角色绑定不存在」→ 不可重复解绑。前端差分算法（4.6）配合这套语义：toAdd 循环幂等、toRemove 循环要求目标确实存在。

审计。根路由组挂了 httpAuditMiddleware（http_audit.go）：对全部 API（含本页端点）异步落 apollo_audit_logs。请求体（JSON/YAML/text 类）与查询串入库前脱敏：password/token/secret/api_key 等键值替换为 ***，>2KB 截断；action = METHOD path（如 POST /api/v1/users）；resource_type = 路径首段（users/roles）；路径含 :id 参数时记录 resource_id；结果判定 2xx→success、401/403→denied、其余 4xx/5xx→failure。创建用户的密码字段在审计里永远以 *** 呈现，不落明文。探针与 /docs 噪声路径跳过。

锁定状态（is_locked）来源。platform/auth 登录逻辑（auth_service.go）：普通账号连续 5 次登录失败、admin 语义账号（platform_admin 等）连续 10 次失败 → IsLocked=true 并记 ACCOUNT_LOCKOUT 审计（admin 锁定额外输出安全告警日志，见 auth_service.go:134-153）。差异化在于 admin 锁定后仍可用正确密码登录并自动解锁（:166-175），普通用户锁定期间连正确密码也被拒、只能改库恢复；而本页没有解锁/重置密码入口（无对应路由）——这是账号安全与可用性之间的已知缺口（见 8 章）。

权限匹配语义（Authorize）：Authorize 对 principal 的有效权限集合做 glob 匹配（access.PermissionMatch），命中形态有三档——集合里存在与目标 resource:action 完全相等的权限点、存在 resource:* 类资源前缀通配（授出 user:* 可同时命中 user:read/user:write）、或存在全集通配 *:*（超管，Authorize 先判 IsSuper 直通，不做逐条扫描）。推论：在「角色管理」页里只勾 user:read 不会顺带获得 user:write——因为页面权限网格只下发单个权限点，不提供 user:* 中间档，二者必须分别勾选；但若有人绕过页面经 POST /roles 给角色写了一条 user:*，则该角色覆盖 user 域全部动作。授权面能否按 read/write 拆分，取决于下发的是单点还是资源前缀通配，本页网格可保证的最小粒度是单点。platform_admin 与 project_admin 的 *:* 之所以能覆盖本页全部动作，正是这条「全集通配」判定；给角色手工加 *:* 需谨慎——那等于把账号层全部读写权交出去，操作会落审计，可在审计页反查授权者与授权时间。

6. 权限与安全

• 认证分层：页面访问、列表读、写操作全部要求登录（Bearer）；未登录跳登录页，token 过期由拦截器统一清态重登。
• 权限点：读 user:read/role:read，写 user:write/role:write；无权限时 403 且拦截器 alert('无权限执行该操作')。页面入口不按权限隐藏——无 user:read 的用户照样能打开本页，只是接口全 403，提示以「…失败」展示。
• 敏感字段不外泄：列表安全视图不含密码哈希/失败次数；审计中密码以 *** 脱敏；页面永远拿不到可逆的凭据。
• 写操作防护：唯一写操作创建账号与角色绑定/解绑，均有权限点约束；解绑走 confirm 二次确认；saving/creating 互斥位防连点并发。
• 超管语义：platform_admin/project_admin 通过 *:* 获得本页全部能力；给普通账号授超管角色的入口在「角色管理/分配角色」链路，操作会落审计，可按审计页追溯授权者。

7. 常见问题与排错

以下现象均由 UsersPage.vue 各 catch 分支提示与后端 handler/service 代码归纳，均可按步骤复现或溯源。

1. 打开页面列表空白并提示「加载用户列表失败：无权限执行该操作」：原因是当前账号无 user:read 权限点（403）。处理：换 platform_admin/project_admin 账号或让超管先在「角色管理」为该账号补 user:read；403 时拦截器会先弹「无权限执行该操作」，这是同一次失败的两条提示，属预期。

1. 点「新建用户」提示「创建用户失败：用户名已存在」：原因是该用户名已在 Apollo 用户库存在（用户名唯一）。处理：换用户名；注意 Apollo 是独立用户库，与 AIP/Foundry 的账号不互通，登录过 AIP 不代表 Apollo 有同名用户。

1. 新建用户成功后列表里姓名/邮箱是「-」：原因是后端 createUserRequest 只有 username/password 两个字段（弹窗内 modal-hint 已说明），姓名/邮箱无入口可填。处理：属已知边界（见 8 章），不影响登录与授权；如需姓名/邮箱展示需后端扩展字段并同步前端。

1. 分配角色弹窗空白，提示「暂无可用角色，请先到「角色管理」创建。」：原因是 GET /roles 返回空数组（角色表为空）。处理：先到「角色管理」页创建角色（或确认 seed 未跑导致内置角色缺失）；候选加载失败则提示「加载角色列表失败：{错误}」，核对 18082 与 token。

1. 点「保存」报「保存角色失败（部分变更可能已生效，已按服务端状态刷新）：用户不存在/角色不存在」：原因通常是弹窗打开期间目标账号被删、或差分基准过期（本地列表快照 vs 服务端不一致）。处理：本批起失败会自动重拉列表并把弹窗勾选对齐到服务端真实结果（UsersPage.vue:301-315），确认提示后按刷新后的勾选基线重试即可；绑定接口幂等，重按保存不会重复加角色。

1. 点「×」移除角色失败，提示「移除角色失败：用户角色绑定不存在」：原因是该绑定已在别处（另一会话/另一管理员）被移除，或当前列表是旧数据。处理：刷新列表确认现状；DELETE 语义要求绑定真实存在，重复移除必 404。

1. 有 user:write 却无法分配角色（403）：原因是绑定走的是 role:write 权限点，不是 user:write。处理：到「角色管理」给该账号所在角色补 role:write，或用内置超管角色执行。

1. 状态列显示「已锁定」但想恢复登录：原因是连续登录失败触发自动锁定（普通账号 5 次、admin 语义账号 10 次），而本页及全站均无解锁/重置密码入口。处理：由管理员直接改 Apollo 用户库把 is_locked 置回 0（并清 failed_login_attempts），或让该账号持有 admin 语义角色后用正确密码登录自动解锁；这是已知缺口（见 8 章）。

1. 搜索框输入中文查不到预期用户：原因是过滤对三字段做小写包含匹配，中文按子串匹配本身可用，但姓名/邮箱通常为空无法命中——用「用户名」片段搜最稳。处理：确认关键字与任一列文本一致；关键字过滤纯前端，不改服务端查询。

1. 列表出现「…」截断的 ID，想拿完整 ID：原因是 shortId 只显示前 12 位。处理：本页无详情入口；如需完整 id 直接调 GET /api/v1/users（受保护，需 token）看原始返回，或在浏览器 Network 里查看 /users 响应体。

1. 按钮停在「提交中...」/「保存中...」长时间不动：原因是 creating/saving 互斥位在请求返回前保持禁用态（防连点重复提交），若后端未返回（网络断/超时 30s）会一直转。处理：看 Network 面板该请求是否挂起，超时或报错后互斥位自动复位即可继续操作；属前端互斥保护而非死锁。

1. 刷新页面后刚才勾选的角色又变回旧值：原因是弹窗勾选只是本地状态，未点「保存」不会发任何请求，刷新即丢弃。处理：改动后必须点「保存」并确认出现「角色已更新：新增 N 个，移除 N 个」提示；未保存就离开是预期丢弃，不会产生脏数据。

8. 已知缺陷与边界

与 AIP /admin/users（UsersPage.vue）的差异对照

两页同名「用户管理」，但分属两套产品/后端，能力集差异很大，跨产品切换前先看下表：

对已熟悉 AIP 管理后台的读者，最需要记住的三点差异：Apollo 页不能删除/锁定/重置密码（不提供按钮且后端无路由）；创建用户只有账号与密码；分配角色走差分批量保存而非单勾即存。

附录 A：页面文案与关键常量速查

附录 A：页面文案与关键常量速查