制品管理

1. 页面概览

1.1 是什么

「制品管理」页（对应前端源码 action/web/src/views/apollo/ArtifactsPage.vue，页面标题「Apollo 制品管理」）是 LightApollo 控制面的构建产物登记与版本治理中心，后端对齐 TAD-04「制品元数据管理」。制品（Artifact）在此采用「元数据注册」的自研轻量实现：页面并不上传文件本体，只登记 name / version / type / storage_backend / storage_path / size_bytes / sha256 / git_commit_sha / git_branch 等元数据到 artifacts 表，把「这条产物叫什么、是谁的哪个版本、放哪、多大、指纹多少」记录下来；在此基础上页面还提供标签体系（行内打标/删标）、部署历史回看（谁在哪次同步被部署到哪个环境）与清理策略（按 scope + 保留版本数/天数/标签批量淘汰历史版本）。

在整个 Apollo 产品的流程中，本页处于「流水线产出 → 制品沉淀 → 部署引用 → 过期回收」的制品生命环上：上游 CI/CD 流水线（pipelines 页）跑完一轮构建后，其产物以元数据形式登记为本页一条制品（后端字段 ci_pipeline_run_id、bundle_id 预留关联）；下游部署若命中制品并写入 artifact_deployments 部署引用，就会把「该制品在某环境经某次 sync 被部署」记下来，从而让本页「部署历史」有据可查（注意：该写入的接线当前尚未在业务链路闭环，详见 5.4 与第 7 章问题 5/6）；当制品版本不断累积，本页「立即清理」会按当前项目的清理策略（Cleanup Policy）把过期版本连同本地物理文件一并回收。输入是制品元数据与清理策略，输出是制品列表、可追溯的部署引用与回收统计。

需要特别区分的是 Apollo 里两套「产物」概念：本页管理的是制品仓库（轻量元数据，登记型、面向长期沉淀的制品库）；而「制品与渠道」页（/apollo/bundles，BundlePage.vue）管理的 bundle 是可验签分发的最小单元（打包文件 + digest + SM2 签名，面向发布下载）。两者通过制品表的 bundle_id（指向 bundles.id）与 storage_path="bundle://{digest}" 连接键关联——bundle 被登记到制品仓库后，其本体引用统一以 bundle:// 表达，删除这类制品不会删 bundle 本体（详见第 5 章）。

典型使用链路（演示视角）：① 先在某处产出产物（如流水线构建或手工打包），拿到底层文件的字节数/SHA256/Git 提交等元数据；② 本页点「注册制品」填名称（如 pay-service）、版本（如 v1.2.0）、类型（二进制/镜像/Helm/文件包）、存储后端等，落库后在列表可见该制品；③ 对线上制品行内补标签（如 prod、release），用「部署历史」回看被哪些部署引用过；④ 配置清理策略（如 scope=pay-service、保留最近 3 个或 30 天内），点「立即清理」批量回收过期版本；⑤ 若制品要作为可分发 bundle，则在「制品与渠道」页构建 bundle 后再回本页登记（或由后端自动登记），本页负责长期留存与引用保护。

1.2 核心价值/能力表

1.3 一句话总结

制品管理页把「构建产物登记、标签维护、部署引用追溯、策略化清理」收敛为 Apollo 制品仓库的轻量入口——先登记元数据、再看被谁引用、最后按策略回收，是本产品所有可分发产物的「名册」所在。

2. 访问入口

2.1 路由与菜单

访问方式：登录 Apollo 后从左侧菜单「制品管理」进入，或直接访问 /apollo/artifacts。相邻页：上游是 git-repos.html（Git 仓库，制品来源之一），下游是 pipelines.html（CI/CD 流水线）；分发侧见 bundles.html（制品与渠道，bundle 概念对照）。

2.2 认证与权限

