制品与渠道

1. 页面概览

1.1 是什么

「制品与渠道」页（对应前端源码 action/web/src/views/BundlePage.vue，页面标题「Apollo 制品与渠道」）是 LightApollo 的可验签分发中枢。它把发布链路上最关键的三种对象收在同一个页面里：bundle 制品（用户在浏览器选若干文件，经 multipart 上传由后端打包签名、登记成带 digest 与签名者指纹的制品记录）、发布渠道（release channel）（把 bundle 绑到「发布给谁」的语义——渠道指向一条期望状态后，Spoke Agent 的 Pull 目标选择就能以 stable 渠道为准来拉取）、部署策略（deployment policy）（用一段 rules JSON 描述「部署该怎么跑」——是否自动回滚、并发上限、就绪超时、退避参数）。页面上半部是构建 bundle 表单与 bundle 制品列表，下半部是左右并排的渠道卡与策略卡，各自独立做创建、编辑、删除与（渠道独有）指向期望状态。

需要先分清本页与相邻页的对象关系：期望状态（desired state）在部署侧创建与激活（YAML 声明，见 deployments 页）；bundle 是本页构建的「带签名、可验签的分发最小单元」，一个期望状态在激活时通常要关联某个 bundle 的 digest（desired_states.digest，G7 连接键）；渠道在本页把「发布目标」绑定到某条期望状态上（current_desired_state_id），并把 promotion/approval 两个策略字段作为 JSON 存起来；策略在本页维护部署行为规则，实际生效在部署编排 Advance 阶段按策略名解析。而「制品管理」页（/apollo/artifacts）的制品仓库走另一套轻量元数据登记，与 bundle 通过 artifacts.bundle_id / storage_path="bundle://{digest}" 关联——本页是打包本体所在，制品页只是登记引用。

典型使用链路（演示视角的完整闭环）：① 首次构建时后端若发现签名者白名单里还没有 demo-signer 的真实公钥，会自动生成一套 SM2 演示密钥并把它 upsert 进白名单（幂等，指纹 = SM3(公钥)），因此「开箱即可签名、开箱即可验签」；② 在「构建 bundle」表单填应用（如 order-service）、版本（如 1.0.0），点「+ 文件行」追加若干文件行并选定本地文件，文件行的「路径」输入框决定该文件在 bundle 内的路径（留空回退用文件名），点「构建 bundle」提交 multipart；③ 后端打包（逐文件 SM3 校验和进清单）→ 计算整体 digest（SM3 规范化 manifest + 按路径排序的文件字节）→ 用演示 SM2 私钥对 digest 签名 → 落盘到 ./temp/apollo_bundles/<digest> 并登记 bundles 表，页面提示 bundle 构建成功 id=… digest=…；④ 在 bundle 制品列表点「验签」，后端从落盘目录读回制品逐项校验（逐文件 SM3 / digest / 白名单信任锚 / SM2 签名），结果弹窗展示 files_ok / digest_ok / signature_ok / trusted，行内出现「可信/不可信」徽标；⑤ 点「下载 zip」拿到 manifest.json + digest.sig + files/… 归档（文件按 bundle-{id}-{app}-{version}.zip 命名），供真实 Spoke 侧下载后自行 LoadBundleFromDir 校验应用；⑥ 回到页面下半部，为某渠道在「指向期望状态」下拉里选一条 active 期望状态，或新建 stable/dev 渠道并把 promotion/approval 策略 JSON 填进去；⑦ 新建/编辑 default 部署策略控制 auto_rollback 等行为——到此「制品签名 → 渠道指向 → 策略放行」的发布前准备即告完成，之后即可在部署页发起部署，让 Agent 按本页固化的声明去拉取应用。

1.2 核心价值/能力表

1.3 一句话总结

2. 访问入口

2.1 路由与菜单

访问方式：登录 Apollo 后从左侧菜单「制品与渠道」进入，或直接访问 /apollo/bundles。相邻页（侧边栏顺序）：配置管理 configs.html（前）、Spoke Agent agents.html（后）；概念对照：制品管理 artifacts.html（制品仓库 / bundle 概念区分）、部署与漂移 deployments.html（期望状态创建激活、bundle digest 关联、部署推进）。

2.2 认证与权限

