Gvu

对于已经在生产环境中运行多年 govanityurls + Nginx 或其他私有模块拉取方案的 Go 开发团队而言，如何低成本地将庞大的私有模块映射迁移至更现代的工具是一大痛点。本文详细记录了一次将历史遗留体系真实迁移至命令行工具 gvu 的全过程。文章首先澄清了开发者常犯的认知误区，明确区分了 Vanity URL 解析（gvu 负责）与模块内容拉取（GOPROXY 负责）的底层边界。随后，通过详尽的步骤复盘，展示了如何盘点存量 vanity.yml 映射，并通过 gvu 的杀手级功能——Wildcard Routing（通配符路由），将原本需要逐条维护的十几个仓库映射，极简压缩为一条规则，从而彻底解放了团队配置和重载 Nginx 的运维压力。最终对比表明，迁移至 gvu 不仅实现了映射管理的零运维，更利用自定义域名和优先级路由机制，完美兼顾了历史老库的平滑过渡与未来Go代码仓库的高效扩张。

Go 语言在公共依赖管理上已足够成熟，但私有模块的拉取依然是许多团队和个人开发者频繁踩坑的痛点。本文是一份全景式的实战指南，旨在一次性讲透 Go 私有模块拉取的底层机制与最佳落地实践。

上一篇文章的结尾我留了个坑——“这篇不是产品说明书，后面会单独写如何上手的文章”。今天这篇就是还债：gvu 正式开放公测，这是一个专门解决 Go 私有 module vanity import path 分发和拉取问题的命令行工具。这篇文章带你 5 分钟走完从安装到跑通拉取第一个私有 module 的全过程。

大约5年前，我写过两篇关于“如何在小厂内部搭建私有 Go module 拉取方案”的文章。这套方案在公司内部用了五年，基本没出过大问题。直到今年，我们第一次把 Go 私有库以白盒方式交付给客户，才发现真正的麻烦从来都不在“内部”——而在于代码一旦离开你的组织边界，所有关于私有 module 的假设都会失效。这篇文章记录了这五年的认知升级，以及为什么我最终把这套认知做成了一个名为gvu的命令行工具。