全面介绍 Xget：统一加速代码存储库、包管理、容器镜像与 AI API 的开发者资源网关

如果说传统镜像站往往只服务于某一个生态，那么 Xget 想做的事情更像是给开发者提供一层统一的“资源加速入口”：同一个域名之下，用不同路径前缀就能访问 GitHub、GitLab、Hugging Face、npm、PyPI、Docker 镜像存储库、OpenAI/Anthropic/Gemini 等 AI 推理 API，甚至 Debian、Fedora、Arch Linux 这样的系统软件源。

这也是 Xget 最值得关注的地方。它不是单纯的下载重定向脚本，也不是只会转发 HTTP 的通用反向代理，而是一个面向开发工作流设计的开发者资源加速网关。它理解 Git、OCI Registry、包管理器索引、HTTP Range、AI API 等不同场景的差异，目标是把“存储库克隆、依赖安装、镜像拉取、模型调用”统一到同一套入口中。

如果你已经读过我之前写的《深入剖析 Xget》，那篇更偏底层实现；本文则更偏“全面介绍 + 实际落地”，重点回答四个问题：Xget 是什么、能做什么、怎么接入、什么时候适合用它。

一、Xget 到底是什么

先看一张图。下面这张示意图把 Xget 的统一域名、路径规则和上游资源类型放在了一起：

flowchart TD
    subgraph Clients["Clients and Tools"]
        A["Browser / curl / wget / aria2"]
        B["git clone / git fetch / git push"]
        C["npm / pip / go / dotnet"]
        D["docker / podman / containerd"]
        E["OpenAI / Anthropic / Gemini SDKs"]
    end

    subgraph Gateway["Xget Gateway (single domain)"]
        F["https://xget.example.com"]
        G["Path Router<br/>/gh /npm /pypi /cr/ghcr /ip/openai"]
        H["Protocol Adapters<br/>Git / OCI Registry / AI API"]
        I["Cache + Retry + Security<br/>Range support + response rewriting"]
    end

    subgraph Upstreams["Upstream Platforms"]
        J["GitHub / GitLab / Hugging Face"]
        K["npm / PyPI / NuGet / Go Proxy"]
        L["GHCR / Docker Hub / GCR"]
        M["OpenAI / Anthropic / Gemini"]
    end

    A --> F
    B --> F
    C --> F
    D --> F
    E --> F
    F --> G --> H --> I
    I --> J
    I --> K
    I --> L
    I --> M

1.1 它不是传统镜像站，而是统一的加速网关

最容易理解 Xget 的方式，是把它看成一个“前缀驱动的资源网关”。

你不需要为每个平台分别寻找镜像源，也不需要记住不同工具各自的代理方法。你只需要准备一个自己的 Xget 实例，比如 https://xget.example.com，然后按照平台使用对应前缀：

GitHub 代码存储库走 /gh/...
PyPI 走 /pypi/...
GHCR 容器镜像走 /cr/ghcr/...
OpenAI API 走 /ip/openai/...

这种模型带来的价值并不只是“路径更整齐”，而是把访问控制、缓存、协议兼容、容器认证、内容重写和监控都放在一个统一入口中处理。对于个人开发者来说，这意味着配置更少；对于团队来说，这意味着可以把 CI/CD、开发机、容器节点和 AI 服务统一接到同一层基础设施上。

1.2 它解决的是开发链路里“到处都慢、到处都不统一”的问题

现实里的开发资源访问经常是割裂的：

git clone 走一套链路
npm install、pip install、go mod download 各走一套链路
docker pull 又是另一套链路
调 OpenAI、Anthropic、Gemini 这样的 API，还要分别改 SDK 的 base_url

Xget 的价值就在于，它试图把这些碎片化的访问路径收敛成一个域名、一套路径规则、一套部署方式和一套安全边界。这样你要优化的，不再是十几个散落的加速方案，而是一层统一的“开发者资源入口”。

二、Xget 当前支持哪些生态

2.1 截至 2026 年 3 月 15 日，实时平台映射覆盖 84 个入口

按 2026 年 3 月 15 日的数据，Xget 当前一共覆盖 84 个入口，分布如下：

