本地包路径必须以 ./ 或 ../ 开头，不可用裸名称；同模块内子目录包自动识别，无需写入go.mod；避免循环导入，测试时注意工作目录影响资源定位。
本地包路径必须以 ./ 或 ../ 开头
Go 不允许直接用裸名称（比如 myutils）引用当前模块下的子目录包。如果你的项目结构是 ./cmd/main.go 和 ./pkg/myutils/utils.go，在 main.go 中导入时必须写成："./pkg/myutils" 或 "../pkg/myutils"（取决于当前文件位置），否则会报错 cannot find package。
常见错误是误写为 "myutils" 或 "project/pkg/myutils" —— Go 模块系统不支持这种“项目内别名”或“绝对路径式导入”。
- 只有
go mod init初始化后的模块根目录下，才能用相对路径导入本地子目录 - 如果在
cmd/下运行go run main.go，而main.go试图导入"./pkg/myutils"，这是合法的；但若从项目根运行go run cmd/main.go，导入路径就得改成"pkg/myutils"（此时已在模块根，可省略./） - 路径区分大小写，
"pkg/MyUtils"和"pkg/myutils"是两个不同包
go.mod 文件里不需要手动添加本地包
go.mod 只记录外部依赖（如 github.com/sirupsen/logrus）和模块声明（module example.com/myapp），所有同模块内的本地子目录包都会被自动识别，无需、也不能在 require 或 replace 中声明它们。
如果你看到有人在 go.mod 里写了 replace myutils => ./pkg/myutils，那是错的——这会导致构建失败或导入冲突，因为 myutils 根本不是独立模块，也没有版本号。
立即学习“go语言免费学习笔记（深入）”；
- 本地包只要目录里有
.go文件且含有效package声明，就能被同一模块内其他代码导入 - 如果本地包目录下有
go.mod（哪怕空文件），它会被视为独立模块，反而破坏本地引用逻辑 -
go list -f '{{.Dir}}' ./pkg/myutils可快速验证 Go 是否能定位到该包
避免循环导入：两个本地包不能互相 import
Go 编译器会在构建阶段报错 import cycle not allowed，例如 pkg/a/a.go 导入 "./b"，而 pkg/b/b.go 又导入 "./a"。这不是运行时问题，而是编译期硬性限制。
实际项目中容易在工具类与配置类之间无意形成循环：比如 pkg/config 依赖 pkg/log 打日志，而 pkg/log 又读取 pkg/config 获取日志级别 —— 这种耦合必须拆解。
- 把共享逻辑抽成第三个包（如
pkg/common），由 a 和 b 分别导入 - 用接口 + 依赖注入替代直接导入，比如
log.Init(logger.Config)而非config.GetLogLevel() -
go build -v ./...能暴露隐藏的循环路径，比单个go build更早发现问题
本地包测试需注意工作目录和 go test 路径
执行 go test 时，当前工作目录决定了哪些包会被发现。如果你在 pkg/myutils 目录下运行 go test，它只测试该包；但在项目根运行 go test ./pkg/...，则会递归测试所有匹配子目录。
容易踩的坑是：本地包里用了相对路径读配置文件（如 os.ReadFile("config.yaml")），测试时工作目录不同导致文件找不到 —— 这和导入无关，但常被误认为是包管理问题。
- 测试中读取本地资源，推荐用
filepath.Join(filepath.Dir(runtime.Caller(0).File), "config.yaml")定位到测试文件所在目录 - 本地包的
example_test.go必须和对应包在同一目录，且package myutils_test才能正确关联 - 不要在本地包里调用
os.Exit(1)，这会让go test提前退出，掩盖真实失败原因
import 语句，在不同目录下运行 go build 可能成功或失败。盯住 go env GOPATH 和当前工作目录，比背命令更重要。 
