企业官网建设流程全解析

codex-app-mirror如何15分钟发现Codex新版？"探测→比对→发布"镜像管道全拆解

【免费下载链接】codex-app-mirror原样镜像官方 Codex 桌面应用:每 15 分钟探测、SHA256 可校验、国内直连下载、 Mac 可增量更新 | Verbatim, verifiable mirror of the official Codex desktop app — probed every 15 min, with a Sparkle delta-update feed.项目地址: https://gitcode.com/gh_mirrors/co/codex-app-mirror

codex-app-mirror是官方 Codex 桌面应用的原样镜像项目：每 15 分钟探测一次上游，SHA256 可校验、国内直连下载、macOS 支持 Sparkle 增量自动更新。它只镜像、不构建、不重打包，上游一变就能发版。这篇文章带你完整拆解它的"探测 → 比对 → 发布"镜像管道。

为什么需要"15分钟镜像探测"？

官方 Codex 桌面应用发布在 Microsoft Store 和 OpenAI 静态地址上，存在两个痛点：

• 下载不便：国内直连慢、临时 CDN 地址随时失效
• 更新感知慢：手动检查版本费时费力

codex-app-mirror的答案是一套全自动管道：定时探测上游指纹，没变化就不下载、不发重复 Release；一旦上游真的变了，自动完成"下载 → 校验 → 发版 → 同步双镜像"全流程。

第一步：探测——只取指纹，不搬大文件

每次运行的入口是探测脚本 probe-release.sh，它对四个平台包做轻量探测，全程不下载安装包本体：

Windows：走 Microsoft Store 元数据

1. 查询 DisplayCatalog（ProductId9PLM9XGG6VKS），拿到 x64 / ARM64 包元数据
2. 用 FE3 metadata 解析可下载的 MSIX moniker 和临时下载 URL
3. 只发 HEAD 请求记录Content-Length/ETag/Last-Modified

ARM64 包如果暂时解析不到下载 URL，会以catalog-only状态记录在 manifest，等下一轮补齐——不会因为一个架构缺失而阻塞其他平台发版。

macOS：appcast + ETag 指纹

对官方 DMG 与 Sparkle appcast 发请求，读取ETag、Last-Modified、Content-Length以及 appcast 里的版本字段（见 probe-release.sh）。所有指纹汇总写进一份probe-manifest.json，这是后续比对的"现场快照"。

第二步：比对——稳定指纹决定是否发版

这是管道里最省钱的一步：指纹没变就直接结束。

manifest_key() 从探测结果中抽取一组稳定字段（版本号、包名、大小、ETag、appcast 版本），与最新 Release 附带的release-manifest.json做逐字段比较。除此之外还有一层"公开镜像自检"：

任何一项不通过，都会触发一次"修复性重发布"。这种设计保证：管道即使跑空转 100 次，用户看到的 latest 链接也永远有效。

第三步：发布——下载、校验、生成 Release

确认上游变化后，管道进入重活阶段：

1. 下载全部安装包：download-macos.sh 下载 DMG 与 Sparkle 归档，并逐字节核对Content-Length，大小不符直接失败
2. 生成指纹文件：prepare-release-metadata.sh 为每个产物计算SHA256SUMS.txt，并合并出完整的release-manifest.json上游指纹
3. 创建 GitHub Release：Release tag 采用 Codex 内部版本聚合命名，如codex-app-26.623.41415。四个架构未集齐时先发 prerelease，补齐后自动提升为 latest——缺失平台会在 body 表格中标注"待官方发布"

构建 Sparkle appcast 时，镜像逐字节复制官方归档和 EdDSA 签名，只改写下载地址。因为签名针对的是归档字节本身，字节一致签名就依然有效，镜像从不伪造签名。

发布之后：双层镜像 + 按地域自动分流

发版不是终点。资产会同步到两套存储，由一个 Cloudflare Worker 按CF-IPCountry自动路由：

• 全球：Cloudflare R2
• 中国大陆：S3 副镜像（secondary-sync 从 Cloudflare 网络内直接搬运，核心逻辑见 core.js）

对用户透明：同一条latest/*短链，国内访问自动走 S3 副镜像，海外走 R2。

调度层：15分钟心跳是怎么实现的？

双保险调度，缺一不可：

主调度配置就一行 cron 表达式，定义在 wrangler.jsonc 中，Worker 通过 GitHub API 触发工作流，实例化配置见 github-dispatcher。

💡 为什么选 15 分钟？足够快的新版本感知，又不会给上游和 CDN 造成压力——因为探测阶段只传几 KB 的元数据。

macOS 增量更新：只下载差量

对 Mac 用户，管道还沉淀了一份 Sparkle appcast 更新源。下游客户端订阅后，新版发布时只下载版本间的 delta 差量包，而不是每次重拉完整 DMG；没有匹配差量时自动回退完整归档，保证任何情况下都能更新成功。

快速索引：管道关键文件

总结

codex-app-mirror用一条极简原则驱动整条管道：没变化就安静，变了就快速、可校验地发版。

• ⏱️ 15 分钟探测 + 6 小时兜底，双层调度不漏检
• 🔐 探测只取 ETag/版本指纹，稳定字段比对杜绝无效发版
• ✅ 每个 Release 附 SHA256 校验和与 manifest 上游指纹
• 🌏 R2 + S3 双镜像，一条短链按地域自动选路

这就是"探测 → 比对 → 发布"三段式管道的全部秘密：把"检查更新"这件重复的事交给机器，把"放心下载"这件事留给用户。

【免费下载链接】codex-app-mirror原样镜像官方 Codex 桌面应用:每 15 分钟探测、SHA256 可校验、国内直连下载、 Mac 可增量更新 | Verbatim, verifiable mirror of the official Codex desktop app — probed every 15 min, with a Sparkle delta-update feed.项目地址: https://gitcode.com/gh_mirrors/co/codex-app-mirror