类别	数量	代表平台
资源下载与软件源	38	GitHub、GitLab、Gitea、Hugging Face、npm、PyPI、Maven、Debian、Fedora、Arch Linux、arXiv
容器镜像存储库	17	Docker Hub、GHCR、GCR、MCR、Quay、ECR、GitLab Registry、Kubernetes Registry
AI 推理 API	29	OpenAI、Anthropic、Gemini、OpenRouter、Groq、Mistral、Cohere、Replicate、Together、Vertex AI

和很多只覆盖“代码下载”或“包管理”的加速工具相比，Xget 的特殊之处是支持面非常宽，而且这些能力并不是分散在多个项目里，而是集中在同一个网关里。

2.2 典型支持面可以分成四大块

2.2.1 代码、模型与文件资源

这一块最直观，也最容易上手。比如：

GitHub：存储库、Release、归档包、原始文件
GitLab、Gitea、Codeberg、SourceForge、AOSP
Hugging Face、Civitai 这样的模型与数据资源
arXiv 论文、F-Droid、Jenkins 插件等下载型内容

对于“偶尔下载一个压缩包”和“长期把开发链路接进去”这两种场景，Xget 都能覆盖。

2.2.2 包管理器与语言生态

Xget 当前覆盖的语言和包管理生态已经相当全：

JavaScript：npm
Python：PyPI
Go：Go Modules Proxy
.NET：NuGet
Java：Maven、Gradle
Ruby：RubyGems
Rust：crates.io 的 HTTP 资源访问
PHP：Packagist
R / Perl / TeX：CRAN、CPAN、CTAN
Conda、Flathub，以及多种 Linux 发行版软件源

换句话说，如果你的团队同时写前端、后端、AI 应用和基础设施代码，Xget 比“只换一个 npm 镜像”或“只换一个 pip 源”要系统得多。

2.2.3 容器镜像存储库

容器镜像是很多团队最痛的部分之一，因为它同时涉及大文件传输、Registry API、认证挑战和 CI/CD 并发拉取。Xget 对这类场景做了专门适配，支持：

Docker Hub
GHCR
GCR
Microsoft Container Registry
Quay
public ECR
GitLab、Heroku、Oracle、SUSE、openSUSE 等 Registry

对于经常拉基础镜像、构建镜像、跑 Kubernetes 节点的团队，这一层统一加速非常有价值。

2.2.4 AI 推理 API

这是 Xget 最不像“传统镜像站”的部分。它不只加速下载资源，还能把 AI 推理 API 也纳入统一入口。当前支持的供应商包括：

OpenAI
Anthropic
Gemini
OpenRouter
Groq
Cohere
Mistral
Fireworks
Replicate
Together
Voyage AI
Vertex AI

这意味着，如果你的团队正在同时接多个模型服务商，Xget 可以把“API 基地址管理”也统一起来。

三、Xget 怎么使用

3.1 先记住三条路径规则

Xget 的使用方式其实很整齐，核心就三条规则：

普通资源下载一般是 https://xget.example.com/{prefix}/...
容器镜像存储库统一走 https://xget.example.com/cr/{registry}/...
AI 推理 API 统一走 https://xget.example.com/ip/{provider}/...

举个最直观的例子。原始 GitHub 下载地址：

https://github.com/microsoft/vscode/archive/refs/heads/main.zip

改成 Xget 之后就是：

https://xget.example.com/gh/microsoft/vscode/archive/refs/heads/main.zip

3.2 常见开发工具的接入方式

3.2.1 npm

npm config set registry https://xget.example.com/npm/
npm config get registry

3.2.2 pip

pip config set global.index-url https://xget.example.com/pypi/simple/
pip config list

如果你的部署环境确实需要信任主机名，再额外加 trusted-host；如果不需要，就不要多配。

3.2.3 Go Modules

go env -w GOPROXY=https://xget.example.com/golang,direct

3.2.4 NuGet

dotnet nuget add source https://xget.example.com/nuget/v3/index.json -n xget
dotnet nuget list source

3.2.5 GHCR 容器镜像

docker pull xget.example.com/cr/ghcr/nginxinc/nginx-unprivileged:latest

需要注意的是，容器镜像不是简单地把 ghcr.io 换成普通前缀，而是必须走 /cr/ghcr/... 这样的 Registry 路径。

