go不支持相对路径导入（如"./package1"），必须使用基于模块或gopath的完整逻辑路径（如"project1/package1"）；项目重命名时需同步更新go.mod中的module声明及所有import路径，不可仅改目录名。
go不支持相对路径导入（如"./package1"），必须使用基于模块或gopath的完整逻辑路径（如"project1/package1"）；项目重命名时需同步更新go.mod中的module声明及所有import路径，不可仅改目录名。
在Go语言工程实践中，相对路径导入（如 import "./package1"）是明确禁止的，这并非配置错误，而是Go构建工具链的硬性设计约束。从Go 1.0起，go build、go install等命令就拒绝解析以 ./ 或 ../ 开头的本地导入路径——除非在极特殊场景下使用 go run main.go 单文件运行（此时Go会临时推导路径，但绝不适用于生产项目或模块化构建）。你遇到的错误：
can't load package: local import "../package" in non-local package
正是Go编译器对非法相对导入的精准拦截，其底层逻辑在于：Go的import语句声明的是逻辑包路径（import path），而非文件系统路径；它必须能被全局唯一识别、可复现构建、并支持跨环境引用。
✅ 正确的本地包导入方式
1. GOPATH模式（历史兼容，不推荐新项目）
在你的结构中：
$GOPATH/src/project1/ ├── main.go ├── package1/ │ └── file1.go // package package1 ├── package2/ └── package3/
main.go 中应写：
立即学习“go语言免费学习笔记（深入）”；
import (
"project1/package1"
"project1/package2"
"project1/package3"
)⚠️ 注意：project1 是 $GOPATH/src/ 下的子目录名，不是任意自定义名；它构成完整导入路径的根。该路径必须与实际目录结构严格对应，且所有.go文件中package声明需与目录名一致（如package1/下所有文件须含 package package1）。
2. 模块模式（Go 1.11+ 推荐，现代标准）
初始化模块并设定唯一模块路径：
cd $GOPATH/src/project1 go mod init github.com/yourname/project1 # 推荐用GitHub路径，确保全局唯一
生成 go.mod：
module github.com/yourname/project1 go 1.21
此时 main.go 的导入必须匹配模块路径：
import (
"github.com/yourname/project1/package1"
"github.com/yourname/project1/package2"
"github.com/yourname/project1/package3"
)✅ 优势：路径与 $GOPATH 解耦，支持版本管理（@v1.2.0）、replace 本地调试、以及未来迁移到任意文件系统位置。
? 项目重命名：不是“改个文件夹名”那么简单
若将 project1 重命名为 project1v2，必须同步完成以下四步，缺一不可：
| 步骤 | 操作 | 示例 |
|---|---|---|
| ① 更新模块声明 | 修改 go.mod 中 module 行 | module github.com/yourname/project1v2 |
| ② 批量替换 import 路径 | 全局搜索并替换所有旧路径 | "github.com/yourname/project1/..." → "github.com/yourname/project1v2/..." |
| ③ 核查 package 声明 | 确保各子目录下 .go 文件的 package xxx 未被误改（包名 ≠ 导入路径！） | package1/ 目录下仍为 package package1，无需改为 package1v2 |
| ④ 清理缓存并验证 | 运行 go mod tidy && go list -f '{{.ImportPath}}' ./... 确认无遗漏路径 | 输出应全部以新模块路径开头 |
? 提示：使用 go list -f '{{.ImportPath}}' ./... 可一键列出当前项目所有生效的包路径，是重命名后必做的校验步骤。
⚠️ 关键注意事项与避坑指南
import 路径 ≠ 目录名，更 ≠ 包名
import "github.com/yourname/project1v2/utils" 中的 utils 是目录名，而该目录下 .go 文件必须写 package utils（二者需一致），但 utils 本身可被重命名为 helpers —— 只需同步改目录名和 package 声明即可。永远不要依赖相对导入
即使 go run ./main.go 偶然成功，也绝不可用于CI/CD或go build。它破坏可重现性，且Go官方文档《How to Write Go Code》 明确指出：“The import path is the path to the directory containing the source files, relative to either the $GOROOT or $GOPATH.”-
版本演进建议
若需长期维护多版本，优先采用语义化版本分支 + gopkg.in 或直接使用模块版本（如 github.com/yourname/project1/v2），而非重命名整个仓库。例如：go install github.com/yourname/project1@v1.5.0 go install github.com/yourname/project1/v2@latest
✅ 总结：轻量、可靠、符合Go哲学的做法
Go不提供自动命名空间隔离，也不隐式推导路径——这恰恰是其“显式优于隐式”设计哲学的体现。解决导入冲突与重命名问题，没有捷径，只有三件确定性动作：
- 弃用相对路径，始终使用完整逻辑路径（模块路径 + 子目录）；
- 重命名即重构，同步更新 go.mod、所有 import 语句、硬编码路径（CLI help、日志、配置）；
- 自动化校验，用 go list 和 go mod tidy 验证路径一致性。
坚持这套实践，你的Go项目才能真正具备可维护性、可协作性与长期生命力。
