Go 的模块路径同时是命名空间和代码地址。import 路径写成 github.com/组织名/仓库名 时，go 工具直接去这个域名下找代码，代码托管商被写进了每一行 import。把仓库迁到 GitLab 或自建 forge，import 路径就得跟着改，下游不升级就拉不到新版本。用自有域名做 vanity import path 能把这两件事拆开，换托管商时只改自己域名指向的位置，下游无感知。这个做法适合已经把 Go 库发布出去、又担心将来换平台的团队。
import 路径怎么变成代码地址的
Go 没有独立的包注册表。go get 拿到一条 import 路径，先判断它指向哪个版本控制系统，再按判出的地址拉代码。路径以 github.com 开头时，go 工具默认这是 GitHub 上的仓库，直接向这个域名发请求。
判断地址的动作是一次 HTTP 探测。go 工具请求 你的域名/模块路径?go-get=1，解析返回页面里的 go-import meta 标签，从中读出模块前缀、版本控制系统类型和真实仓库地址。官方文档把这个标签的内容固定成三段，依次是 import 前缀、vcs 类型、仓库根地址。用 GitHub 路径时这一步被跳过，域名本身就是答案。
问题出在这里。命名空间本该归团队自己管，物理位置由托管商决定，两件事写进同一串字符，改位置就必须动命名空间。
换托管商为什么像搬家
假设一个内部公共库被八个项目依赖，import 路径全是 github.com/team/lib。迁到新平台后地址变了，go 工具按旧路径继续找旧位置，新代码永远到不了下游。要改就得做一次全仓库搜索替换，再协调八个项目同步升级，任何一方没跟上，编译直接断。
外部依赖方更麻烦。库已经开源，改了 import 路径等于要求所有使用者跟着改，他们没有理由配合。很多团队于是继续给旧平台续费，一留就是好几年。
用自有域名做 vanity import path 的步骤
整套方案只需要一个域名、一台能配 HTTPS 的 Web 服务器。
- 选一个子域名，例如
go.你的域名，解析到自己的服务器。 - 在服务器上对
go.你的域名/模块路径?go-get=1这类请求返回一段静态 HTML，里面放go-import和go-source两个 meta 标签。 - 把带
go-get=1查询串的请求和普通访客的请求分流。普通访客 301 跳转到仓库页面，go 工具拿到的则是一段 HTML。 - 签一张 HTTPS 证书。Let's Encrypt 配合 certbot 就能自动续期，目录写在证书的 live 路径下。
- 仓库里的 import 全部改成
go.你的域名/模块路径。
一段可用的 nginx 配置长这样。443 端口先按查询串分流，不带 go-get=1 的跳转回仓库主页，带的则返回静态目录。跳转目标写成变量，换托管商时只改这一行。
server {
listen 443 ssl;
server_name go.example.com;
ssl_certificate /etc/letsencrypt/live/go.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/go.example.com/privkey.pem;
set $repo_home "仓库主页地址";
if ($args !~ go-get=1) {
return 301 $repo_home$request_uri;
}
root /var/www/go;
location / { try_files $uri $uri/ =404; }
}被分流转到静态目录的那份 index.html 才是关键，两个 meta 标签告诉 go 工具真实的仓库位置。go-import 的三段依次是模块前缀、版本控制系统、仓库根地址，go-source 则是给代码浏览器的目录和文件行号模板。
<meta name="go-import" content="go.example.com/lib git 仓库根地址">
<meta name="go-source" content="go.example.com/lib 仓库根地址 仓库目录模板 仓库文件行号模板">配完执行 go get go.example.com/lib 验证。能拉到代码，说明 meta 标签被正确解析。
成本与适用边界
域名和证书是持续的固定开销，一年几百元量级。多出来一台服务器和一套配置，也就多了一个要维护、要盯过期的组件。
这套方案解决的是托管商锁定，不解决别的。模块版本仍在仓库的 tag 里，仓库被删了照样拉不到。它也不提供代下载能力，拉取依然直连托管商，对方限流时该慢还是慢。
已经没人用、也不打算再发的私有脚本，直接写 github.com 更省事。真正的收益出现在库有外部用户、或者内部依赖方多到改一次 import 就要协调半年的场景。
几个常见问题
内部库也要这么配吗？ 值得。内部库的依赖方往往最多，改一次 import 的成本最高。
换平台时代码要动吗？ 不用。只改 nginx 和 meta 标签里的仓库地址，下游零改动。
必须自己写 nginx 配置？ 不是。任何能按查询串分流并返回静态 HTML 的服务都可以，用现成的 vanity import 服务也行。
会不会影响 go 命令的速度？ 多一次域名请求，可以忽略。真正的耗时在拉仓库本身。