Go 代码别被 GitHub 绑死
Don't couple your Go code to GitHub
Go 语言通过 URL 命名空间获取代码的特性虽然便捷，却容易让项目与 GitHub 深度耦合。一旦你想迁移到 GitLab 或 Azure DevOps，就必须修改所有依赖代码，这种高昂的切换成本甚至迫使一些公司同时维护多个托管平台，白白浪费资金。文章作者 Iain Cambridge 指出，解决之道是使用自定义域名（如 go.iain.rocks）来解耦代码与托管服务。通过配置 Nginx 和 HTML 元数据，你可以让域名指向任意 Git 仓库，无论后端如何迁移，用户的安装命令始终不变。对于任何商业 Go 开发团队而言，采用自定义域名是避免被单一平台锁定的最佳实践。
这听起来完全荒谬，但这却是 Go 社区中几乎成为事实的标准做法。
HN 评论区
72- p4bl0
没错，但得小心你用的域名。因为 VeriSign 可能会单方面决定把你的域名连同成千上万个其他域名一起删掉 [1]，到时候你就得从头再来了……
- thih9
> 在我看来，每个使用 Go 进行商业软件开发的团队，都应该使用自定义域名来命名空间化其内部库和包。
我觉得上面的话里可以把“Go”去掉，也就是说，同样的道理也适用于其他技术栈。
甚至在代码注释中使用 GitHub 域名链接，长期来看也会出问题。比如当发生迁移时，这些链接就会指向空无一物。
- dewey
> 也就是说，如果你把 Git 托管迁移到 GitLab，你就得改代码！
你完全可以在 go.mod 文件里加一行 "replace github.com/example/example => gitlab.com/example/example"，一切就能继续正常工作。这似乎是对一个根本不重要的问题做了过早的优化。
- okanat
正如 [^1] 所说：
> 在花了几年时间在两个方向上折腾 FFI 之后，我得出的结论是：Go 唯一靠谱的边界就是网络边界。
看来这一点也延伸到了包管理器上。Go 程序唯一靠谱的边界是 socket。Go 包管理器（如果我们能称之为包管理器的话）唯一靠谱的边界则是域名和 DNS 服务器（你自己的，或者像 gopkg.in 那样别人的）。
[^1]: https://fasterthanli.me/articles/lies-we-tell-ourselves-to-k...
- st3fan
当一家公司倒闭，其域名变成孤儿域名时，情况就非常糟糕了。下一个抢注它的人就会接管源代码，而其他人却还在依赖它。我们在其他生态系统中已经见过很多次这种情况了。这是一个非常糟糕的局面。
建议把你的包移到自己的域名下是坏主意。你绝不可能像微软那样有能力一直续费域名。人生没有 guarantees，但我敢保证，当你公司倒闭时，域名绝对是最后才会让你想到的东西。