3.2.6 OpenAI 兼容 SDK

from openai import OpenAI

client = OpenAI(
    api_key="your-openai-api-key",
    base_url="https://xget.example.com/ip/openai/v1",
)

对于 Anthropic、Gemini 和其他兼容供应商，本质上也是同样的思路：保留你原来的 API Key，只把 SDK 指向 Xget 的对应 base_url。

3.3 公开实例、URL Converter、Skill 和浏览器扩展

Xget 存储库 README 里提供了几个对新手和 Agent 都很友好的入口：

xget.xi-xu.me：预部署公开实例，但 README 明确写了“不保证可靠性”
xuc.xi-xu.me：URL Converter，可以把原始地址转换成 Xget 格式
skills/xget/SKILL.md：供 Codex、Claude Code 等 Agent 直接调用的 Xget skill

这里我还是建议把公开实例当作“试用入口”，不要当作正式生产方案。只要你准备长期使用，最佳实践依然是自建。

这个 skill 值得单独提一下，因为它不只是告诉 Agent Xget 是什么，而是能让 Agent 在开发流程里直接用 Xget 做操作。

另外，Xget 还有一个配套浏览器扩展 Xget Now，适合不想手动改链接、但又希望把网页里的下载入口自动切到自己 Xget 实例的用户。

四、Xget 为什么不仅仅是“换个前缀”

4.1 它背后是一套动态平台映射和路径转换机制

Xget 的核心不是静态 URL 列表，而是一套平台映射加路径转换逻辑。平台前缀会映射到上游地址，像 ip-openai 会被解释为 /ip/openai/，cr-ghcr 会被解释为 /cr/ghcr/。

更重要的是，它并不是“去掉前缀后原样转发”这么简单。某些平台需要额外的路径改写，例如：

crates.io 的 HTTP 路径需要映射到 /api/v1/crates/...
Homebrew API 和 bottle 路径需要特殊处理
Jenkins 更新中心路径需要补到 /current/...

所以从设计上看，Xget 更像一个“懂上游协议结构的加速适配层”。

4.2 它会识别 Git、OCI Registry 和 AI API 这些特殊协议

这也是 Xget 和很多通用反代的差异点。它不是只会处理普通静态下载，还会根据路径、请求头和请求方法去识别：

Git 的 info/refs、git-upload-pack、git-receive-pack
Docker / OCI Registry 的 /v2/...、认证挑战、manifest 与 blob 请求
AI API 常见的 JSON POST 请求和供应商路径

这意味着同一个 Xget 实例，可以同时服务：

git clone
docker pull
pip install
openai.ChatCompletion 或 responses.create

统一入口的意义，到这里才真正体现出来。

4.3 它还做了缓存、重试、安全头和内容重写

根据当前 README 和代码实现，Xget 至少具备下面这些“网关级”能力：

默认 30 分钟缓存策略
请求失败自动重试，默认最多 3 次
30 秒超时控制
严格的安全头注入和请求校验
对 HTTP Range 的支持，便于断点续传和多线程下载
对 PyPI、npm 等场景的动态内容重写，避免响应里的下游链接把流量重新带回原站

所以它的价值并不只是“把 A 地址换成 B 地址”，而是把访问链路里那些经常被忽略的细节一起做好。

五、Xget 怎么部署

5.1 边缘平台部署是它最有代表性的形态

从存储库当前结构看，Xget 的主线实现仍然是面向 Cloudflare Workers 的，wrangler.toml 里也保留了 Workers 配置。因此如果你追求全球边缘节点、较低冷启动成本和统一 HTTPS 入口，Cloudflare Workers / Pages 依然是最能体现 Xget 特性的部署方式。

除此之外，README 里还给出了：

Cloudflare Workers
Cloudflare Pages
EdgeOne Pages
Vercel
Netlify
Deno Deploy

这些部署形态的共同点，是都在把 Xget 当成一层边缘函数或轻量网关来运行。

5.2 自托管同样可行，而且更适合团队内网

如果你不需要公共边缘网络，或者更关心控制权与稳定性，Xget 也支持 Docker / Podman 自托管。README 给出的最基础运行方式非常直接：

docker pull ghcr.io/xixu-me/xget:latest