• 路由 requiresAuth: true：未登录访问被前端路由守卫拦截并跳转 /apollo/login（登录态为独立 apollo_token，2026-09-12 修订后不再回退旧 aip_token）。
• 全部本页端点位于 server.go 的 protected 组，经 access.Authn 解析 Bearer JWT / X-API-Key 后逐条 RequirePerm 校验权限点：
  • bundle：读用 PermBundleRead，写/验签/清理用 PermBundleWrite；
  • 渠道：读 PermChannelRead，创建/更新/删除/指向 PermChannelWrite；
  • 策略：读 PermPolicyRead，创建/更新/删除 PermPolicyWrite；
  • 期望状态下拉：读 PermDesiredStateRead。
• 401（apollo_token 失效）由响应拦截器清 token 并跳转 /apollo/login；403 统一 alert('无权限执行该操作')。注意：验签在语义上是只读诊断，但后端要求 PermBundleWrite——只有读权限的只读角色点「验签」会收到 403（见 7.4）。

2.3 端口与 API 前缀

• Apollo 后端端口 18082。Vite 开发代理把 /apollo-api 前缀 rewrite 为 /api 转发（后端路由注册在 /api/v1），apolloClient baseURL /apollo-api/v1，即前端请求 /apollo-api/v1/bundles → 后端 /api/v1/bundles。
• 统一响应 envelope {code,message,data,request_id}：拦截器在 HTTP 2xx 且 code===0 时把 response.data 解包为业务数据，页面 const { data } = await apiClient.get(...) 直接拿业务对象。
• blob 例外：bundle 下载走 responseType:'blob'，拦截器对 blob/arraybuffer 原样放行、不解析 envelope（下载 zip 场景）。

3. 界面布局

