# 两种发版方式怎么区分（1.1.26 起有变动）

> 一句话：**站点后台「一键发布」仍走 OSS（`avc-releases2/`）；
> 开发者本机的 `npm run push` 已改为纯本地直发，包跟着下载站走，不再用 OSS。**

> ⚠️ **1.1.26 起的重要变化**：下面第一节讲的「两条链路都往 OSS 放包」已经是历史。
> 本机发版（原「链路 B」）**不再需要 OSS 凭据**了，包直接跟着下载站发布。
> 第二节的对照表已按现状更新；第一节保留是为了解释 `avc-releases2/` 这个目录
> 对**站点后台一键发布**依然有效。

## 一、为什么要分开（历史）

早期两条链路都把升级包放进 OSS 的 `avc-releases/` 目录：

| 链路 | 在哪打包 | 结果 |
|---|---|---|
| **A. 后台「一键发布」** | 服务器本机，点按钮时现场打包 | 上传到 `avc-releases/` |
| **B. 下载页 / 手动上传** | 开发环境打好，切分片发布 | 也放 `avc-releases/` |

两者共用同一个目录，会出现：

- 自动发布把手动上传的包**覆盖**掉（同名时）；
- 一个目录里混着两种来源的包，**排查时根本分不清谁是谁**；
- 想清理旧包时不敢删，怕删掉另一条链路正在用的。

**1.1.23 起**：站点后台的一键发布独占 `avc-releases2/`。

**1.1.26 起**：本机发版彻底离开 OSS —— 包和页面一起发到下载站，
所以「两边抢同一个 OSS 目录」这个问题从根上没有了。

---

## 二、现状对照表

| 对比项 | 站点后台「一键发布」 | 本机 `npm run push` |
|---|---|---|
| **打包位置** | 你的服务器上，点按钮时现场打包 | 你的本机 |
| **怎么触发** | 后台点「一键发布」按钮 | 执行 `npm run push` |
| **包放哪** | 阿里云 OSS 的 `avc-releases2/` | **下载站目录**（切 8 个分片） |
| **要凭据吗** | 要（在后台「存储配置」里填） | **不要** |
| **打包模式** | 自动比对（增量为主），也支持全量 | 增量为主，`--full` 可全量 |
| **发布动作** | 上传 OSS + 写本机升级源 | 切分片 + 更新下载页 + 发布上线 |
| **用途** | 多站点**日常自动更新** | **从零部署**或手动升级 |
| **谁用它** | 已部署站点后台「检查更新」 | 下载区取包的人 |

> **判断谁更新**：不要比序号，看包内的 `appVersion`（如 `1.1.26`）和 `releasedAt`。
> 两条链路的序号**各自独立**，本来就不该相等。

---

## 三、本机发版现在一条命令走完（1.1.26 起不需要 OSS）

以前在开发机发版要手工做四件事：开阿里云控制台传 zip、切 8 个分片、
改下载站的版本号和 SHA256、再发布。1.1.24 起变成一条命令，
**1.1.26 起连 OSS 凭据也不用配了**：

```bash
npm run push                  # 打包 → 切分片 → 更新下载站 → 发布上线
npm run push -- --dry-run     # 演练（打包但不发布）
npm run push -- --site-only   # 不重新打包，用 release/ 里最新的包重推下载站
```

前置条件：**无**。装上依赖就能跑。

**这条命令只影响开发者本机与下载站**，站点侧无需任何改动。
它产出的包放在下载站上，所以站点后台的「升级源地址」填**下载站地址**即可。

---

## 四、站点后台一键发布（走 OSS）改目录后要做什么

### 如果你是「用自动发布」的站点（推荐流程）

1. 升级到 **1.1.23**；
2. 后台「系统升级」→「📤 发布新版本到 OSS」→ 点「一键发布」；
3. **本次发布会自动把 `upgrade/source.json` 的地址改写到新目录**，无需手改。

发布卡片上会提前提示：

> ⚠ 当前升级源指向旧目录 `avc-releases/`，本次发布会自动改为 `avc-releases2/`；
> 旧目录里的历史包不会被删除。

### 如果你等不及，想手动改

编辑站点目录下的 `auto-video-cut/upgrade/source.json`：

```json
{
  "url": "https://你的域名/avc-releases2",
  "latestFile": "latest.json",
  "updatedAt": 0
}
```

把 `url` 从 `.../avc-releases` 改成 `.../avc-releases2`，保存即可。
（结尾有没有 `/` 都行，系统会自动规范化。）

### 如果你是「手动上传升级包」的站点

**不受影响**，继续用 `avc-releases/` 即可。只要保证：
> 「后台填的升级源地址」= 「你实际存放 latest.json 的目录」

---

## 四、想换成别的目录名

在站点 `.env` 里加一行，然后重启服务：

```bash
OSS_RELEASE_PREFIX=my-releases
```

- 不带前后斜杠也可以（如 `/my-releases/` 会被自动规范化为 `my-releases/`）；
- 不配置则用默认值 `avc-releases2`；
- 后台发布卡片会**显示实际生效的目录**，改完刷新后台即可确认。

---

## 五、旧目录的包会怎样

**不会被删除，也不会被读取。**

- 系统全程不调用删除操作（做到「只归档不删除」）；
- 旧目录 `avc-releases/` 里的历史包留在那里，需要回滚时仍可手动取用；
- 新发布的包只会进 `avc-releases2/`。

---

## 六、常见疑问

**Q：我之前两条链路都传同一个文件夹，现在改成两个，会不会有站点收不到更新？**

只要你把站点升级到 1.1.23 并重新发布一次（或手动改 `source.json`），
源地址就会指向新目录，更新照常能收到。**在改之前，老站点仍从旧目录检查更新**，
而旧目录的包没被删，所以**不会出现更新中断**。

**Q：我能让两条链路继续用同一个目录吗？**

可以。把两边都设成同一个名字即可（例如都用 `avc-releases`）：

```bash
# 站点 .env
OSS_RELEASE_PREFIX=avc-releases
```

但这样就回到了「两种来源混在一起」的状态，排查会更麻烦，**不建议**。