Go 1.27 go 命令不再支持 bzr：旧模块源怎么迁移

升级到 Go 1.27 后，旧项目可能突然无法下载托管在 Bazaar（bzr）服务器上的模块。官方发布说明给出的边界很明确：go 命令不再支持 bzr，也不能再直接抓取 bzr 模块。这里的关键词是“直接抓取”——如果版本已经由模块代理提供，或者开发机缓存中仍有副本，问题可能暂时不出现，直到新的 CI 节点、清理缓存或请求新版本时才暴露。

先判断依赖是在走代理还是直连仓库

GOPROXY 决定模块下载的入口。配置中的代理地址会先联系“模块代理”；关键字 direct 才表示直接联系版本控制系统。代理协议会提供 .info、.mod、.zip 等文件，因此客户端拿到完整模块产物时，不需要认识后端原来使用什么仓库。

私有模块还要查看 GOPRIVATE 和 GONOPROXY。一旦某个路径绕过代理，就会进入直连边界；此时 GOVCS 负责限制允许调用的工具，但 Go 1.27 已没有 bzr 支持，所以即使旧的 bzr 仓库 可以访问，也无法靠放宽变量恢复。下图把两条路径放在同一张图中：GOPROXY 可以走 模块代理，由它交付 .info、.mod、.zip；也可能落到 direct，再经过 GOVCS 触及 bzr 仓库。

两条迁移路线怎么选

第一条是仓库迁移：把历史和仍需维护的版本镜像到 Git 或 Mercurial，尽量保持稳定模块路径，再重新核对版本标签与模块目录。它适合仍在迭代的内部库，也是最容易长期维护的方案。

第二条是代理托管：为暂时不能迁移的固定版本准备符合 GOPROXY 协议的产物。Go 官方模块参考说明，代理可以直接提供模块，适合组织不暴露仓库，或使用客户端不支持的版本控制工具。但代理不是实时“翻译器”；必须确认所需版本已形成不可变的元数据、go.mod 和源码压缩包。

迁移后用干净缓存验收

不要只在原开发机上运行一次。先记录当前环境，再在隔离环境清理模块缓存并重新下载：

go env GOPROXY GOPRIVATE GONOPROXY GONOSUMDB GOVCS
go clean -modcache
go mod download
go list -m all

如果走仓库迁移，检查 Git 镜像 是否保留了需要的 版本标签，并让 稳定模块路径 与代码中的导入路径一致。随后核对 go.mod 和 go.sum，再使用 干净模块缓存 触发 CI 构建。最后保存 回滚记录，包括原仓库、代理地址、版本映射和切换时间，避免缓存命中掩盖迁移缺口。

常见问题

把 GOVCS 配成包含 bzr，Go 1.27 就能继续下载吗？

不能。GOVCS 是允许列表，不会重新加入已从 go 命令移除的实现。应改用受支持的仓库，或让模块代理直接提供模块产物。

为什么本地能构建，新的 CI 却失败？

本地可能命中了模块缓存或企业代理，新的 CI 则需要下载缺失版本并回退到 direct。用干净缓存复测，并比较两边的 GOPROXY、GONOPROXY 与代理中实际存在的版本。

先封住直连缺口，再安排长期迁移

处理顺序应是先确定失败路径，再选择仓库迁移或代理托管，最后用无缓存环境验收。不要用旧开发机的一次成功替代迁移证明，也不要把 GOVCS 当成兼容开关。真正的完成标准，是目标版本可以从受控来源稳定重建。

参考：Go 1.27 Release Notes、Go Modules Reference、Managing dependencies。