go mod tidy 不删除废弃 import 和空包引用，因其只管理 go.mod/go.sum 中声明的依赖，不扫描源码实际使用情况，且默认保留间接依赖；需手动检查并清理 replace、vendor 及幽灵引用。
为什么 go mod tidy 不能自动删掉废弃的 import 和空包引用
因为 go mod tidy 只管理 go.mod 和 go.sum 中的依赖声明，它不会扫描源码里是否还实际用到某个包——哪怕你已经把所有 import "github.com/some/old" 都删了，只要 go.mod 里还留着那行 require github.com/some/old v1.2.0，它就认为“合法”。更麻烦的是，有些旧模块被间接依赖（比如通过 transitive dependency），go mod tidy 默认不清理它们。
- 运行
go mod graph | grep old-module查看谁在拉它 - 用
go list -m all | grep old-module确认是否仍出现在模块列表中 - 如果确认无直接或间接引用，手动从
go.mod中删掉对应require行，再跑一次go mod tidy
如何识别并删除已弃用但仍在 go.mod 中残留的 replace 指令
replace 是迁移中最容易被遗忘的“钉子户”：当初为临时绕过 bug 或等待新版本加的，后来主模块升级了、问题修复了，但 replace 还躺在那儿，导致构建时实际加载的是旧代码，甚至引发类型冲突或 panic。
- 检查
go.mod中所有replace行，对照当前require版本——如果目标模块版本号 ≥ replace 指向的版本，大概率已失效 - 临时注释掉某条
replace，运行go build ./...；若无报错且测试全过，说明它真没用了 - 特别注意
replace指向本地路径（如./local-fix）的，迁移后必须删，否则 CI 会失败
清理残留的 vendor 目录时为什么不能直接 rm -rf vendor
如果你项目曾启用 go mod vendor，又切换回 module mode（即不再用 vendor），直接删目录看似干净，但可能触发两个隐藏问题：一是某些 IDE（如 GoLand）缓存了 vendor 路径索引，删完后提示 “package not found”；二是 go build -mod=vendor 这类显式指令若残留在 CI 脚本或 Makefile 里，会因找不到 vendor 目录而中断。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 先执行
go env -w GOFLAGS="-mod=readonly"（或确保环境变量未设GOFLAGS=-mod=vendor） - 搜索整个项目：
grep -r "\-mod=vendor" . --include="*.sh" --include="Makefile" --include="*.yml" - 确认无任何地方显式启用 vendor 后，再
rm -rf vendor；之后建议运行go mod verify验证校验和一致性
旧模块的 type alias 或 interface 实现为何会在迁移后突然报错
当旧模块 A 定义了 type Foo struct{}，新模块 B 也定义了同名 Foo，即使你已删掉对 A 的 import，但如果某处还残留着 var x A.Foo（哪怕只是注释里的示例代码），go vet 不报，但 go build 会因未解析的标识符失败——这类“幽灵引用”常藏在测试文件、example_test.go 或文档注释里。
立即学习“go语言免费学习笔记（深入）”；
- 用
grep -r "\.OldModule" . --include="*.go"全局搜模块名缩写或旧 import 路径 - 重点关注
example_*.go、*_test.go、doc.go这三类易被忽略的文件 - 启用
go list -f '{{.Deps}}' ./... | grep OldModule，看是否仍有包依赖它（说明某处 import 没删干净）
真正难的不是找到旧逻辑，而是确认它“彻底没被任何隐式路径加载”。多跑几次 go list -deps -f '{{.ImportPath}}' . | sort -u，比对着删，比靠感觉靠谱。
