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 run等命令就拒绝解析以 ./ 或 ../ 开头的本地导入路径——除非在极少数调试场景下使用 go run *.go 直接运行单个文件（此时Go会临时推导包路径，但该行为不可靠、不推荐用于生产项目）。
✅ 正确的本地包导入方式
在传统GOPATH工作区（如提问中 $GOPATH/src/project1/ 结构）下，导入路径必须与 $GOPATH/src/ 下的完整子路径严格对应：
$GOPATH/src/
└── project1/
├── main.go # package main
├── package1/
│ └── file1.go # package package1
└── package2/
└── helper.go # package package2则 main.go 中应写：
import (
"project1/package1"
"project1/package2"
)? 原理说明：Go将 $GOPATH/src 视为逻辑根目录，"project1/package1" 表示从该根出发的路径，而非文件系统相对路径。这也是为何 ./package1 报错 local import in non-local package —— Go认为你在非“本地开发包”（即未处于 $GOPATH/src 子目录顶层）中尝试非法本地引用。
立即学习“go语言免费学习笔记（深入）”；
? 迈向模块化：Go 1.11+ 的标准实践
自Go 1.11引入模块（go mod）后，GOPATH模式已逐步淘汰。现代项目应主动初始化模块，并采用语义化、可移植的模块路径：
cd /path/to/project1 go mod init github.com/yourname/project1 # 推荐使用GitHub/GitLab等实际托管地址
生成 go.mod 后，目录结构不变，但导入路径即为模块名 + 子目录：
// main.go
import (
"github.com/yourname/project1/package1"
"github.com/yourname/project1/package2"
)✅ 优势显著：
- 路径唯一、可公开引用（他人可 go get github.com/yourname/project1）；
- 支持版本管理（go get github.com/yourname/project1@v2.0.0）；
- 完全脱离 $GOPATH 约束，项目可置于任意路径。
? 项目重命名：不是改文件夹名那么简单
若将 project1 重命名为 project1v2，仅执行 mv project1 project1v2 是无效且危险的。必须同步完成以下操作：
| 位置 | 需修改内容 | 示例 |
|---|---|---|
| go.mod 文件 | module 声明行 | module github.com/yourname/project1v2 |
| 所有 .go 文件 | import 语句前缀 | "github.com/yourname/project1/package1" → "github.com/yourname/project1v2/package1" |
| CI/CD脚本、Dockerfile、文档等 | 硬编码路径或模块名 | go test github.com/yourname/project1/... → ...project1v2/... |
| （可选）代码内字符串 | 日志、配置、CLI help文本中出现的项目名 | "project1 v1.2" → "project1v2 v1.2" |
? 提示：使用 grep -r "project1/" . --include="*.go" 全局搜索旧路径；go list -f '{{.ImportPath}}' ./... 可验证当前所有生效包路径是否已更新。
⚠️ 注意事项与避坑指南
- 包名 ≠ 导入路径：package package1 是代码内标识符作用域，而 "github.com/yourname/project1/package1" 才是导入路径。二者可不同（如 import p1 "github.com/yourname/project1/package1"），但强烈建议保持一致以提升可维护性。
- 不要混用 GOPATH 与 module 模式：若项目含 go.mod，Go 1.16+ 默认禁用 GOPATH 查找逻辑。残留的 $GOPATH 环境变量可能引发路径解析冲突，建议开发时清空或明确设置 GO111MODULE=on。
-
跨模块引用？用 replace：当主项目需引用尚未发布的本地模块（如 project1v2 在开发中），可在主模块 go.mod 中添加：
replace github.com/yourname/project1v2 => ../project1v2
此后仍按正常路径 import "github.com/yourname/project1v2/package1" 使用。
✅ 总结：一条清晰路径
Go 的哲学是 “显式优于隐式”。它拒绝模糊的相对路径，要求你明确声明模块身份与包归属。因此，正确的工程实践链条是：
初始化模块（go mod init）→ 使用规范模块路径导入 → 重命名时全局同步更新路径 → 借助工具校验（go list, go mod tidy）。
这不仅解决命名冲突，更构建出可协作、可版本化、可长期演进的Go项目基础设施。
