## 上线从最终文件开始

本章验收的是准备发给用户的**实际加密组件包**，而不是源码目录。源码测试和开发版集成通过后，仍需在目标正式宿主中完成这一轮。

先确认[打包与登记](publishing.html)已经完成，保留最终包、发行记录和测试资料。

## 第一步：检查发行信息

| 字段 | 必须一致的对象 |
| --- | --- |
| ID、类别、版本 | 清单、后台记录与实际包 |
| 内容摘要与大小 | 本地最终文件与发行登记 |
| 宿主要求 | 实际调用接口与声明的最低版本 |
| 授权范围 | 业务计划与后台核验结果 |
| 发布状态 | 当前后台状态与用户可见入口 |

不要在核对完成后再改文件。发生内容变化，应作为新发行内容重新生成和登记。

## 第二步：首次导入

在独立测试数据环境中，使用软件现有组件导入入口，选择与类别对应的 `.mrite-task` 或 `.mrite-component` 文件。兼容入口可能还支持旧 `.mrite-plugin`，但新包应遵循当前分类发行流程。

核对显示名称、图标、类别、版本、安装结果和打开状态。不要将源码 ZIP 改名后作为这个步骤的输入。

## 第三步：完成一个真实最小流程

- 效率插件：打开、执行一项操作、查看结果，需要时保存到允许位置。
- 自动化任务：检查输入、运行阶段、取消或完成，核对实际文件。
- 两类组件：关闭、重新打开、停用再启用，检查清理。
- 需要模型、工具或文件能力的组件：分别核对实际配置和调用，不能只看界面出现。

## 第四步：验证拒绝和失败路径

| 场景 | 预期 |
| --- | --- |
| 包损坏或内容不一致 | 明确拒绝，不留下半装配状态 |
| 类别或格式不匹配 | 明确提示，不靠后缀混用 |
| 宿主版本不足 | 告知版本要求，而不是空白加载 |
| 账号或授权范围不满足 | 明确解释，不能误报成功 |
| 网络或服务不可达 | 说明阶段和重试方式，保留用户项目 |
| 依赖或输出路径异常 | 指出对应对象和可采取的下一步 |

使用受控测试材料验证失败，不破坏用户正常项目或真实发行记录。

## 第五步：从旧组件升级

使用上一受支持版本创建一个小项目，保留其材料、输出和设置。导入新版本后核对入口身份未变、旧项目可打开、状态迁移正确，并完成一次继续修改。

如果新功能需要升级宿主，更新说明应直接写出最低要求。不能在用户拿到插件后才让其发现宿主缺少接口。

## 第六步：确认可用的发布入口

后台登记、发布状态、下载地址或人工分发是不同环节。维护者应核对实际后台支持的状态，并配置相应更新信息；需要 QQ 群或其他方式发包时，发出的仍是已验收的最终文件。

不要把“生成了本地包”“上传了文件”和“用户已经收到更新”当成同一件事。

## 上线交付清单

- 发行文件及其摘要、大小和唯一记录。
- 组件与宿主版本、适用范围、依赖说明。
- 已运行的正常和失败用例记录。
- 用户可理解的变更内容、安装或更新方法。
- 问题收集与撤回方案，以及旧项目的处理约定。

完成这些步骤后再对外发布。上线后根据实际问题记录跟进，不为临时修复覆盖已发布同版本文件。