+------------------------------------------------------------------+
| Apollo 制品与渠道（h2 页头）                                       |
| [操作结果提示条 v-if alert.message：{{alert.message}}  [关闭]]     |
+------------------------------------------------------------------+
| [构建 bundle 卡]                                                  |
|   应用（app）* | 版本（version）* | bundle_version * | 签名者(signer)|
|   制品文件（文件键为 bundle 内路径）            [+ 文件行]          |
|     [路径输入][file 选择][已选文件名][删除] ×N                    |
|   [构建 bundle / 构建中...]（busy 禁用）                          |
+------------------------------------------------------------------+
| [bundle 制品卡]                                                   |
|   ID|名称|应用|版本|bundle_version|digest|签名者指纹|大小|验签|操作 |
|     （digest/指纹：shortDigest 悬停全文；名称列 b.name||b.app）  |
|     验签列：[验签] [可信/不可信徽标]  操作列：[下载 zip]            |
+------------------------------------------------------------------+
| [发布渠道（channels）卡]  |  [部署策略（policies）卡]  ← 左右并排   |
|   创建表单（名称/描述/promo/approval）+[创建渠道]                  |
|   ID|名称|指向期望状态|操作       ID|名称|规则|操作                |
|   指向期望状态=[select: 未指向(0)│#id name...]                     |
|   操作=[编辑][删除]            操作=[编辑][删除]                   |
+------------------------------------------------------------------+
| [编辑渠道弹窗] [编辑策略弹窗] [验签结果弹窗]  @click.self 可关      |
+------------------------------------------------------------------+

各板块职责：

页面无独立「加载中」骨架屏：数据未到时表格区为空，写操作进行中由按钮 busy 文案体现（构建中.../保存中...）；四份数据任一接口失败被 .catch(() => ({data:[]})) 静默降级，不弹错误（见 7.10）。

4. 交互元素

4.1 页面标题与操作结果提示条

页面用一组 ref 维护状态：四个列表 bundles/channels/policies/desiredStates、全局互斥位 busy、提示 alert、验签结果缓存 verifyMap（键 = bundle id）与三个弹窗 verifyModal/channelEditModal/policyEditModal。所有写操作共用 busy：任一进行中，构建按钮、验签、下载、渠道/策略的创建与编辑保存按钮全部 :disabled="busy"，防止并发写把列表状态弄乱；只有「删除」用 window.confirm 前置确认。

4.2 「构建 bundle」表单

构建表单字段 → 后端：FormData 组装顺序为 app、version、bundle_version（String(bundle_version || 1)）、可选 signer，随后每个文件以「其 bundle 内路径」为键逐条 fd.append(path, file)。后端 handleCreateBundle 先读 app/version（trim 空 → 400 app/version 不能为空），parseInt(bundle_version, 1) 兜底，再 parseFormFiles 解析全部上传文件——所以「文件键即 bundle 内路径」是该接口的第一语义：multipart 字段名不是固定文件名，而是发布时制品在 bundle 里的相对路径。

4.3 bundle 制品列表与「验签」

bundle 制品卡标题 bundle 制品。bundles.length===0 时居中灰字空态 暂无 bundle，请构建一个。；有数据显示表格，列头依次 ID / 名称 / 应用 / 版本 / bundle_version / digest / 签名者指纹 / 大小 / 验签 / 操作。列表由后端按 id 降序返回（最新构建在最上）。

验签行为（handleVerify）：点「验签」→ busy=true → POST /bundles/:id/verify（无请求体）。成功时把解包后的结果对象存入 verifyMap[b.id] 并打开验签弹窗：标题 验签结果（bundle #{id}），正文 <pre class="code-block">{{ JSON.stringify(result, null, 2) }}</pre> 深色代码块完整展示 {files_ok, digest_ok, signature_ok, trusted, signer_name} 逐项结果。失败时不红条、而是同样打开弹窗：verifyMap[b.id] = { trusted:false, error: ... } 且弹窗内容为 { error: 错误信息 }，行内徽标因此显示红底 不可信——即「验签失败也展示」（如 403 VERIFY_SIGNER_NOT_TRUSTED），这不是页面 bug 而是设计取舍：让用户看得见「为什么不可信」。失败后点开弹窗只能看到错误串，看不到四步明细（后端错误分支不返回部分成功项，见 5.4）。

4.4 「下载 zip」

下载实现：拿 blob → URL.createObjectURL → 构造隐藏 <a> 设 download → 点击 → 移除节点 → revokeObjectURL。后端把落盘目录（manifest.json + digest.sig + files/<path>…）整树 walk 进 zip，Content-Disposition: attachment; filename="{BundleID}.zip"；前端 override 后实际保存名总带记录 id，避免同名 bundle 覆盖本地文件。注意：拦截器对 blob 原样放行，因此下载成功与否完全看 HTTP 状态——若记录文件已被后端清理策略删除，后端打包阶段报 打包 bundle 失败: ...（500）。

4.5 渠道创建表单与渠道列表（含指向期望状态）

「发布渠道（channels）」卡顶是创建表单（两行四个输入 + 按钮），下方 channel-table 渠道表格，列头 ID / 名称 / 指向期望状态 / 操作。列表由后端 id 升序返回（软删行自动过滤）。

创建渠道表单字段表：

渠道行内控件：

指向期望状态的结果语义：切换下拉 → busy=true → POST。选 未指向(0) 时先 confirm 解除指向；成功提示 渠道 "{name}" 已指向期望状态 #{desired_state_id}（选 0 时提示 已解除指向（未指向任何期望状态））（success）并刷新；失败提示 指向失败：{msg}（选 0 时 解除指向失败：{msg}）且也刷新一次（让下拉回到后端实际值）。后端中 desired_state_id=0 直接清空指向（幂等），非 0 要求目标期望状态存在且 status=active（审批流未过审的也不行，见 IsApprovedForDeploy），否则 400 期望状态 N 未激活（当前状态 X），不可作为通道期望状态（hub/channel.go:153-181）。渠道指向变化会直接影响 Agent 的 Pull 目标选择（见 5.4 渠道机制）。

4.6 「编辑渠道」弹窗

channelEditModal.visible 为 true 时以 modal-overlay 覆盖层出现，点遮罩（@click.self）或「关闭」可关。标题 编辑渠道 "{{current.name}}"。

注意与创建的差异：后端 UpdateChannel 只更新描述与两个策略（name 参数在 handler 里根本没传），策略字段传空对象/空串时是幂等跳过而非清空——因此想用编辑弹窗把某个已填的策略清掉是做不到的（源码只对 trim 非空才 parse、后端也只对非空更新），这是「无法清空策略字段」边界（见 8 章）。

4.7 策略创建表单与策略列表

「部署策略（policies）」卡顶创建表单（名称 + rules + 按钮），下方表格列头 ID / 名称 / 规则 / 操作，列表 id 升序。

默认规则说明：新建策略不填 rules（或后端发现 rules 为空）时，后端把 DefaultPolicyRules() 序列化落库——即 {"auto_rollback":true,"max_concurrent":2,"readiness_timeout_sec":60,"reconcile_backoff":{"initial_s":5,"multiplier":2,"max_s":300}}。因此本页创建的每条策略保存后都会带一套完整 JSON，而非空对象。

4.8 「编辑策略」弹窗与「验签结果」弹窗

编辑策略弹窗（policyEditModal）：标题 编辑策略 "{{current.name}}"；字段表：

验签结果弹窗（verifyModal）：标题 验签结果（bundle #{id}），正文 <pre class="code-block">{{ JSON.stringify(result, null, 2) }}</pre>，result 为验签成功时的 VerifyResult（{files_ok,digest_ok,signature_ok,trusted,signer_name}）或失败时的 {error: "..."}。深色等宽代码块 white-space: pre-wrap 会折行，超长 digest/错误串也能完整看到。「关闭」或点遮罩关闭，无二次操作入口。

5. 后端关联

5.1 API 客户端

action/web/src/api/apolloClient.js：axios 实例 baseURL /apollo-api/v1、timeout 30000ms、默认 Content-Type: application/json（构建 bundle 时显式覆盖为 multipart/form-data）。请求拦截器对所有请求附加 Authorization: Bearer <token>（仅取 apollo_token，不回退 aip_token）。响应拦截器：HTTP 2xx 且 code===0 → 把 response.data 解包为业务数据；HTTP 2xx 但 code 非 0 → reject；4xx/5xx → 从 body.message 提取并 reject（401 清 apollo_token 并跳 /apollo/login（登录页自身 401 不跳防死循环），403 alert('无权限执行该操作')），同时把服务端 message 别名写入 error.response.data.error 与 error.message——页面 catch 统一用 err.response?.data?.error || err.message 取文案。blob/arraybuffer 响应（zip 下载）原样放行不解包。

5.2 端点表

所有端点注册于 action/products/apollo/server/server.go protected 组（约 746-765 行）。返回形状：创建类 201 {id}（bundles 除外——返回完整记录）、修改类 {id}、删除类 {id, deleted:true}、指向类 {id, desired_state_id}。

5.3 响应结构示例

GET /bundles（envelope 解包后为数组，单项 BundleRecord）：

[
  {
    "id": 7,
    "name": "demo-app-1.0.0-b2",
    "app": "demo-app",
    "version": "1.0.0",
    "bundle_version": 2,
    "digest": "8f3a1c2e5b9d0476aa11cc22dd33ee44ff55aa66bb77cc88dd99ee00ff11aa22",
    "signer_id": "demo-signer",
    "signer_fingerprint": "c9d8...",
    "size_bytes": 4096,
    "created_at": "2026-09-07T03:12:00+08:00"
  }
]

字段含义（server/models.go BundleRecord）：id 主键；name 即 BundleID（{app}-{version}-b{bundle_version}）；digest bundle 内容哈希（size:128;uniqueIndex，G7 唯一连接键）；signer_fingerprint = SM3(公钥) 指纹（白名单匹配键，展示列悬停全文）；size_bytes 各文件字节和；dir 字段 json:"-" 不外发（落盘路径只在服务端用，下载/验签按 id 反查）。

POST /bundles（201，envelope 解包后即 BundleRecord）：响应就是刚登记的完整记录（同列表单项），页面 toast 用其中的 rec.id/rec.digest/rec.signer_fingerprint。成功时 digest 冲突走 upsert：digest 唯一索引 OnConflict 只更新 size_bytes/dir 两列，id 保持首次登记的旧值。

POST /bundles/:id/verify（200）：

{
  "files_ok": true,
  "digest_ok": true,
  "signature_ok": true,
  "trusted": true,
  "signer_name": "demo-signer"
}

字段含义（hub/bundle.go VerifyResult）：files_ok 逐文件重算 SM3 校验和与大小对照 manifest（含文件数与路径覆盖检查）；digest_ok 用 manifest+文件重算 digest 对照 manifest.Digest；trusted 白名单信任锚命中（指纹存在且 enabled=true）——注意它不隐含其它三项通过；signer_name 命中的白名单签名者名（omitempty）。400/403 错误分支：制品加载失败 400 BUNDLE_INVALID；指纹不在白名单（或 enabled=false）→ HTTP 403，envelope 保留领域码与原始 message（见下，页面 catch 把 message 展示在弹窗）：

{
  "code": "VERIFY_SIGNER_NOT_TRUSTED",
  "message": "签名者指纹 \"c9d8...\" 不在可信白名单（enabled=true）中，拒绝应用",
  "request_id": "req_1725600000000abcd"
}

GET /channels（envelope 解包后为数组，单项 ReleaseChannel）：

[
  {
    "id": 1,
    "name": "stable",
    "description": "演示发布通道（指向 demo-app）",
    "current_desired_state_id": 3,
    "promotion_policy": { "batch_percent": 10 },
    "approval_policy": { "require_approval": false },
    "created_at": "2026-09-07T02:00:00+08:00",
    "updated_at": "2026-09-07T02:00:00+08:00"
  }
]

current_desired_state_id 为 0 或缺失即「未指向」（页面 select 映射成 未指向）；两个策略字段 omitempty，未填的渠道行不会出现该键。set-desired-state 响应 {id: 1, desired_state_id: 3}（页面 toast 取 data.desired_state_id）。

GET /policies（envelope 解包后为数组，单项 DeploymentPolicy）：

[
  {
    "id": 1,
    "name": "default",
    "rules": {
      "auto_rollback": true,
      "max_concurrent": 2,
      "readiness_timeout_sec": 60,
      "reconcile_backoff": { "initial_s": 5, "multiplier": 2, "max_s": 300 }
    },
    "created_at": "2026-09-07T02:00:00+08:00",
    "updated_at": "2026-09-07T02:00:00+08:00"
  }
]

GET /desired-states（下拉选项数据源）：页面只消费每项的 id 与 name（渲染 #{{ ds.id }} {{ ds.name }}），但后端返回整行 DesiredState（含 status/approval_status/digest/version 等，见下方折叠），页面未做任何筛选/状态展示。

{
  "id": 3,
  "name": "demo-app",
  "description": "",
  "app": "demo-app",
  "version": "1.0.0",
  "bundle_version": 1,
  "digest": "8f3a1c2e5b9d0476...",
  "signer_id": "demo-signer",
  "declaration": { "app": "demo-app", "version": "1.0.0", "name": "demo-app", "channel": "stable", "components": [ ... ] },
  "status": "active",
  "approval_status": "",
  "created_by": "system",
  "created_at": "2026-09-07T02:00:00+08:00",
  "updated_at": "2026-09-07T02:00:00+08:00"
}

5.4 关键机制

① bundle 打包与签名（构建即签名，契约④）。POST /bundles 的完整链路：handleCreateBundle 校验后 parseFormFiles 把 multipart 解成 []BundleSourceFile{Path,Data}（Path = 文件键，空键回退 fh.Filename）；bundleStore.build 里若请求 signer 为空自动兜底 demo-signer，随后 ensureSigner() 惰性取演示签名者——首次构建时 crypto.GenerateSM2KeyPair() 生成 SM2 密钥对（私钥仅存进程内存），计算指纹 SignerFingerprint = SM3(公钥字节) 并幂等 upsert trusted_signers（name 冲突更新 public_key_fingerprint/public_key/enabled/description，行名固定 demo-signer、描述「演示签名者（服务器首次构建 bundle 时自动注册，G1 信任锚）」），因此 seed 里那只占位指纹 demo-fingerprint-placeholder 会在第一次构建后被真实指纹顶替，白名单自洽。随后 hub.BuildBundle 四步：① 枚举文件生成清单 Files[]（path/size/SM3 校验和）；② 由文件路径推导组件清单 Components[]（classifyComponentKind：路径含 ontology→ontology_yaml、llm_route/llm-route/llmroute→llm_route、含 eval→eval_set、含 config 或以 .yaml/.yml 结尾→config、否则→binary；组件名取文件基名去扩展名）；③ digest = SM3(manifest 规范化 JSON（digest 置空防自引用）+ 全部文件字节按 Path 字典序拼接)（G7 不可变连接键）；④ 用 SM2 私钥对 digest 签名，manifest 记 signer_fingerprint 与 signed_at。之后制品落盘：目录 = ./temp/apollo_bundles/<digest>（bundleDirBase，相对进程工作目录），内部结构为 manifest.json（json.MarshalIndent 缩进）+ digest.sig（签名 hex 字符串）+ files/<sanitized路径>（每文件先 sanitizeRelPath 防穿越再 MkdirAll 写盘）；记录登记 bundles 表（name=BundleID、digest 唯一索引、size_bytes = 清单各文件字节和）。

② multipart 上传的边界与静默截断。parseFormFiles 先 r.ParseMultipartForm(32 << 20)（整请求内存/磁盘缓冲上限 32MB，超限后端报解析错误），再对每个上传文件 io.ReadAll(io.LimitReader(f, 8<<20))——单文件超过 8MB 会被静默截断到 8MB：字节被砍掉，但后端不比对原长度、不报错，只会构建出一个「manifest 里 size 与你上传的不一致」的制品。前端无法从响应发现截断（页面 formatSize 展示的是截断后清单里的大小）。已加前端前置拦截（提交 412e9c48）：选文件时即按 MAX_FILE_SIZE(8MB) 预校验并提示（BundlePage.vue:398-413），从入口避免上传超限文件（见 8 章）。另外 multipart 以「文件键」为字段名，若两个文件行填了相同路径，后 append 的会覆盖先 append 的（同名键最后一次生效），前端行内不提示重复（见 7.7）。

③ 验签链与「可信」语义（G1）。POST /bundles/:id/verify（可选 ?environment_id=，页面不传，走全局白名单）→ store.verify 用 LoadBundleFromDir 从落盘目录读回制品 → hub.VerifyBundle/VerifyBundleScoped 按序执行：1) verifyFiles 逐文件重算 SM3 与大小对照 manifest（文件数、路径覆盖都查）→ files_ok；2) 重算整体 digest 对照 manifest.Digest → digest_ok；3) 用 manifest.SignerFingerprint 在白名单查（环境级 scope 时环境级优先回退全局，需 enabled=true）——命中即 trusted=true 并记 signer_name，未命中/禁用直接返回 HTTP 403（领域码 VERIFY_SIGNER_NOT_TRUSTED、message 含指纹）；4) 有签名且 digest 非空才用白名单公钥做 SM2 验签 → signature_ok（无签名时 signature_ok=false 但仍 200 返回）。需要点破的是：后端 trusted 字段只代表「签名者进了白名单」，不等于四步全过——若落盘文件被人为改过，步骤 1/2 会置 files_ok=false/digest_ok=false 但响应仍 200、trusted=true（签名是对 manifest 里存的 digest 验的，digest 字段没变就验得过）。已修复（提交 412e9c48）：页面徽标改为四项合取判定（verifyResultOk = trusted && files_ok && digest_ok && signature_ok，BundlePage.vue:355-357），并且验签弹窗把四项分开展示「通过/失败」徽标（BundlePage.vue:284-304），因此这类"内容被篡改但签名者仍可信"的制品不再误显示绿徽标。对本页演示路径（构建即验签）四步恒全过、白名单恒命中，结论与直觉一致；异常只在制品被外部改盘/白名单变动时出现。

