项目管理

1. 页面概览

1.1 是什么

「项目管理」页（对应前端源码 action/web/src/views/apollo/ProjectsPage.vue，页面标题「Apollo 项目管理」，TAD-11 批次 2 平台管理组）是 LightApollo 的项目治理与成员归属管理页：创建项目（如 core-pay）、浏览全量项目列表，并在每行内联展开「项目成员」子表，完成添加成员（从用户下拉 + 角色下拉中选择）与移除成员。项目（projects 表）是 Apollo 各业务资源的归属边界——环境、Git 仓库、同步目标、制品、流水线、监控、告警、安全、配置等模块的资源全部注册在 /api/v1/projects/:id/... 路径下；项目成员（project_members 表）则是「谁能访问该项目名下资源」的数据范围载体。因此本页治理的对象不是单个资源本身，而是「资源往哪个项目里装、谁能进出这个项目」。

本页在整个 Apollo 运维闭环中处于第一层「组织与范围」位置：在使用任意资源类页面之前，通常需要先有一个项目承载，并需要把操作用户登记为该项目的成员。后端对项目作用域资源的访问采用「权限点 + 成员归属」双重门槛（详见 5.4）：先由 RequirePerm 校验登录主体具备读/写该类资源的权限点（由平台角色授予，如 project:read/project:write），再经 projectScopeAccessGuard 中间件校验「该主体是此项目的成员（或 super admin 直通）」——两个条件任一不满足即拒绝。而本页的「项目列表/创建项目」自身不带项目作用域（/projects 路径），因此凡具备 project:read/project:write 权限点的用户都能看到全部项目并创建新项目；但要看某个项目的成员、往里加人，就必须先成为该项目的成员。这就形成了一个清晰的第一性约定：项目的第一个成员只能由 super admin（或其他已是成员的操作者）添加，之后成员可以继续拉人。

典型使用链路（从零到有、完整闭环）：① 平台管理员（super）登录后在本页点「新建项目」，填项目名（如 core-pay）与描述，创建成功提示 项目已创建 id=1；② 列表出现该项目（此时「成员」列显示 0 人）；③ 点该项目行的「添加成员」，弹窗中从「用户（user_id）」下拉选一个已存在用户、从「角色（role_id）」下拉选该项目内角色（如 developer），点「添加成员」提交，提示 成员已添加；④ 点项目行展开成员子表，可看到该成员的用户 ID、角色名（role_name（#id））、添加人与加入时间，并可在子表内点「移除」把它请出项目（有确认框）；⑤ 此后该成员登录 Apollo 时，即可访问该项目名下带权限点对应的资源（环境/制品/流水线等模块会对它放行成员校验），而非本项目成员则只能看到项目名、不能触碰项目内任何资源。

从「项目作用域」看，本页的治理覆盖面实际上很大：后端把环境管理（/environments）、Git 仓库（/git-repos）、同步目标（/sync-targets）、制品与清理策略（/artifacts、/cleanup-policies）、流水线（/pipelines）、监控配置与健康检查（/monitoring-config、/health-checks）、告警与事件单（/alert-rules、/alert-events、/incidents、/silences）、安全策略与漏洞（/security-policies、/vulnerabilities）、配置模板与密钥（/config-templates、/secrets）等大类、几十条端点全部注册在 /api/v1/projects/:id/... 前缀之下（见 server.go 794-981 行路由注册），并统一接受 projectScopeAccessGuard 的成员校验；而期望状态、发布渠道、部署策略、签名者白名单、Spoke Agent 等属于「全局资源」，注册在 /projects 前缀之外，只受权限点约束、不参与项目成员隔离。所以本页「添加成员」这个动作的真实含义，是一次性打开该用户对目标项目下全部模块的数据访问范围——它是高权限操作，源码也在移除时用 confirm 二次确认来降低误操作风险，日常应只交给可信平台管理员与项目负责人执行。

本页只读数据（项目列表、用户下拉、角色下拉、成员列表）全部在同一批 Promise 中并行发起（onMounted 同时触发 fetchProjects 与 fetchLookups；fetchLookups 内部再串行两个请求），任一失败只在提示条报错、不影响其余部分渲染（如用户下拉失败但项目列表正常）。也就是说页面并不依赖「先有项目才能拉用户」的时序，二者数据各自独立成环，展示层仅在打开弹窗那一刻才把两组下拉与当前行数据拼装到一起。