• 路由 requiresAuth: true，无 guest 白名单：未登录访问会被前端路由守卫拦到 /apollo/login。Apollo 控制面使用独立的 apollo_token（localStorage），向后兼容无 apollo_token 时回退读取旧 aip_token。
• 后端各制品端点全部注册在 protected 组并按权限点细粒度控制：读操作（列表/详情/部署历史/搜索/版本/策略查询）要求 PermArtifactRead（artifact:read）；写操作（注册/删除/标签增删/策略增删改）要求 PermArtifactWrite（artifact:write）；清理执行（POST /projects/:id/cleanup/run）要求 PermArtifactExecute（artifact:execute）。权限点缺失返回 HTTP 403。
• 403 由 apolloClient 响应拦截器统一 alert('无权限执行该操作')；401 时拦截器清除 apollo_token 并跳转 /apollo/login（登录页自身 401 不跳转，避免死循环）。

2.3 端口与 API 前缀

• Apollo 后端端口：18082；Vite 开发服务器把 /apollo-api 前缀代理到该后端。
• 客户端 baseURL：/apollo-api/v1（apolloClient.js）；统一 envelope {code, message, data, request_id}。
• 项目 id：页面暂用常量 PROJECT_ID = 1（default 项目），全部制品/策略端点落在 /projects/1/...；/artifacts/:id/... 全局资源端点不带项目段。
• 辅助接口：环境下拉走 GET /projects/1/environments，仅用于部署历史弹窗把 environment_id 翻译成环境名，失败不阻塞页面。

3. 界面布局

┌───────────────────────────────────────────────────────────┐
│ Apollo 制品管理                                [注册制品]    │
│ [alert-info 顶部说明：制品为"元数据注册"（TAD-04 自研轻量）]   │
│ [操作结果提示条（v-if alert.message，右上角「关闭」）]          │
├───────────────────────────────────────────────────────────┤
│ ┌ 清理策略（Cleanup Policy）卡片 ──────────────────────────┐ │
│ │ 标题 + [编辑策略] [立即清理]                              │ │
│ │ （加载中 / 空态：暂无清理策略，点击"编辑策略"创建 / 策略信息） │ │
│ └─────────────────────────────────────────────────────────┘ │
│ [搜索框：按名称 / 版本 / sha256 / 标签搜索制品...][搜索][清空]  │
├───────────────────────────────────────────────────────────┤
│ ┌ 制品列表卡片 ────────────────────────────────────────────┐ │
│ │ （加载中 / 空态 / 表格三态）                               │ │
│ │ ID 名称 版本 类型 大小 SHA256 标签 漏洞扫描 创建人 创建时间 操作 │ │
│ │ 操作列：标签输入+打标签 | 部署历史 | 删除                    │ │
│ └─────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────┤
│ ┌ 注册制品弹窗 modal ┐ ┌ 编辑清理策略弹窗 modal ┐             │
│ └───────────────────┘ └ 部署历史弹窗 modal（modal-lg）┘      │
└───────────────────────────────────────────────────────────┘

4. 交互元素

4.1 「注册制品」按钮（页头）

4.2 注册制品弹窗与表单

弹窗标题为 注册制品（项目 #1），右上「关闭」；表单 @submit.prevent 提交，含必填「名称」「版本」等字段，全部字段如下：

提交按钮文案随忙碌态切换：busy === 'saveArtifact' 时显示「保存中...」并禁用，否则显示「注册」；另有一个 type="button" 的「取消」按钮直接关闭弹窗。点击「注册」（handleSaveArtifact）：

1. 先前端校验 name/version 非空，否则弹错误「名称（name）与版本（version）必填」并中止；
2. 置 busy='saveArtifact'，POST /projects/1/artifacts（payload 见上表）；
3. 成功：从 data?.id || data?.artifact?.id 取新 id，提示 制品注册成功（id=N）（alert-success），关闭弹窗并 fetchArtifacts() 刷新列表；
4. 失败：提示「注册制品失败：<错误信息>」，弹窗不关闭、表单保留可修改重试；
5. finally 清空 busy。

后端行为：同项目下（project_id, name, version）复合唯一，重复注册返回 HTTP 409 ARTIFACT_CONFLICT；类型/存储后端不在白名单返回 400；created_by 为空时后端用当前登录用户名填充。

4.3 搜索框与「搜索」「清空」按钮

后端搜索实现是 name LIKE '%kw%'（仅名称字段，第 5 章说明）——placeholder 声称的范围（名称/版本/sha256/标签）与真实能力不一致，见第 7 章问题 4。

