Go Modules 不兼容旧 GOPATH 导入路径，仅通过 replace 指令临时映射或重定向路径，需手动更新 import 语句为模块路径，且 replace 不保证语义一致性。
Go Modules 并不“兼容”旧的 GOPATH 导入路径，而是通过模块路径映射和重写机制，让部分旧代码在迁移初期仍能编译通过——但这只是临时过渡行为，不是设计承诺，更不是长期支持。
go.mod 中的 replace 指令能覆盖旧导入路径
当项目里还残留 import "app/utils" 这类非模块化路径时，Go 不会自动识别它对应哪个模块。但你可以用 replace 显式告诉 Go：“这个路径实际指向本地某个目录”。
-
replace app/utils => ./internal/utils：把原 import 路径映射到当前项目子目录 -
replace github.com/oldorg/lib => github.com/neworg/lib v1.2.0：把旧仓库地址重定向到新模块 - 必须配合
go mod tidy才会生效，且仅影响当前模块构建，不改变源码中的 import 语句
go get 会自动重写 import 路径（仅限已知公共模块）
如果你执行 go get github.com/sirupsen/logrus，而代码中写的是 import "github.com/Sirupsen/logrus"（大小写错误），Go 1.16+ 会尝试自动修正并写入 go.mod 的 replace 条目。这不是 magic，而是基于模块 registry 的 canonical path 查询结果。
- 只对知名托管平台（GitHub、GitLab 等）的常见拼写变体生效
- 对私有路径（如
import "mycompany/pkg"）完全不处理，必须手动replace - 该行为由
GO111MODULE=on和GOPROXY共同决定，离线环境不会触发
旧 GOPATH 项目迁移到模块后，import 路径必须显式更新
从 import "utils" 改成 import "github.com/yourname/project/utils" 不是可选项，而是强制要求。Go Modules 不再解析相对于 $GOPATH/src 的路径，所有 import 都按模块路径解析。
立即学习“go语言免费学习笔记（深入）”；
- 如果模块名是
github.com/yourname/project，那么utils/目录下的包就必须被导入为github.com/yourname/project/utils - IDE（如 VS Code + gopls）通常能自动提示并批量重命名，但底层逻辑仍是文本替换，不是智能路径推导
- 遗漏某处 import 会导致
build失败，报错类似：cannot find package "utils" in any of ...
真正容易被忽略的是：replace 只解决“找得到”，不解决“语义一致”。比如把 import "legacy/db" 替换成 ./db 后，如果 ./db 里的 API 已重构，运行时 panic 不会提前暴露——过渡期要格外注意单元测试覆盖和接口契约检查。