1.2 核心价值/能力表

1.3 一句话总结

本页是 Apollo 资源归属与数据范围的第一道闸门——建项目、登记成员、指派项目内角色，谁在哪个项目里、担任什么角色在此统一维护，资源级权限由各业务模块在此基础上自理。

2. 访问入口

2.1 路由与菜单

访问方式：登录 Apollo 后从左侧菜单「平台管理 → 项目管理」进入，或直接访问 /apollo/admin/projects。相邻页（侧边栏顺序）：API Key 管理 admin-api-keys.md（前）、审计日志 admin-audit-logs.md（后）；概念对照：用户管理 admin-users.md（页面用户下拉的数据来源）、角色管理 admin-roles.md（页面角色下拉的数据来源与平台角色语义）。

2.2 认证与权限

• 路由 requiresAuth: true：未登录访问被前端路由守卫拦到 /apollo/login（登录态为独立 apollo_token，2026-09-12 修订后仅认 apollo_token，不再回退读取旧 aip_token）。
• 全部本页端点位于 server.go 的 protected 组，先经 access.Authn 解析 Bearer JWT / X-API-Key 注入主体，再逐条 RequirePerm 校验权限点：
  • GET /projects、GET /projects/:id/members → PermProjectRead（project:read）；
  • POST /projects、POST /projects/:id/members、DELETE /projects/:id/members/:memberId → PermProjectWrite（project:write）；
  • 用户下拉 GET /users → PermUserRead（user:read）；角色下拉 GET /roles → PermRoleRead（role:read）。
• 成员归属二次门槛：/projects/:id/... 路径资源还会命中 projectScopeAccessGuard，非 super 主体必须是该项目成员，否则 403（详见 5.4）。
• 401（apollo_token 失效）由响应拦截器清 token 并跳 /apollo/login；403 统一 alert('无权限执行该操作')，页面把 err.response?.data?.error || err.message 展示到提示条。

2.3 端口与 API 前缀

• Apollo 后端端口 18082。Vite 开发代理把 /apollo-api 前缀 rewrite 为 /api 转发（后端路由注册在 /api/v1），客户端 baseURL /apollo-api/v1。
• 统一响应 envelope {code,message,data,request_id}：拦截器在 code===0 时把 response.data 解包为业务数据，页面 const { data } = await apiClient.get(...) 直接拿业务数组/对象。
• 本页六个端点的业务数据形态：/projects、/projects/:id/members、/roles 为裸数组；/users 为 {items,total,page,page_size} 分页对象（后端实为全量返回，见 5.3 备注）；创建类端点返回 {id, ...} 对象。

3. 界面布局

┌────────────────────────────────────────────────────────────────┐
│ Apollo 项目管理                                  [新建项目]    │
│ [alert 操作结果提示条（v-if alert.message，含「关闭」）]        │
├────────────────────────────────────────────────────────────────┤
│ ┌ 新建项目弹窗（modal-overlay + modal-card，@click.self 可关）┐ │
│ │ 新建项目  [关闭(link-btn)]                                 │ │
│ │ 项目名（name）*   <input placeholder「如 core-pay」>        │ │
│ │ 描述（description）<textarea rows=3「项目用途、边界等（可选）」│ │
│ │ [创建项目/创建中...] [取消]                                │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌ 项目列表（加载中… / 空态 / 表格三态）────────────────────────┐ │
│ │ 表头：ID | 名称 | 描述 | 创建人 | 创建时间 | 成员 | 操作      │ │
│ │ 行（clickable-row，展开高亮 row-selected）：                 │ │
│ │   id  name  描述或-   created_by或-  时间   成员(N人) [添加成员]│ │
│ │ ╞══ 展开行（detail-row, colspan=7）═════════════════════════╡ │ │
│ │ │ 项目成员（N）[inner-table]                               │ │
│ │ │   用户（user_id）| 角色 | 添加人 | 加入时间 | 操作          │ │
│ │ │   (行内 [移除]，空态「暂无成员，点击"添加成员"邀请。」)     │ │
│ │ ╞══════════════════════════════════════════════════════════╡ │ │
│ │ ┌ 添加成员弹窗（modal，@click.self 可关）─────────────────┐ │ │
│ │ │ 添加成员到项目 "{name}"  [关闭(link-btn)]               │ │
│ │ │ 用户（user_id）*  <select 请选择用户>                   │ │
│ │ │ 角色（role_id）*   <select 请选择角色>                  │ │
│ │ │ [添加成员/添加中...] [取消]                             │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘

各板块职责：

4. 交互元素

4.1 页头、操作结果提示条

页面用一组 ref 维护状态：projects（项目数组）、membersMap（{项目id: 成员数组} 字典，只缓存已展开过的项目）、users/roles（两个下拉选项数据）、expandedId（当前展开行项目 id）、loading（列表初次加载位）、busy（全部写操作共享的互斥位）、alert（单槽提示）、createModal/createForm、memberModal/memberForm。所有写操作（创建项目/添加成员/移除成员）共用 busy：任一进行中，两个弹窗的提交按钮与「移除」按钮同时禁用。

4.2 「新建项目」按钮与新建项目弹窗

表单字段表（新建项目弹窗）：

4.3 项目列表与行点击展开

4.4 添加成员弹窗（用户/角色下拉）

4.5 成员展开行与「移除」按钮

4.6 数据加载与会话级细节

页面挂载顺序（onMounted）：fetchProjects()（项目列表）与 fetchLookups()（用户/角色下拉）先后同批启动。loading 只控制项目列表卡片的三态切换（加载中.../空态/表格）；用户/角色下拉没有自己的加载态，首次打开「添加成员」弹窗时若两个请求尚未返回，下拉只会显示一个「请选择用户/请选择角色」占位项——此时直接提交会被前端守卫拦下（请选择用户/请选择角色）。fetchLookups 内部是串行 await：先 GET /users 再 GET /roles，且两个请求分别用 try/catch 包裹，谁失败只提示谁，不影响另一个。

busy 是页面唯一的写互斥位：创建项目、添加成员、移除成员三处共用。请求进行中提交按钮置灰并显示进行中文案；由于 Vue 的响应式赋值发生在 await 前后，同一弹窗内连点不会发出两个请求。要留意两个异步窗口：其一，请求在途时弹窗已被 closeModal 守卫锁住（「关闭/取消/遮罩」三处入口在 busy 时直接 return 并提示「请求进行中，请稍候」，且按钮 :disabled="busy"，见 8 章）——本批修复后不再出现「弹窗已关但请求仍在提交」以及重开时的「假忙」观感；其二，expandedId 高亮、membersMap 缓存与 busy 互不干扰——移除成员进行中仍可点击其它行展开，只是该行「移除」按钮与「添加成员」提交按钮因 busy 置灰。

另外「成员」列的计数与子表标题、空态文案都取自同一个 membersMap[p.id]：展开过的项目在移除最后一人后，空态文案 暂无成员，点击"添加成员"邀请。 会立即出现；收起重开后计数回到 0，逻辑一致。全部时间列（创建时间/加入时间）展示格式为去掉 T、截取前 19 位的本地化弱化格式（如 2026-08-30 02:15:00），若后端返回空字符串则整格显示 -。

4.7 表单提交前校验与通用失败分支

两个表单提交在发请求前各自有前端守卫（handleCreate 检查 name trim 非空否则 项目名必填；handleAddMember 检查 user_id 非空否则 请选择用户、role_id 非 0 否则 请选择角色）。所有写操作成功后都会刷新受影响的列表数据：创建项目刷新项目列表、添加/移除成员刷新对应 membersMap[projectId]（展开行就地更新，无需收起重开）。所有失败统一走 catch → 提示条 ...失败：{errMsg}（errMsg 优先取 err.response.data.message || err.response.data.error || err.message）。由于 busy 是共享互斥位，提交按钮在请求期间变灰且文字切换为 创建中.../添加中...，防止连点重复提交；两个弹窗的「关闭/取消/遮罩」也已由 closeModal 在 busy 时一并锁住（ProjectsPage.vue:211-224，见 8 章）。

5. 后端关联

5.1 API 客户端

action/web/src/api/apolloClient.js：axios 实例 baseURL /apollo-api/v1、timeout 30000ms、请求拦截器对所有请求附加 Authorization: Bearer <token>（token 仅取 apollo_token，不回退 aip_token）。响应拦截器：HTTP 2xx 且 code===0 时把 response.data 解包为业务数据（页面 const { data } = ... 直接得到业务对象/数组）；HTTP 2xx 但 code!==0 拒绝；4xx/5xx 提取 body.message || body.error 并把 message 别名写入 error.response.data.error 后 reject——401 清 token 并跳 /apollo/login（登录页自身 401 不跳，避免死循环），403 alert('无权限执行该操作')。页面 catch 统一以 err.response?.data?.error || err.message 兜底取错。