4.4 制品列表表格与空态

列表表头：ID | 名称 | 版本 | 类型 | 大小 | SHA256 | 标签 | 漏洞扫描 | 创建人 | 创建时间 | 操作。行渲染细节：

toList 解析：data 为数组直接返回；否则取 data.items 数组；都不是返回空数组——适配后端 data 裸数组与分页 {items,...} 双形态。表格行以 a.id 为 key。列表加载失败（fetchArtifacts catch）会提示「加载制品列表失败：...」并把 artifacts 置空数组（见第 8 章）。

4.5 行内打标签（标签输入 + 「打标签」）

4.6 标签 chip 上的「×」（删除标签）

4.7 「部署历史」按钮与弹窗

弹窗内表格列：ID | 部署时间 | 同步历史 ID | 环境 | 状态：部署时间取 deployed_at 优先、created_at 兜底（formatTime）；同步历史 ID 在 sync_history_id / sync_id / history_id 间取首个非空，空显示 -；环境用 environment_id / environment / env_id 经 envLabel 翻译；状态 d.status || 'success' 并套 deployStatusClass 徽标。后端 artifact_deployments 表本身无 status 字段，故状态列实际恒显示绿色「success」（见第 8 章缺陷）；环境名依赖 GET /projects/1/environments 下拉，找不到该 id 时退化为 #<id>。弹窗遮罩点击与「关闭」均可退出。

4.8 「删除」制品按钮

4.9 清理策略卡片与「编辑策略」按钮

顶部卡片标题 清理策略（Cleanup Policy），右上「编辑策略」「立即清理」两按钮（均 :disabled="!!busy"）。卡片主体三态：

策略信息格（label 均为后端字段名 + 中文）：作用范围（scope）/ 保留版本数（keep_count）/ 保留天数（keep_days）/ 保留标签（keep_tags）/ 启用（enabled）。keep_count ?? '-'、keep_days ?? '-' 用空值合并；keep_tags 数组 join , ，字符串原样，空显示 -；enabled 徽标：false 显示 disabled（灰 status-offline），否则 enabled（绿 status-online）。

「编辑策略」→ openEditPolicy()：以当前 policy（无则空对象）回填表单并打开策略弹窗。表单初始值来自策略字段；enabled 勾选默认 p.enabled !== false（即只要不是显式 false 都视为启用）。

4.10 清理策略弹窗（新建 / 编辑 / 删除）

弹窗标题：有策略时 编辑清理策略 #{id}（项目 #1），无策略时 新建清理策略（项目 #1）。字段如下：

底部按钮：有策略时出现红色「删除策略」（handleDeletePolicy，先 window.confirm('确定删除清理策略 #{id} 吗？') 再 DELETE /cleanup-policies/:id，成功提示「清理策略已删除」并关闭弹窗刷新）；另有「取消」「保存」（保存中显示「保存中...」）。

「保存」（handleSavePolicy）分支：policy.value?.id 存在则 PUT /cleanup-policies/:id 并提示 清理策略 #N 更新成功；否则 POST /projects/1/cleanup-policies，从 data?.id || data?.policy?.id 取新 id 提示 清理策略创建成功（id=N）。失败统一提示「保存清理策略失败：...」。成功后关闭弹窗并 fetchPolicy() 刷新卡片。注意「更新」与「创建」的判定依据是卡片当前策略，不是弹窗中 id。

4.11 「立即清理」按钮

5. 后端关联

5.1 API 客户端

5.2 端点表（路由注册见 server/server.go 与 server/artifact_handlers.go）

5.3 响应结构示例

制品列表响应（GET /projects/1/artifacts，经 apolloClient 解包后页面拿到的即为 data 数组）：

{
  "code": 0,
  "message": "ok",
  "data": [
    {
      "id": 1,
      "project_id": 1,
      "name": "pay-service",
      "version": "v1.2.0",
      "type": "binary",
      "storage_backend": "local",
      "storage_path": "1/pay-service/v1.2.0/pay-service",
      "size_bytes": 10485760,
      "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "tags": ["prod", "release"],
      "git_commit_sha": "a1b2c3d4",
      "git_branch": "main",
      "ci_pipeline_run_id": 0,
      "bundle_id": 0,
      "vulnerability_scan_status": "unscanned",
      "created_by": "admin",
      "created_at": "2026-08-30T10:00:00+08:00",
      "updated_at": "2026-08-30T10:00:00+08:00"
    }
  ],
  "request_id": "req_1724992800000ab12"
}

