为什么你的 Go 私有模块不该直接用 GitHub 路径
一个真实的噩梦 去年，我朋友老张的公司做了一个"很正常的决定"——把代码从 GitHub Enterprise 迁移到自建 GitLab。 听起来不复杂对吧？代码搬过去，CI 改改，完事了。 直到他们发现：公司 200 多个 Go 微服务的 import path 全是以 github.com/their-org/ 开头的。 迁移代码仓库只需要一个周末。但修改所有下游服务的 import path？3 个工程师干了两个星期。改完还要回归测试，又是一周。 老张事后跟我说了一句话，我至今记得： “如果当初用了 vanity URL，这一切只需要改一条 DNS 记录。” 这篇文章，就是写给还没踩这个坑的你。 四大隐患 隐患一：平台锁定——换 Git 服务 = 改所有 import Go 模块的 import path 就是它的身份标识。当你写： import "github.com/your-org/user-service" 你实际上是在说：这个模块永远住在 GitHub 上。 想迁移到 GitLab？改 import。想迁移到 Gitea？改 import。想迁移到自建 Gitea？还是改 import。 而且不只是改一个地方——是所有引用了这个模块的项目、所有下游服务、所有 go.mod 文件。对于中型团队，这可能意味着 数百个文件的批量修改 + 全量回归测试。 这不是假设。Go 社区里几乎每年都有公司因为 Git 平台迁移而经历 “import path 大逃亡”。 隐患二：IP 地址和内网信息裸奔 比 GitHub 锁定更危险的是自建 Git 服务器的场景。很多公司内部直接用 IP 地址或内网域名： ...