对比

govanity 是什么？ govanity 是 Google 提供的 go-import meta 标签服务参考实现。它是一个单独的 Go 二进制文件，读取一个 YAML 配置文件，然后响应 ?go-get=1 请求返回正确的 meta 标签。 # govanity.yaml paths: /auth: repo: https://github.com/org/auth-service vcs: git /logger: repo: https://github.com/org/logger vcs: git 部署它，把域名指向它，就能工作。对于合适的场景，它是一个不错的工具。 不足之处 痛点一：基础设施你自己扛 govanity 是你自己运行的二进制文件。这意味着：一台服务器（或容器）、进程管理、健康检查、日志采集，以及凌晨 3 点它崩了得有人起来处理。“不就是个小 Go 程序嘛”——直到它出问题的时刻。 痛点二：不自带 HTTPS govanity 只提供纯 HTTP 服务。你需要在前面加一层反向代理（Nginx、Caddy、Cloudflare）来实现 HTTPS。这又是一个需要配置、监控和维护的组件。 痛点三：只有配置文件，没有 CLI 添加路由意味着编辑 YAML 文件然后重启进程。没有 govanity add 命令，没有 API，没有编程式的管理方式。5 条路由的时候没问题，50 条的时候就变成了一次部署事件。 痛点四：不支持通配或模式匹配 每条路由都必须在配置文件中单独列出。如果你的组织在 github.com/org/ 下有 100 个仓库，你得写 100 条 YAML 配置。不支持 glob，不支持模板，不支持通配符。 逐项对比 维度 govanity（自托管） gvu（托管） 搭建 编译二进制 + 写 YAML + 部署 + 反向代理 `curl … HTTPS 手动（反向代理 + 证书管理） 自动 路由管理 编辑 YAML + 重启进程 CLI（gvu add / gvu remove） 通配路由 不支持 * 模式，一条规则 go-source 标签 不生成 自动识别 GitHub/GitLab/Bitbucket 主版本支持 每条路由手动配 自动（/v2、/v3…） 运维负担 服务器 + 进程 + 代理 + 证书 零 多设备同步 共享配置文件（Git？） 基于账户，自动 自定义域名 手动 DNS + 代理配置 CNAME + 自动 TLS 监控 / 告警 自己搭建 已包含 成本 服务器费用 + 你的时间 免费套餐可用 什么时候适合 govanity govanity 适合以下场景： ...

DIY 方案 Go 的 go-import meta 标签机制本身很简单。你在网页上放这么一行： <meta name="go-import" content="go.yourcompany.com/user-svc git https://github.com/org/user-svc"> go get 就知道去哪里拉代码。听起来很简单——那为什么不直接手写几个 HTML 文件，用 Nginx 来提供服务呢？ 很多团队一开始就是这么干的。接下来会发生什么，往下看。 问题出在哪里 痛点一：一个模块 = 一个 HTML 页面 + 一条 Nginx 规则 每个 vanity import path 都需要自己的 HTML 页面（包含正确的 meta 标签），加上 Nginx 的 location 块来处理 ?go-get=1 检测。5 个模块还管得过来，50 个模块就是 50 个 HTML 文件和 50 条 Nginx 规则。 痛点二：HTTPS 证书管理 你的 vanity 域名需要 HTTPS。这意味着要申请并自动续签 TLS 证书（Let’s Encrypt 之类），在 Nginx 中配置，还要监控过期时间。一张证书过期，所有模块的 go get 全部挂掉。 痛点三：没有管理界面 添加或删除路由意味着：SSH 登录服务器，编辑 HTML 文件，修改 Nginx 配置，跑 nginx -t，然后 reload。没有 CLI，没有 API，没有操作记录。 ...