制品记录字段字典（Artifact 模型，artifacts 表）：

时间展示说明：时间字段是 RFC3339 带时区格式。页面 formatTime 仅做三次字符处理——T→空格、去掉 Z 字符、slice(0,19) 截前 19 位——不做任何时区换算。效果是：无论后端落的是 UTC（Z 结尾）还是本地偏移（如 +08:00，后端 JSON 常带毫秒如 2026-09-06T02:47:07.8813266+08:00），页面都只显示其日期+时刻的「字面值」，时区与毫秒一律截掉。演示若全部由本机后端生成（本地时区写入）则观感正常；一旦接入跨时区或 UTC 落库的数据源，展示的就是「后端本地时刻」而非浏览器本地时间（见第 8 章「时间展示无时区换算」）。

清理执行响应（POST /projects/1/cleanup/run，后端 CleanupResult）：

{
  "code": 0,
  "message": "ok",
  "data": {
    "scanned": 12,
    "deleted_artifacts": 3,
    "freed_bytes": 5242880,
    "skipped_referenced": 1,
    "skipped_tagged": 2,
    "skipped_recent": 4,
    "policy_used": "project",
    "policy_enabled": true
  },
  "request_id": "req_1724992800000cd34"
}

字段含义：scanned 扫描的制品总数；deleted_artifacts 实际删除数（前端以 removed_count/deleted_count/... 别名读取，核心即此值）；freed_bytes 释放字节数；skipped_referenced 被部署引用强制保留数；skipped_tagged 命中 keep_tags 保留数；skipped_recent 命中 keep_days 保留数；policy_used 使用的作用域（project）；policy_enabled 策略是否启用。

清理策略对象（GET/POST/PUT 均返回同构）：

{
  "code": 0,
  "message": "ok",
  "data": {
    "id": 1,
    "project_id": 1,
    "scope": "*",
    "keep_count": 3,
    "keep_days": 30,
    "keep_tags": ["prod"],
    "enabled": true,
    "created_at": "2026-08-30T10:00:00+08:00",
    "updated_at": "2026-08-30T10:00:00+08:00"
  },
  "request_id": "req_1724992800000ef56"
}

制品部署历史响应（GET /artifacts/:id/deployments，后端 ArtifactDeployment，id 升序；sync_history_id 可空、非 GitOps 触发部署为 0，deployed_at 为空时页面回退 created_at）：

{
  "code": 0,
  "message": "ok",
  "data": [
    {
      "id": 1,
      "artifact_id": 2,
      "sync_history_id": 11,
      "environment_id": 2,
      "deployed_at": "2026-08-30T11:00:00+08:00",
      "created_at": "2026-08-30T11:00:00+08:00"
    },
    {
      "id": 2,
      "artifact_id": 2,
      "sync_history_id": 0,
      "environment_id": 1,
      "created_at": "2026-09-01T09:30:00+08:00"
    }
  ],
  "request_id": "req_1724992800000a0f1"
}

注意（重要）：当前版本 artifact_deployments 通常没有数据——写入它的 RegistryService.RecordDeployment 只有单元测试调用，GitOps 引擎与 HTTP handlers 尚未接线（wiki 标注「部署引用 ◐ 未闭环」）。页面「部署历史」弹窗与上方示例是预留展示位；演示时该接口大概率返回空数组，前端显示「该制品暂无部署记录。」，不代表页面故障（见第 7 章问题 5/6）。

注册请求 payload（buildArtifactPayload 产物，POST /projects/1/artifacts，供比对后端 RegisterRequest 字段）：

{
  "name": "pay-service",
  "version": "v1.2.0",
  "type": "binary",
  "storage_backend": "local",
  "storage_path": "/artifacts/pay-service/v1.2.0.tar.gz",
  "size_bytes": 10485760,
  "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "git_commit_sha": "a1b2c3d4",
  "git_branch": "main",
  "tags": ["prod", "release"]
}