④ bundle 生命周期清理（本页无 UI，后端保留策略驱动）。POST /bundles/cleanup/run 会先 ensureDefaultBundlePolicy：若不存在 (project_id=0, scope=bundle) 的清理策略则创建 KeepCount=10（artifact_cleanup_policies 表）；再读策略（enabled=false 则跳过）按每 app 分组 CreatedAt DESC 保留最近 N 个，叠加 keep_days/keep_tags 过滤，标记过期 bundle 后删除记录与本地目录。引用保护：desired_states.digest（G7 连接键）与 artifacts.bundle_id 引用中的 bundle 强制保留；删除目录前 dirWithinBundleBase 校验目标在 ./temp/apollo_bundles 内（纵深防御，防 DB 的 Dir 被篡改指向任意目录），trusted_signers 白名单不随 bundle 删除。该端点显式写审计 BUNDLE_CLEANUP_RUN（scanned/deleted/freed_bytes）。演示中若发现 bundle「自己不见了」，多半是有人调过清理或按保留策略过期，本页没有恢复入口。

⑤ 渠道机制：软删、唯一名、指向须 active、策略是存储而非执行。release_channels 用 GORM DeletedAt 软删，列表自动过滤；name 唯一索引，重名创建返回 409（CHANNEL_CONFLICT），空名 400（CHANNEL_INVALID）。SetChannelDesiredState 在 desired_state_id=0 时直接清空当前指向并落库（幂等），非 0 时校验期望状态存在且 status=active（RequiresApproval/审批态见下）（hub/channel.go:153-181）——页面选「未指向」经确认即解除指向，前后端两处均已打通。promotion_policy/approval_policy 在此仅作 JSON 存储：审批 gate（approval_status 驱动 Spoke Pull 拦截）在期望状态审批端点（G15）执行，渐进发布的 rollout 百分比在编排侧消费，本页不触发执行，只负责把它填进渠道。Seed 里自动创建渠道 stable（描述「演示发布通道（指向 demo-app）」）并指向 demo 期望状态，若其指向已被清/弃用则 seed 会重置指向 demo——即 demo 环境里 stable 渠道永远是「有指向」的，演示 Pull 目标选择因此恒能命中第二优先级。

