Go 语言通过 Go Modules 实现包路径管理，模块路径（如example.com/myapp）作为 import 基准，结合 cmd/、internal/、pkg/ 等目录约定实现分层与可见性控制，并支持 go.work 多模块协作。
Go 语言本身不依赖传统意义上的“包路径配置”，而是通过项目目录结构和 import 语句中的相对路径（基于 $GOPATH 或 module 根目录）来确定包位置。所谓“自定义包路径”，本质是合理设计模块（module）根目录、内部子目录结构与 import 路径的对应关系，从而实现清晰的代码分层管理。
以 Go Module 为基础设定统一根路径
从 Go 1.11 起，推荐使用 Go Modules 管理依赖和包路径。第一步是在项目根目录执行：
go mod init example.com/myapp
这个 example.com/myapp 就是你的模块路径前缀，后续所有本地子包的 import 路径都以此为基准。例如：
-
myapp/internal/handler→ import 路径为example.com/myapp/internal/handler -
myapp/pkg/utils→ import 路径为example.com/myapp/pkg/utils -
myapp/cmd/api→ import 路径为example.com/myapp/cmd/api
注意：模块路径不必真实可访问，但应具备唯一性和语义性，避免用 localhost 或无意义字符串。
立即学习“go语言免费学习笔记（深入）”；
按职责划分目录层级，明确包可见性
Go 推荐用目录结构表达架构意图。常见分层建议如下：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
cmd/：存放可执行入口（main.go），每个子目录对应一个二进制文件，如cmd/api、cmd/cli；这些目录下的包不能被其他模块 import（Go 规定cmd/下的包仅用于构建命令） -
internal/：存放仅本模块内使用的私有逻辑，如internal/service、internal/repository；外部模块无法 importinternal/xxx，Go 编译器会强制检查 -
pkg/：存放可被外部复用的公共组件，如pkg/auth、pkg/httpx；只要模块路径公开，其他项目就能引用 -
api/或proto/：存放 OpenAPI 定义或 Protocol Buffer 文件，配合工具生成代码
避免硬编码路径，用相对 import + 别名提升可读性
当包路径较长时（如 example.com/myapp/internal/user/usecase），可在引用处使用短别名：
import ( userUsecase "example.com/myapp/internal/user/usecase" "example.com/myapp/pkg/logger" )
同时确保 IDE（如 GoLand 或 VS Code + gopls）能正确解析路径——这依赖于当前工作目录是 module 根，且 go.mod 存在。若出现 “could not import” 错误，优先检查是否在正确目录下运行 go run 或是否启用了 Go Modules（GO111MODULE=on）。
利用 go.work（多模块协作）扩展路径管理
对于大型单体或微服务聚合项目，可使用 go.work 文件统一管理多个 module。例如：
go work init go work use ./user-service ./order-service ./shared-lib
此时你在 user-service 中 import shared-lib 时，可直接写：
import "shared-lib/pkg/auth"
前提是 shared-lib/go.mod 的 module 名为 shared-lib，且 go.work 已将其纳入工作区。这种方式让跨模块开发更自然，也便于统一构建与测试。