注意：storage_path 在请求里是手工填写的描述性路径；若请求带 file_data（base64）后端才会真正落盘并回写计算出的相对路径/SHA256/大小。type/storage_backend 均必填合法值（后端空 type 兜底 file_package、空 backend 兜底 local）；metadata/ci_pipeline_run_id/bundle_id 等扩展字段页面表单未暴露，仅 API/服务层支持。

5.4 关键机制

元数据注册与唯一约束。artifacts 表以 (project_id, name, version) 复合唯一索引兜底，同一项目下同名同版本只能登记一次；重复注册在服务层与数据库两层都拦为 HTTP 409 ARTIFACT_CONFLICT（错误文案「制品 X:Y 已存在」）。服务层同时校验：名称/版本非空（400）、类型在白名单（docker_image/binary/helm_chart/file_package）、存储后端在白名单（后端合法值为 local/harbor/minio/aliyun_oss）。vulnerability_scan_status 注册时恒为 unscanned，后续由安全合规相关接口（POST /artifacts/:id/scan、/sbom 等，PermSecurityExecute）更新——本页只读展示该字段。注册接口实际也支持 file_data（base64 字节）把文件本体写入 data/artifacts/{project}/{name}/{version}/{file} 并自动算 SHA256/大小/路径，但前端表单不上传文件，仅以元数据方式登记；若带文件，后端会对 name/version/fileName 做路径段安全校验（拒绝空段、.、..，防路径穿越），并把分隔符替换为 _。

搜索语义。/projects/:id/artifacts/search 的后端实现仅 name LIKE '%<q>%' 一条过滤（q 为空返回项目全量），不匹配 version/sha256/tags——与前端 placeholder「按名称 / 版本 / sha256 / 标签搜索制品...」所暗示的范围不一致（见第 7 章问题 4 与第 8 章缺陷）。

清理策略语义与 Cleanup 执行链。项目清理策略以 (project_id, scope='project') 为键、每项目至多一条有效策略（本页只展示 list[0]）。执行清理（Cleanup）时：① 先幂等补齐默认策略（EnsureDefaultPolicy：不存在则建 keep_count=10、keep_days=0、keep_tags=[]、enabled=true）——这就是「从未配置也能立即清理」的原因；② 若策略 enabled=false 直接返回零统计，不删任何制品；③ 把制品按 name 分组、组内按 CreatedAt 降序（ID 降序破平），逐组圈定四类强制保留：命中 keep_tags（任一标签交集）、keep_days 保留期内新建、被 artifact_deployments 引用（referencedArtifactIDs Distinct 查询）、每 name 最近 keep_count 个；④ 其余候选先删物理文件（StoragePath 空或 bundle:// 前缀不删本地文件，removeFile best-effort 清理空目录）再删元数据行；⑤ 统计返回 CleanupResult。清理为项目级一次性同步执行（无后台任务、无调度），页面刷新列表即可看到被清理的版本消失。

部署引用与 bundle 关联。artifact_deployments 表由后端服务方法 RegistryService.RecordDeployment(artifactID, syncHistoryID, environmentID) 写入一行（artifact_id + sync_history_id + environment_id + deployed_at，sync_history_id 可空、非 GitOps 触发时记 0），被引用的制品在清理时强制保留，避免「正在线上使用的版本被回收」。需要如实说明的是：当前版本该方法只有单元测试调用，GitOps 包与 server handlers 均未接入（wiki 文档标注「部署引用 ◐ 未闭环」），因此 GET /artifacts/:id/deployments 在生产通常返回空——页面「部署历史」弹窗是为该能力预留的展示位，待 GitOps 联动落地后生效（见第 7 章问题 5/6）。