⑥ 部署策略机制：空规则落默认、按名解析兜底。policies 表 rules 为 JSON；CreatePolicy/UpdatePolicy 遇到空 rules 都会 DefaultPolicyRules().ToJSON()（auto_rollback:true、max_concurrent:2、readiness_timeout_sec:60、reconcile_backoff{initial_s:5,multiplier:2,max_s:300}），非法 JSON 400（策略规则非法 JSON: ...）；重名创建冲突（名称唯一索引）。部署编排按策略名解析：ResolveRulesByPolicyName 找到则 ResolvePolicyRules（字段级默认值兜底），找不到或解析失败直接读 DefaultPolicyRules()——策略被删不会让部署崩溃，只是退回默认行为。Seed 创建 default 策略供部署引用。

⑦ 前端并行加载与互斥。loadAll 用 Promise.all 并行拉 GET /bundles、/channels、/policies、/desired-states 四份，每份 .catch(() => ({data:[]}))——任一接口失败静默降级为空数组，不提示（例如无 PermDesiredStateRead 权限时下拉会空、但其余三卡正常）。页面 onMounted 与每个写操作成功/失败（部分）回调都会 loadAll()；busy 全局互斥保证「构建/验签/下载/渠道写/策略写」不会并发交叠，避免提示条互相覆盖与列表竞态。因为没有独立的列表刷新按钮，若四份数据之一在别处被改，需要在本页做一次写操作或刷新页面才能看到新值。

