发布运维应该统一收口到 contextgo-releases

为什么版本事实来源必须单一

一旦官网、GitHub Release 页面、下载中心和桌面端更新各自读不同地方，产品就会出现一种非常典型的支持问题：每个地方都“看起来像官方”，但用户无法判断哪个才是当前版本。

这会直接带来歧义。用户可能在官网看到一个版本号，在桌面端看到另一个，在 GitHub 上又找到第三种产物命名。对支持团队来说，这意味着排障时先要解决“我们现在在讨论哪个版本”。

contextgo-releases 的价值，就是成为唯一的产品版本事实来源。凡是跟“可安装产物、校验值、manifest、更新来源”有关的东西，都应该围绕这个仓库收口。

release 仓库到底承载什么

release 仓库最适合承载的是这些内容：

1. 可下载安装的二进制安装包。
2. 对应的 checksum、manifest 和版本产物元数据。
3. 版本级 release notes 摘要。
4. 给下载中心和桌面 updater 读取的稳定公开结构。

它不适合承载的是长文档、博客正文和官网品牌页面。这些内容应该继续保留在站点侧，因为它们承担的是解释、教育和品牌职责，而不是作为安装事实来源。

把这层边界分清楚之后，站点和 release 仓库就不会互相污染。官网负责讲清楚产品、文档和操作说明；release 仓库负责讲清楚某个版本到底发布了什么产物。

官网下载与桌面更新为什么要对齐

对外产品体验里，用户并不会主动区分“这是站点逻辑、这是 updater 逻辑、这是 GitHub Release 逻辑”。他们感受到的是一个统一产品：官网提供下载，桌面端提供更新。

因此这两个入口必须读取同一份版本事实。最理想的状态是：

1. 官网下载中心从 release 仓库读取版本与产物信息。
2. 桌面端更新检查从同一来源读取 manifest。
3. 支持团队在排障时，只需要先确认 release 仓库记录，再追踪站点或客户端表现。

这样即使站点视觉、下载页文案和客户端交互在演进，底层版本事实仍然只有一份，不会因为某个页面缓存、某段脚本或者某份手工维护文案而漂移。

这会怎样改变支持与排障

一旦版本事实来源统一，很多问题的排查顺序都会变简单。

支持团队不再需要先猜“是网站没更新，还是客户端读错了，还是 GitHub 上的 tag 不对”。他们可以先看 release 仓库记录，再去判断站点是否同步、客户端是否读取正确。

这也会让未来的下载页、自动更新和版本广播更容易标准化。因为每个面都不是在维护自己的版本真相，而是在消费同一份发布记录。

长期收益是什么

一个公开产品如果想长期建立信任，必须把“对外说法”和“可安装事实”绑在一起。release 仓库的单一来源模型，看起来像运维决策，实际上会反向影响品牌可信度、支持成本和更新体验。

所以这不是简单的仓库整理问题，而是产品分发边界问题。ContextGo 要对外讲清楚文档、博客和下载的角色，就必须同时把 release 来源收口清楚。