清理判定——一个完整的小例子。假设策略 scope=*、keep_count=2、keep_days=0、keep_tags=["prod"]、enabled=true，同项目制品表里 pay-service 名下先后有 v1.0.0、v1.1.0、v1.2.0、v1.3.0 四行（创建时间递增，即 v1.3.0 最新），其中 v1.2.0 打了 prod 标签、v1.3.0 被一条 artifact_deployments 引用。执行「立即清理」时后端按 name 分组、组内按 created_at 降序（ID 降序破平）排列后单遍打标：v1.3.0 同时命中「keep_count 前 2」「被引用」两个条件、v1.2.0 同时命中「keep_count 前 2」「keep_tags=prod」，v1.1.0/v1.0.0 位于第 3、4 位且无其它保留理由 → 判为过期，先删物理文件再删元数据行。结果提示「清理完成：清理 2 个版本，释放 X」，v1.2.0/v1.3.0 留在列表。注意 keep_count 是「组内最近 N 个全保」而不是「扣掉强制保留后补 N 个」——四种保留条件是并集关系。若把 keep_days 改为 30 而 v1.1.0/v1.0.0 都在 30 天内新建，则它们又命中 keep_days 保留，结果变成「清理 0 个版本」——这正是问题 3 里「点清理却什么都没删」的常见成因。制品与 bundle 的关联走两条通道：bundle_id 列直接指向 bundles.id，或 storage_path="bundle://{digest}" 表达 bundle 本体连接键——删除制品时 handler 见 bundle:// 前缀即跳过物理文件删除，保证不会误删 bundle 分发本体（bundle 有自己的生命周期清理，见「制品与渠道」页）。

部署历史字段形态。ListDeployments 直接查 artifact_deployments 行，逐行 JSON 仅含 id/artifact_id/sync_history_id/environment_id/deployed_at/created_at，没有 status；前端状态列 d.status || 'success' 因而恒显示成功。环境名列无法从行数据得知名字，前端用预取的 /projects/1/environments 列表做 id→name 翻译。

audit 审计。制品关键写操作均在 handler 层记审计：注册 ARTIFACT_CREATE、删除 ARTIFACT_DELETE、执行清理 ARTIFACT_CLEANUP_RUN（含 project_id/name/version/deleted/freed_bytes 明细），可在「审计日志」页追溯。

6. 权限与安全

• 认证分层：全部制品端点挂 protected 组，JWT/登录态失效返回 401，前端响应拦截器清 token 跳 /apollo/login；无 apollo_token 时回退 aip_token 属向后兼容设计，新环境建议统一用 Apollo 独立登录。
• 权限点隔离：读（artifact:read）/写（artifact:write）/执行（artifact:execute）三权分离——「立即清理」是唯一需要 execute 权限点的操作，普通可读可写角色若缺 execute 会在点击时被 403 拦截。
• 写操作防护：删除制品、删除策略、立即清理均走 window.confirm 二次确认；busy 全局互斥防重复提交（忙碌中所有行按钮置灰）。
• 路径与数据安全：后端对制品 name/version/文件名的路径段做消毒与穿越校验（sanitizeSegment + validateSegment），防止写文件越出 data/artifacts 根目录；删除策略/清理对物理文件的删除均有目录归属校验，bundle:// 引用不连带删除 bundle 本体。制品元数据中可能含 sha256/Git 提交等供应链信息，对外导出/截图分享时按需脱敏。
• 审计留痕：注册/删除/清理均有 AUDIT 记录（带操作者、对象、明细），可在审计日志页回溯谁在何时删改了制品或执行了清理。

7. 常见问题与排错

问题 1：注册制品时选择 S3 / 镜像仓库 / OSS 等存储后端被后端拒绝

• 现象：选了「S3」或「镜像仓库（registry）」或「OSS」点「注册」，提示「注册制品失败：非法存储后端 "s3"」。
• 原因：前端下拉的选项值 s3 / registry / oss 与后端存储后端白名单 local / harbor / minio / aliyun_oss 不一致（前端 STORAGE_BACKENDS 选项名与后端 validStorageBackends 枚举对不上），只有 local、minio 两者能通过后端校验。
• 处理：当前需先选「本地存储（local）」或「MinIO」完成登记（storage_path 可手工填远端路径表达意图）；该不一致已在缺陷报告中登记，等待前后端统一枚举（第 8 章）。

问题 2：注册同名同版本制品被拒（ARTIFACT_CONFLICT）