6. 权限与安全

• 认证分层：全部端点 protected（Bearer JWT / X-API-Key），401 由 apolloClient 清 token 跳 /apollo/login；未登录直接访问路由被前端守卫拦到登录页。不存在公开写端点，bundle 下载也要求登录。
• 权限点细化：bundle 读写分离（读 PermBundleRead、写/验签 PermBundleWrite）；渠道与策略各带读写分离；期望状态下拉只读。值得注意的是验签属只读诊断动作却落在 Write 权限，只读运维角色会因此 403（7.4）。
• 写操作防护：删除渠道/删除策略均前置 window.confirm；JSON 输入提交前 JSON.parse（非法不入 payload）；表单校验（name 必填、app/version/文件至少一行）在前端完成，后端同规则兜底。渠道/策略名不可改（编辑弹窗 disabled）降低误改名风险。
• 制品侧纵深防御（后端）：落盘路径固定 ./temp/apollo_bundles/<digest>，删除前 dirWithinBundleBase 校验；bundle 目录内的文件写盘前 sanitizeRelPath 防路径穿越；multipart 表单字段名被当作路径但不会逃逸目录——这些属于后端加固，页面侧不暴露原始路径。
• 审计覆盖：本页 CRUD 均落在 HTTP 审计中间件（http_audit.go）全量记录范围（body 按 content-type 白名单捕获、multipart/下载跳过 body 但记录请求）；cleanup/run 另有显式 BUNDLE_CLEANUP_RUN 审计行。在「审计日志」页可按此检索本页操作。

7. 常见问题与排错

以下问题均从 BundlePage.vue 提示分支、后端 handler/服务层错误码与既有测试归纳，可按步骤复现。

8. 已知缺陷与边界

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