弃用模块仍可使用，但存在兼容性风险和维护隐患；需手动检查Deprecated状态、更新import路径、验证类型与行为一致性，并清理go.sum残留。
模块被标记为 deprecated 后还能用吗
能用，但 Go 不会阻止你 import 或调用，go list -m -u all 也不会报错，只有人看 go.mod 里那行 // Deprecated: ... 注释才知道。真正影响的是生态信任度和后续维护——比如 gopkg.in/yaml.v2 已停更，而官方推荐迁移到 gopkg.in/yaml.v3 或 github.com/go-yaml/yaml/v3。
常见错误现象：go get github.com/some/old@latest 仍成功，但编译时出现未定义符号（如 yaml.Unmarshal 行为变化）、或运行时报 panic: reflect: Call of nil function（因内部接口重写）。
- 检查方式：运行
go list -m -f '{{.Deprecated}}' github.com/some/old，返回非空字符串即已弃用 - 不要只依赖
go get -u自动升级——它可能跳过 major 版本，比如从v1.2.0升到v1.9.9，却跳过v2.0.0+incompatible - 弃用模块的
go.sum条目不会自动清理，残留哈希可能干扰校验
替换模块时如何避免 import 路径冲突
Go 的模块路径即导入路径，github.com/old/repo 和 github.com/new/repo 是两个完全独立的命名空间。但若新模块刻意兼容旧路径（如通过 replace 或 fork 后保留原 path），就容易引发符号重复、类型不兼容等隐性问题。
典型场景：把 github.com/golang/protobuf 迁移到 google.golang.org/protobuf，两者虽功能相似，但 proto.Message 接口不互通，proto.Marshal 返回值类型也不同。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须全局搜索项目中所有
import "github.com/golang/protobuf/...，逐个改为import "google.golang.org/protobuf/... - 不能只改
go.mod里的replace，否则旧 import 仍会加载老代码，导致类型断言失败 - 若新模块使用了
/v2后缀（如github.com/foo/bar/v2），则 import 必须显式带/v2，否则 Go 会当作不同模块处理
go.mod 中 replace 与 require 的优先级关系
replace 永远高于 require，无论是否在同一个 go.mod 文件里。这意味着：子模块声明了 require github.com/old/x v1.0.0，只要根模块写了 replace github.com/old/x => github.com/new/x v2.0.0，所有地方都会走新路径。
但副作用明显：IDE 可能无法正确跳转（因 GOPATH 模式下缓存了旧路径），go mod graph 显示的依赖图也会失真。
- 临时调试可用
replace，但上线前必须删除，并确保require指向真实新模块路径 -
replace不解决版本语义问题——比如把v1.5.0替换成v2.0.0，但没改 import 路径，就会触发incompatible错误 - 跨组织迁移时（如从
github.com/abc/log到github.com/xyz/log），replace是唯一能绕过路径锁定的方式，但需同步修改所有.go文件中的 import
迁移后如何验证类型兼容性与行为一致性
光跑通 go build 不代表迁移完成。很多模块废弃是因为 API 语义变更：比如 http.Client.Do 在旧版中忽略 Context 超时，新版则严格遵循；又如日志库的 Infof 参数顺序调整，会导致格式串错位。
建议在关键调用点加轻量断言：
if _, ok := someObj.(interface{ ProtoReflect() protoreflect.Message }); !ok {
log.Fatal("expected google.golang.org/protobuf, got gopkg.in/yaml.v2")
}
- 用
go vet -all检查方法签名差异（尤其 interface 实现） - 对序列化/反序列化逻辑，写对比测试：用旧模块 marshal 的字节，尝试用新模块 unmarshal，确认无 panic 且字段值一致
- 注意
go.sum中的校验和——迁移后要执行go mod tidy，否则可能混用新旧 checksum，CI 构建失败
最常被忽略的是间接依赖：某个你没直接 import 的模块可能仍依赖旧版，得用 go mod graph | grep oldname 排查，再针对性 replace 或推动上游更新。