• 现象：点「注册」提示「注册制品失败：项目 1 下制品 pay-service:v1.2.0 已存在」或「制品 pay-service:v1.2.0 已存在」。
• 原因：(project_id, name, version) 复合唯一，重复登记由服务层与数据库唯一索引双重拦截为 HTTP 409。
• 处理：换一个新版本号（如 v1.2.1）登记；若确需覆盖旧定义，先「删除」旧制品再登记（无版本升级语义）。

问题 3：点「立即清理」后提示「清理完成：清理 0 个版本」且没删任何东西

• 现象：确认执行后结果提示清理 0 个版本、释放 0。
• 原因：策略被停用（enabled=false，后端直接跳过执行）；或当前制品都在保留范围内（命中 keep_tags/keep_days/被部署引用/每名最近 keep_count 个）。
• 处理：去「编辑策略」确认「启用该策略」勾选状态与各阈值；若只是想验证，把 keep_count 调小/keep_days 置 0 后重跑，或查看后端审计 ARTIFACT_CLEANUP_RUN 的 deleted 明细。

问题 4：搜索时输入了版本号或 sha256 却搜不到

• 现象：按 placeholder 提示输入版本（如 v1.2.0）或 sha256 关键字点「搜索」，列表提示「未搜索到匹配的制品。」。
• 原因：后端搜索实现是 name LIKE '%q%'，只匹配名称字段；输入非名称关键字自然无结果（符合后端契约，但与界面提示的范围不符）。
• 处理：改用制品名称关键字搜索；需要按版本/sha256/标签检索时，暂用「清空」后人工在列表定位，或后续等后端搜索能力扩展。

问题 5：部署历史提示「该制品暂无部署记录」

• 现象：点「部署历史」弹窗显示空态。
• 原因：该制品从未被任何部署引用写入 artifact_deployments（见问题 6——当前版本后端 RecordDeployment 尚无业务调用方，部署记录通常就是空的），或部署记录表中确实无 artifact_id 匹配行。
• 处理：先确认该制品确实被部署过（部署与漂移页查看对应 sync 历史）；制品表与部署记录都只删不更，若记录确实存在但弹窗为空，检查浏览器 Network 中 /artifacts/:id/deployments 的响应是否为数组/{deployments} 形态。

问题 6：制品确实被部署了，但部署历史仍为空

• 现象：在部署与漂移页对某制品对应的环境执行过 sync，回本页看「部署历史」仍是空态。
• 原因：写入 artifact_deployments 的 RegistryService.RecordDeployment 目前只有单元测试调用，GitOps 引擎与 HTTP handlers 都还没有接线（wiki 标为「◐ 未闭环」）；无论同步成功与否，当前版本都不会自动产生制品部署引用行。
• 处理：这不是页面操作错误。可先用后端 deploy-history/sync-history 类命令或部署与漂移页确认同步本身成功；制品部署历史能力需待 GitOps 联动落地后才有数据（该页弹窗为预留展示位）。

问题 7：删除制品/删除策略/立即清理点下去没反应或提示无权限

• 现象：点击后无对话框，或弹出「无权限执行该操作」。
• 原因：浏览器拦截了原生 window.confirm（如被 iframe/设置禁用）时点击无反应；403 则是当前账号缺少 artifact:write（删除）或 artifact:execute（清理）权限点。
• 处理：确认账号在角色管理中被授予对应权限点；原生 confirm 被禁时改用直连 API（携带 apollo_token）验证，页面功能本身依赖 confirm 确认。

问题 8：部署历史弹窗的「环境」列显示成 #2 这类编号而不是环境名

• 现象：部署历史有数据时，环境列只显示 #<数字>，看不到环境名称。
• 原因：envLabel 用 environment_id 去 GET /projects/1/environments 预取的列表里查找；后端没配任何环境、环境下拉失败（fetchEnvironments 静默降级为空数组）、或部署记录引用的环境已被删除时，找不到匹配项就退化显示 #<id>（找到则显示「名称（#id）」）。
• 处理：先到环境管理页确认存在至少一个环境且与部署记录里的 environment_id 对应；刷新本页重新加载；若环境确被删除，该历史行的环境名无法还原，属正常兜底。

8. 已知缺陷与边界