5.2 端点表

注册位置：action/products/apollo/server/server.go protected 组（828-832 行 projects 五条、811/818 行 users/roles）；handler 在 handlers.go（handleListProjects/handleCreateProject/handleListProjectMembers/handleAddProjectMember/handleRemoveProjectMember，1625-1725 行）。/projects/:id/... 路径经 protected 组的 projectScopeAccessGuard（718-722 行注册）。

5.3 响应结构示例

GET /projects（envelope 解包后为裸数组）：

[
  {
    "id": 1,
    "name": "core-pay",
    "description": "核心支付域：订单/账务/清算",
    "created_by": "admin",
    "created_at": "2026-08-30T02:15:00.123+08:00",
    "updated_at": "2026-08-30T02:15:00.123+08:00"
  }
]

字段含义（access.Project，access/models.go）：id 自增主键；name 项目名（uniqueIndex，唯一）；description 描述（可空）；created_by 创建人用户名（后端写 currentUsername）；created_at/updated_at 时间戳。列表按 id 升序。

POST /projects（201，envelope 解包后）：

{ "id": 1, "name": "core-pay" }

页面据此提示 项目已创建 id=1。创建类端点统一 HTTP 201；重名返回 409（code: 40901，message 项目已存在）；空名返回 400（message 项目名不能为空）。

GET /projects/:id/members（envelope 解包后为裸数组）：

[
  {
    "id": 5,
    "project_id": 1,
    "user_id": "2a3f9b7c-1c6e-4d4a-8f20-3e5c2d1a0b99",
    "role_id": 3,
    "added_by": "admin",
    "created_at": "2026-08-30T03:00:00+08:00"
  }
]

字段含义（access.ProjectMember）：id 成员记录主键（移除时用这个 id）；project_id 所属项目；user_id 用户主键字符串（用户表主键为 UUID 字符串）；role_id 角色 ID（引用 roles 表，不存角色名）；added_by 添加人用户名；created_at 加入时间。表有 (project_id, user_id, role_id) 复合唯一索引，同项目同用户同角色只允许一条。

GET /users（envelope 解包后为分页对象）：

{
  "items": [
    {
      "id": "2a3f9b7c-1c6e-4d4a-8f20-3e5c2d1a0b99",
      "username": "alice",
      "is_locked": false,
      "created_at": "2026-08-25T10:00:00+08:00",
      "roles": [ { "id": 3, "role_name": "developer", "permissions": [] } ]
    }
  ],
  "total": 3,
  "page": 1,
  "page_size": 20
}

字段含义（userView，server/handlers.go 1405 行）：id 用户主键字符串；username 用户名；name/email 个人姓名/邮箱（omitempty，可缺省）；is_locked 是否锁定；created_at；roles 角色数组（omitempty）。注意：/users 虽套 {items,total,page,page_size} 分页壳，后端 handleListUsers 始终把全量用户放入 items 并令 total=len(views)，page/page_size 只是回显——即无论传不传分页参数，下拉选项都是全量（前端只取 data.items，不做前端分页）。

GET /roles（envelope 解包后为裸数组）：

[
  { "id": 1, "role_name": "platform_admin", "permissions": [] },
  { "id": 2, "role_name": "project_admin", "permissions": [] },
  { "id": 3, "role_name": "developer", "permissions": [] }
]

字段含义（model.Role）：JSON 键为 role_name（非 name；前端 r.role_name || r.name 双兼容）；permissions 权限点数组。角色主键 id 即 ProjectMember.role_id 的取值来源。

5.4 关键机制

项目成员归属隔离（projectScopeAccessGuard）。这是「项目作为数据范围边界」的后端执行点：中间件挂在 protected 组（server.go 718-722 行），对命中 /api/v1/projects/:id[/...] 前缀的全部路径解析出项目 id 后执行 checkProjectAccessible——登录主体为 super admin 直接放行；否则查 project_members 表是否登记 (project_id, user_id)，未登记返回 403 无权访问项目 {id} 的资源（非项目成员）。因此本页 GET/POST /projects/:id/members 也会被该守卫拦截：非 super 用户想查看/添加某项目成员，自己必须先在该项目里；/projects（列表/创建，无 /:id）与 /users、/roles 不在该前缀下，不受成员校验，只走权限点。

