制品开发

制品开发是一个面向开发者的官方应用，用于设计、打包、维护和发布 ZPK 制品。

它的重要性不只是“管理几个制品文件”，而是：微擎面板里很多可以安装的应用，主要就是通过这个工具来设计、打包和发布的。

如果你要把一个应用沉淀成可安装、可升级、可持续交付的面板应用，而不是只做一次性的临时打包，那么制品开发就是核心工具。

项目已开源：

• https://github.com/w7panel/w7panel-zpk

这个工具主要解决什么问题

在实际开发里，一个应用要变成可安装制品，通常不只是准备一份代码，还要同时处理：

• 制品基础信息
• Manifest 定义
• 附件包和文件树
• 版本管理
• 发布设置
• 升级策略和价格配置
• 仓库、命名空间和权限

制品开发的作用，就是把这些原本分散的事情整理到一套开发和发布流程里。

你通常会在这里做什么

从当前前后端能力看，开发者在这个工具里最常见的工作包括：

• 新建和维护制品
• 编辑制品基础信息和 Manifest
• 上传、整理和维护附件包
• 创建和维护版本
• 配置发布、升级和价格策略
• 执行制品发布
• 管理仓库、命名空间和权限

可以把它理解成：应用管理 更偏“怎么安装和使用应用”，而 制品开发 更偏“怎么把应用做成一个可安装、可发布的制品”。

主要页面怎么理解

从当前前端路由看，这个工具至少包含下面这些主要页面：

• 制品列表
• 制品详情
• 版本管理
• 制品编辑
• 前端制品编辑
• Manifest 编辑
• 附件上传
• 附件树
• 镜像仓库
• 命名空间
• 用户管理
• 设置
• 制品商店

这些页面不是简单平铺，而是围绕一条完整链路组织起来的：

定义制品 → 补齐内容 → 管理版本 → 执行发布 → 进入分发和权限控制

一、从哪里开始最合适

如果你是第一次进入制品开发，建议按下面顺序开始：

1. 先进入 制品列表，确认已有制品情况
2. 如果是新制品，进入 制品编辑 或 Manifest 编辑
3. 上传附件包并补齐文件树内容
4. 进入 版本管理 创建版本
5. 配置发布设置、升级策略和价格信息
6. 执行发布

这个顺序更接近真实开发链路，也更符合“先定义，再打包，再发布”的工作方式。

开始之前先准备什么

如果你准备开始做一个新制品，通常最好先准备好下面这些内容：

• 制品的名称、标识和基础说明
• 应用的核心结构或交付方式
• 需要上传的附件包
• 版本规划
• 发布目标和升级策略

这些内容越早准备清楚，后面的编辑、打包和发布就会越顺。

二、制品定义相关页面

和“制品定义”最相关的页面主要有：

• 制品编辑
• 前端制品编辑
• Manifest 编辑
• 制品描述

它们各自更适合处理：

• 制品编辑：维护制品整体结构和基础信息
• 前端制品编辑：处理前端相关制品内容
• Manifest 编辑：维护制品清单和结构配置
• 制品描述：维护展示说明和描述文档

如果你的目标是“把制品定义清楚”，通常会主要停留在这一组页面里。

Manifest、附件包、版本之间是什么关系

可以把这三者理解成三个不同层次：

• Manifest：定义这个制品是什么、怎么描述、怎么被系统识别
• 附件包：提供制品真正要交付的内容
• 版本：把某一次完整的制品状态沉淀成可发布、可升级的版本

简单说：

• Manifest 负责“定义”
• 附件包负责“内容”
• 版本负责“发布对象”

如果这三者没有理顺，后面通常就会出现“内容有了但版本不完整”或“版本有了但发布结果不对”这类问题。

三、附件包和文件树

制品开发不是只改配置，很多时候还要维护真实的附件内容。

当前实现里已经明确包含：

• 附件上传
• 附件树

这意味着你可以：

• 上传制品附件包
• 查看附件结构
• 继续维护制品内容树

如果一个制品的配置看起来没问题，但发布后内容不对，通常就要先回到附件和文件树继续检查。

四、版本管理和发布

版本管理是制品开发里非常关键的一块。

