旧Go项目依赖必须迁移到module机制，否则构建失败；需先识别Godeps.json、vendor/、glide.yaml或Gopkg.toml等旧格式，再用go mod init和go get还原依赖，清理vendor和GOPATH残留，并处理隐式导入及无tag commit等手动难题。
旧 Go 项目依赖记录（如 Godeps.json、vendor/ 目录或 glide.yaml）不能直接复用，必须重解析并转为现代 Go module 机制 —— 否则 go build 会报错或漏包。
识别你手头的旧依赖格式到底是什么
老项目可能混用多种管理方式，先确认类型再选迁移路径，否则一步走错全盘重来：
- 检查根目录是否存在
Godeps.json：这是godep工具生成的，常见于 Go 1.5–1.10 时期项目 - 看是否有
vendor/目录且含vendor.json或manifest：大概率是govendor - 若存在
glide.yaml+glide.lock：属于已归档的glide工具 - 没有以上但有
dep相关文件（Gopkg.toml）：Go 官方曾短暂支持的dep工具
用 go mod init + go mod edit 手动还原依赖版本
Go 1.16+ 默认启用 module 模式，go get 不再读取旧 vendor 或 lock 文件；必须显式初始化并补全依赖项：
- 执行
go mod init example.com/your-old-project（模块路径尽量与原 import 路径一致，否则后续 import 会出错） - 若原项目有
vendor/目录，可临时用go list -m all查当前已知模块，但不会自动包含 vendor 中未被 import 的包 —— 需人工核对vendor/下的每个子目录名是否出现在代码import中 - 对每个缺失依赖，运行
go get github.com/some/old@v1.2.3（版本号从旧Godeps.json的Rev字段或glide.lock中提取） - 遇到
go: downloading却仍报cannot find module？说明该包已被归档、重命名或迁移到新路径，需查其 GitHub 主页的 README 是否标注了新 import 路径
处理 vendor 目录残留和 GOPATH 冲突
旧项目常依赖 GOPATH 和本地 vendor/，而 Go module 默认忽略这两者 —— 不清理会导致行为不一致：
立即学习“go语言免费学习笔记（深入）”；
- 删除
vendor/目录前，先运行go mod vendor确认新 module 能完整拉取所有依赖；成功后再删旧vendor/ - 确保环境变量中未设置
GOPATH（或设为空），否则某些老脚本可能误触发 GOPATH 模式 - 检查
.bashrc或 CI 配置中是否硬编码了GO111MODULE=off，必须改为on或删掉该行（Go 1.16+ 默认开启） - 如果项目里有
import _ "some/old/init"这类隐式导入，go mod tidy会删掉它 —— 需手动加回，并用//go:linkname或go mod edit -require锁定
真正麻烦的不是命令怎么敲，而是旧依赖里那些没打 tag 的 commit、私有仓库路径变更、或已被作者删库的 fork —— 这些得一个个手动存档或替换镜像地址。别指望自动化工具能覆盖全部。