成员记录主键语义。ProjectMember.id（自增）与 user_id（UUID 字符串）是两回事：移除成员时 DELETE /projects/:id/members/:memberId 的 :memberId 是成员记录 id（前端遍历 m.id 传入）；后端 RemoveProjectMember 按主键查删，无记录返回 404 项目成员不存在。因此同一用户在不同项目、甚至同项目不同角色都有独立的成员记录 id，删除互不影响。

添加成员的三段校验与幂等。前端先拦截空选（请选择用户/请选择角色）→ handler 校验 body 非空（400 user_id/role_id 不能为空）→ accessSvc.AddProjectMember 依次校验项目/用户/角色存在（任一不存在 404 项目不存在/用户不存在/角色不存在）→ 写入时用 (project_id,user_id,role_id) 复合唯一键 OnConflict DoNothing 幂等（重复添加静默成功、不报错、不新增行）。AddedBy 记录添加人用户名，形成可审计的「谁拉谁进哪个角色」轨迹。

用户下拉的数据兼容（大写/小写键）。源码注释沿用了旧版「/users 返回无 json tag 的 model.User、键为大写」的假设，故 userId()/userName() 分别兼容 u.ID || u.id || u.user_id 与 u.Username || u.username || userId(u)。实测当前后端经 toUserView 输出的小写键 id/username 已被前端读取——双兼容代码保证无论后端将来回到大写结构也不破。

角色下拉与角色反查。成员表只存 role_id；页面挂载时拉一次 GET /roles 全量角色（roles 数组），下拉与子表 roleName() 都从这个缓存反查显示 role_name（#id）。若 role_id 在缓存中找不到（角色已被删除或列表未加载完），子表回退显示裸 #id——页面上「角色变裸 id」通常意味着角色数据源缺失，而非成员数据异常。

懒加载成员与成员计数。列表初次只加载项目；首次点击行才 GET /projects/:id/members 并缓存进 membersMap[projectId]，重复展开不再请求。成员计数列与子表标题的 N 都直接取 (membersMap[p.id] || []).length——未展开过行的项目显示 0 人；一旦展开过就显示缓存值（此后增删成员会刷新该缓存）。由于新增/移除都发生在展开态，页面会自动刷新对应项目缓存，计数即时正确。

时间与空值展示约定。formatTime(t) 对 RFC3339/ISO 串做 replace('T',' ').replace('Z','').slice(0,19) 展示（如 2026-08-30 02:15:00），不转浏览器本地时区；空值统一显示 -。描述/创建人/添加人空值分别显示 -。

角色 id 与全局角色库（跨项目共享）。role_id 引用的是平台级角色库（platform/model 的 model.Role，即「角色管理」页维护的那批平台角色，如 platform_admin/project_admin/developer/operator/viewer），项目之间共享同一套角色主键，不存在「每个项目各自一套角色」的概念。因此在本页添加成员时，角色下拉出现的是平台全部角色；给不同项目成员选同一 role_id，展示出来的角色名完全一致。从后端执行看，projectScopeAccessGuard 目前只校验「是否为成员」而不校验成员记录的 role_id——真正决定某成员能读还是能写某类资源的是该用户经 user_roles 全局授予的权限点（由「用户管理」页分配）。也就是说本页下拉里选的「项目内角色」此刻更多是组织语义标签（告诉读者该成员在项目内承担 project_admin/developer 等职责），并未参与按项目细分的读写判定；若产品后续要做「同一资源对不同项目成员按 role 分级放行」，需要在 guard 与各资源 handler 增加 role 维度判定，当前尚未实现（见 8 章）。对照这一机制，日常给成员派角色时建议与实际平台角色保持一致，避免标签与真实权限错位造成误解。

错误码速查。本页涉及的失败统一走 envelope（HTTP 状态码 + code/message），速查如下：

前端 errMsg() 优先读 err.response.data.message，其次 err.response.data.error（拦截器写入别名），再退 err.message，最后 未知错误。

6. 权限与安全