从当前前端和后端能力看，这里至少包含：

• 新建版本
• 编辑版本说明
• 查看发布状态
• 配置发布设置
• 处理版本升级相关能力
• 配置价格和升级策略

如果你把制品理解成“长期演进的交付物”，那版本管理就是它最核心的维护入口。

什么时候需要优先进入版本管理

通常在这些场景里要优先进入版本管理：

• 新制品已经准备好，准备发布第一个版本
• 需要补充新版本说明
• 需要调整发布设置
• 需要处理升级策略
• 需要确认某个版本是否已经发布成功

五、发布、官方制品库和云市场

当前实现里可以确认，制品不仅能发布，还能继续和官方制品库、云市场相关能力打通。

前端里可以看到：

• 制品商店
• 添加到官方制品仓库
• 发布到云市场后的状态说明

后端里也能看到围绕：

• publish
• goods publish
• publish loop

这些发布流程相关的处理逻辑。

这意味着制品开发的目标不是把内容存下来而已，而是把它变成真正可以上线、可分发、可升级的制品。

六、仓库、命名空间和权限

除了制品本身，这个工具还覆盖了一组更偏平台维护的能力：

• 镜像仓库
• 命名空间
• 用户管理

这部分更适合处理：

• 制品应该放到哪个命名空间
• 谁对哪个仓库有管理权限
• 是否允许 push、pull 或更精细的仓库权限控制

如果你已经不只是“做一个制品”，而是要长期管理多个制品、多个人员或多个仓库，这组能力会很重要。

什么时候需要进入这些页面

通常在这些场景里，才需要优先去看这组页面：

• 制品数量越来越多，需要分类管理
• 多人协作时，需要控制谁能 push、谁能管理仓库
• 同一个团队维护多个制品，想把分发范围理清楚
• 发布链路已经跑通，但权限或仓库结构开始变复杂

如果你现在只是开发和发布单个制品，通常不需要一开始就把重点放在这里；等制品数量、协作人数或权限需求变复杂后，再重点处理会更合适。

七、CLI 配套能力怎么理解

这个项目除了面板本身，还包含配套 CLI。当前已经可以确认的命令能力包括：

• login
• attach
• push
• list
• use

从开发者角度看，可以把它理解成：

• 面板适合做制品定义、版本管理和发布配置
• CLI 更适合做附件处理、打包、推送和命令行开发链路

如果你的团队既需要图形化管理，又需要脚本化或命令行发布能力，这两部分通常会配合使用。

什么时候更适合用面板，什么时候更适合用 CLI

可以按这个原则判断：

• 更适合用面板：制品信息维护、版本管理、发布设置、价格与升级策略、仓库和权限配置
• 更适合用 CLI：附件包处理、打包、推送、命令行工作流集成

如果你的工作是“定义和管理制品”，优先用面板；如果你的工作是“把本地内容打包并推送到制品链路里”，CLI 往往更顺手。

八、常见开发链路

如果你是第一次使用制品开发，通常可以按下面顺序操作：

1. 新建或进入某个制品
2. 完成制品基础信息和 Manifest 定义
3. 上传并整理附件包
4. 创建版本
5. 配置发布设置、升级和价格信息
6. 执行发布
7. 如果需要继续管理分发范围，再去看命名空间、仓库和权限

这条链路更适合长期维护制品，而不是只做一次性的临时打包。

九、什么时候优先检查制品开发本身

如果你遇到下面这些情况，通常要先回到制品开发应用里排查：

• 制品内容和实际发布结果不一致
• 附件包已经上传，但版本内容不完整
• 版本一直无法发布
• 发布后状态异常
• 仓库权限或命名空间配置不符合预期

使用建议

• 先把制品定义、Manifest 和附件内容整理清楚，再去做版本和发布
• 不要把“制品定义问题”和“发布结果问题”混在一起判断
• 如果一个应用需要长期维护，尽早规划好版本、命名空间和权限结构
• 如果同时使用面板和 CLI，建议明确各自职责，避免重复操作同一链路

制品开发的价值，在于把“应用设计、制品定义、版本维护、附件管理、发布与分发”这些原本分散的工作，整理成一套面向开发者的制品开发流程。