Go语言没有全局模块，正确做法是通过模块路径和pkg/目录组织可复用代码，用internal/限制作用域，依赖go.mod实现项目自包含。
Go 语言没有“全局模块”这个概念——所谓“全局”，其实是误用术语带来的认知偏差。真正的解法不是设法让某个包“全局可用”，而是通过模块路径、导入路径和包可见性规则，让共享逻辑在**语义上清晰、物理上可控、访问上受限**。
为什么不能直接 import "global"
Go 的包系统基于文件系统路径和模块声明，不存在类似 Python 的 sys.path 或 Node.js 的 node_modules 全局注册表。你写 import "global" 会直接报错：cannot find module providing package global。常见错误现象包括：
- 编译失败，提示
no required module provides package global - 强行创建
global包但被多个子模块重复导入，导致循环依赖或版本冲突 - 把工具函数全塞进
main包，结果其他包无法引用，只能复制粘贴
正确做法：用 pkg/ + 显式导入替代“全局”
把真正可复用、无业务耦合的通用能力（如日志封装、错误包装、HTTP 工具）抽成独立包，放在 pkg/ 目录下，并通过模块路径导入。例如：
项目结构：
myapp/
├── go.mod
├── cmd/
│ └── main.go
├── pkg/
│ └── util/
│ └── http.go
└── internal/
└── api/
└── handler.go
pkg/util/http.go 内容：
package util
<p>import "net/http"</p><p>func NewClient(timeout int) <em>http.Client {
return &http.Client{Timeout: time.Duration(timeout) </em> time.Second}
}</p>
在 internal/api/handler.go 中使用：
package api
<p>import (
"myapp/pkg/util" // ← 模块路径，非“全局名”
)</p><p>func Handle() {
client := util.NewClient(30)
}</p>
关键点：
-
myapp是你在go mod init myapp时声明的模块路径，它决定了所有内部导入的根 -
pkg/下的包可被项目内任意位置导入，但不可被外部项目 import（除非你明确发布为公共库） - 不要试图在
go.mod里用replace把pkg/util映射成global——这只会破坏可读性和工具链识别
internal/ 是比“全局”更安全的选择
如果你的“全局逻辑”只服务于本项目，且不希望被外部引用（比如数据库初始化、配置加载器），就放进 internal/。Go 编译器会强制拦截跨边界导入：
-
internal/db/init.go只能被internal/或其父目录（即项目根）下的代码 import -
cmd/main.go可以 importinternal/db，但pkg/util不可以 - 一旦有人在外部项目里写
import "myapp/internal/db"，go build直接失败
这种约束不是限制，而是提前暴露设计问题：如果某个“全局”功能真需要被外部复用，它本就不该待在 internal/ 里。
别碰 GOPATH 或硬链接模拟“全局”
老方案如把工具包放在 $GOPATH/src/global，再用符号链接拉进项目，已彻底过时：
-
GO111MODULE=on时，go build会忽略$GOPATH/src下未声明模块的代码 - VS Code 和
gopls无法正确解析硬链接路径，跳转/补全失效 - CI 流水线中无
GOPATH环境，构建必然失败
Go Modules 就是为此而生：每个项目自包含，go.mod 是唯一真相源。所谓“优雅”，就是接受这套规则，而不是绕开它。
最容易被忽略的一点：模块路径（go mod init xxx 的参数）不必对应真实域名，但必须保证在当前代码仓库内唯一且稳定。改一次，所有 import 都得跟着动——这不是负担，而是对依赖关系的显式承诺。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