docker run -d \
  --name xget \
  -p 8080:8080 \
  ghcr.io/xixu-me/xget:latest

更推荐的方式是把容器只绑定在本机回环地址上，再通过 Nginx、Caddy 或云负载均衡暴露 https://xget.example.com 这样的正式域名。这样既便于上 TLS，也更容易加鉴权、IP 白名单和日志治理。

5.3 团队化部署时，DigitalOcean 这类方案也很实用

Xget 存储库还单独提供了 DigitalOcean 部署文档，里面把落地方案拆成了三类：

Droplet + Docker Compose：最接近“自己管机器”
App Platform：更接近托管容器服务
DOKS：更适合多副本、高可用和滚动升级

这个拆分其实也说明了 Xget 的定位并不局限于个人工具。它完全可以作为团队内部的统一加速层存在，尤其适合下面这些场景：

CI/CD 经常从 GitHub、GHCR、npm、PyPI 拉资源
多个服务同时调用不同 AI 推理供应商
海外资源访问质量不稳定，想统一一层缓存和访问控制

六、哪些人最适合用 Xget

6.1 个人开发者：想把“到处配代理”变成“一次性接入”

如果你是独立开发者、学生或个人维护多个项目，Xget 的最大好处是减少心智负担。你不再需要分别去找 GitHub 下载镜像、npm 镜像、PyPI 镜像、GHCR 镜像和 OpenAI 代理入口，而是可以围绕一个自己的域名做统一管理。

6.2 团队和平台工程：把开发者资源访问收敛成基础设施能力

对于团队来说，Xget 更像一个平台工程组件。它可以把：

构建机的依赖安装
容器节点的镜像拉取
开发机的存储库访问
AI 服务的上游 API 调用

统一收敛到同一层上做缓存、限流、审计边界和域名治理。

6.3 AI 应用团队：多模型供应商接入会更整洁

如果你的业务同时接 OpenAI、Anthropic、Gemini、OpenRouter、Groq 等多个上游，那么 Xget 的 ip/{provider} 结构会特别顺手。至少从配置层面看，你终于可以用一套统一域名去管理多家模型服务商，而不是在各个项目里散落着不同的 API 基地址。

七、使用 Xget 前需要知道的边界

7.1 最重要的一条：优先自建，不要把公共实例当生产基础设施

这是本文最想强调的一点。按照 Xget 技能文档和存储库 README 的口径，xget.xi-xu.me 更适合作为演示和快速体验入口，而不是默认生产地址。真正要长期使用时，应优先使用你自己的域名，例如：

https://xget.example.com

这样你才能控制可用性、鉴权、限流、访问策略和数据路径。

7.2 自托管不等于天然拥有全球边缘能力

如果你把 Xget 跑在一台普通云服务器上，它依然是有价值的，但性能表现主要取决于：

你的服务器所在地域
到上游平台的链路质量
你的缓存命中率
反向代理与 TLS 配置

也就是说，Cloudflare Workers 形态和单机 Docker 形态都叫 Xget，但它们的性能上限并不一样。

7.3 仍然要遵守上游平台条款与本地法律

Xget 是统一加速入口，不是免责工具。无论你访问代码、包、镜像还是 AI API，都仍然要遵守对应平台的服务条款、限流规则、版权要求和当地法律法规。对于公开暴露的自建实例，还要额外考虑鉴权、滥用防护和流量成本。

结语

如果让我用一句话总结 Xget，我会说：它不是某一个生态里的“镜像站替代品”，而是一个试图把代码存储库、包管理、容器镜像和 AI 推理 API 统一起来的开发者资源加速网关。

它最吸引人的地方，不只是支持平台多，而是它把“统一入口、统一路径规则、统一部署方式、统一安全边界”这几件事做成了一个完整产品。对于只想加速一次下载的人来说，它已经够用；对于想把整个开发资源访问链路做成基础设施能力的团队来说，它则更值得认真研究。

如果你接下来还想继续深入，我建议下一步直接去看两个东西：一是 Xget 存储库的 README 和 src/config/platforms.js，二是那篇偏技术实现的《深入剖析 Xget》。一个帮你理解“现在能做什么”，一个帮你理解“它为什么能做到这些”。