Go 语言禁止在非本地（non-local）包中使用相对路径导入（如 ./package1），仅支持标准库、模块路径或显式 GOPATH/src 下的完整导入路径；项目重命名需同步更新 go.mod 模块声明及所有 import 路径，否则将导致构建失败。
go 语言禁止在非本地（non-local）包中使用相对路径导入（如 `./package1`），仅支持标准库、模块路径或显式 gopath/src 下的完整导入路径；项目重命名需同步更新 `go.mod` 模块声明及所有 `import` 路径，否则将导致构建失败。
在 Go 语言中，import 语句的本质是按模块路径解析包位置，而非简单地按文件系统相对路径查找。你遇到的错误：
can't load package: local import "./package1" in non-local package
根本原因在于：Go 自 1.0 起即明确禁止在非命令行直接运行（go run 单文件）场景下使用相对导入路径（./... 或 ../...）。该限制并非版本缺陷，而是设计约束——它强制开发者采用可复现、可共享、路径稳定的导入方式。
⚠️ 注意：虽然 Go 1.10+ 在 go run main.go 这类单文件执行场景中临时允许 ./subpackage 形式的相对导入（用于快速原型验证），但go build、go test、go install 等构建命令始终拒绝该写法，且官方文档与 Go 工程规范（golang.org/doc/code.html#Library）明确将其列为反模式。
✅ 正确导入方式：使用完整模块路径
以你的项目结构为例：
立即学习“go语言免费学习笔记（深入）”；
$GOPATH/src/project1/ ├── package1/ │ ├── file1.go // package package1 ├── package2/ │ └── util.go // package package2 └── main.go // package main
应在 main.go 中写为：
package main
import (
"project1/package1"
"project1/package2"
"project1/package3"
)
func main() {
package1.DoSomething()
}该路径 project1/package1 实际对应 $GOPATH/src/project1/package1/，Go 编译器据此定位源码并校验 package package1 声明是否一致。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
? 项目重命名：不只是改文件夹名
当 project1 需升级为 project1v2（例如因重大重构或版本迭代），必须同步完成以下四步，缺一不可：
-
重命名目录
mv $GOPATH/src/project1 $GOPATH/src/project1v2
-
更新 go.mod 模块声明（若启用 Go Modules）
cd $GOPATH/src/project1v2 go mod edit -module github.com/yourname/project1v2 # 推荐使用 GitHub 路径 # 或保持本地路径（仅限私有开发）： # go mod edit -module project1v2
-
批量替换所有 import 路径
使用 sed（Linux/macOS）或 findstr + PowerShell（Windows）全局替换：# 替换所有旧路径（含子包） grep -rl 'project1/' . | xargs sed -i '' 's/project1\//project1v2\//g' # 注意：若用 GitHub 路径，应替换为 github.com/yourname/project1v2/
-
验证并清理缓存
go mod tidy # 重新解析依赖，生成新 go.sum go list ./... # 列出所有有效包路径，确认无残留 project1
? 提示：使用 go list -f '{{.ImportPath}}' ./... 可快速检查当前项目实际生效的所有导入路径，避免遗漏深层子包。
? 为什么不能只靠别名或相对路径“绕过”重命名？
- 别名（如 p1 "project1/package1"）无法解决模块路径变更问题：别名仅作用于当前文件内标识符，go build 仍需按原始路径 project1/package1 查找源码；若目录已重命名而 import 未更新，直接报 cannot find module。
- 相对路径 ./package1 是构建时禁用项：即使重命名后手动改为 ./package1v2，go build 仍会拒绝，且丧失跨环境可移植性（CI/CD、他人协作时必然失败）。
✅ 最佳实践总结
| 场景 | 推荐做法 | 说明 |
|---|---|---|
| 新项目初始化 | go mod init github.com/username/repo-name | 使用唯一、可公开访问的模块路径，避免 project1 等模糊名称 |
| 包组织 | 目录名 = package 声明名（小写、无下划线） | 如 ./utils/ → package utils，提升可读性与 IDE 支持 |
| 版本管理 | 通过模块路径区分大版本，如 github.com/user/lib/v2 | 配合 go get github.com/user/lib/v2，无需重命名仓库 |
| 重命名安全操作 | 先 go list ./... 记录旧路径 → 批量替换 → go mod tidy → 全量测试 | 防止 import 路径断链 |
最后强调：Go 的包导入机制是其工程可靠性的基石——它用路径确定性换取了构建可重现性。放弃相对路径、拥抱显式模块路径，不是妥协，而是对可维护性与协作效率的主动投资。