• 认证分层：全部端点 protected，access.Authn 解析 JWT 或 API Key；无效凭据 401，前端清 token 跳登录页。
• 权限点门禁：project:read/project:write 管项目本体与成员读写，user:read/role:read 管下拉数据；由内置平台角色（platform_admin/project_admin/developer/operator/viewer 等）按 RBAC 授予。
• 成员归属隔离：项目作用域资源叠加 projectScopeAccessGuard，super 直通、非成员 403——页面自身可被只读角色打开，但非项目成员的操作会被成员校验拦下。
• 写操作防护：移除成员前原生 confirm 二次确认（提示将被移除的用户 id）；所有写操作共享 busy 互斥防连点；创建项目对 name 做前后端双重非空校验。
• 数据暴露边界：项目列表与成员下拉会对具备权限点的登录用户返回用户全名/角色名等身份信息，属平台管理范畴的正常读取；/users 返回的 userView 已剔除密码哈希与登录失败计数等敏感列。

7. 常见问题与排错

以下现象均由 ProjectsPage.vue 的提示分支、后端 handler/accessService 代码与既有测试归纳，均可按步骤复现。

1. 现象：创建项目提示 项目已存在。 原因：projects.name 唯一索引，重名时 handler 预检命中返回 409（code 40901，message 项目已存在）。处理：换一个项目名；先在列表确认是否有同名项目。

2. 现象：点「创建项目」提示 项目名必填。 原因：name 输入为空或全空格，前端 createForm.name.trim() 判空拦截。处理：填非空项目名（placeholder 示例 如 core-pay）；若填了仍报，检查是否误输全角空格——后端 trim 空同样 400 项目名不能为空。

3. 现象：点「添加成员」没反应或提示 添加成员失败：...。 原因：常见于用户/角色下拉未加载（GET /users/GET /roles 失败、缺 user:read/role:read 权限被 403）、或后端校验项目/用户/角色不存在（404）。处理：先确认 Network 面板 users/roles 两个请求是否 200；确认目标用户已在用户管理页存在、角色在角色管理页存在；若为非 super 账号，还需确认自己已是该项目成员（成员校验 403 无权访问项目 ... 的资源）。

4. 现象：点「移除」后成员还在列表里。 原因：若提示 移除成员失败 通常是 :memberId 传错（应传成员记录 id m.id）或记录已被他人删除（404 项目成员不存在）。处理：核对源码 handleRemoveMember 传 m.id；刷新展开行确认后端是否真的删除成功。特别提醒：confirm 弹窗里展示的是 user_id，但实际删除按成员记录 id 生效——同用户在同一项目有多条角色记录时，删除只去掉被点的那条。

5. 现象：子表「角色」列显示裸 #3 而不是角色名。 原因：roles 下拉数据里找不到该 role_id——角色被删除，或 GET /roles 未加载成功（权限 403 / 接口失败被 catch）。处理：刷新页面重载 roles；到角色管理页确认该角色仍存在；角色删除后遗留成员会一直显示裸 id（见 8 章）。

6. 现象：未展开的项目行「成员」列恒显示 0 人，展开后数量才对。 原因：成员数是前端 membersMap 缓存的长度，行未展开时从未请求成员接口。处理：点击行展开即懒加载显示真实数量；这是页面既有的展示边界（见 8 章），不是数据丢失——到 GET /projects/:id/members 可核对真实成员。

7. 现象：下拉里找不到刚在用户管理页新建的用户。 原因：fetchLookups 只在页面挂载（onMounted）时拉一次 users/roles；新建用户后本页的下拉还是旧快照。处理：刷新页面重新进入；无手动「刷新下拉」按钮（见 8 章）。

8. 现象：明明有 project:write 权限，操作某个项目仍被 403。 原因：命中项目成员归属校验——非 super 用户对 /:id 项目资源还必须是该项目成员。处理：由 super 或现有成员先把你加进该项目；或确认当前是否有成员校验 403 的 message（无权访问项目 N 的资源（非项目成员））。

9. 现象：页面只能看到项目列表，点任何写按钮都弹 无权限执行该操作。 原因：当前登录主体缺 project:write（或 user:read/role:read）权限点，RequirePerm 返回 403，拦截器统一弹窗提示。处理：到「用户管理」页给该用户授予含对应权限点的平台角色（如 project_admin 通常含项目读写），刷新页面重试。

10. 现象：另一位管理员刚加了成员，本页展开后计数对不上。 原因：membersMap 是前端会话级缓存，只在首次展开与本次增删操作后刷新；他人通过另一会话/另一入口（如直接调 API）改动成员时本页不会感知。处理：收起再重新展开该行会重新请求一次；或整页刷新（见 8 章「缓存过期」）。

8. 已知缺陷与边界

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