Go项目复用包的核心是模块路径可解析、go.mod声明正确依赖、包路径与文件结构一致；本地需匹配module名和目录结构，私有仓库要配置GOPRIVATE并确保go.mod存在，多模块应避免replace而优先单模块或版本化引用。
Go 项目中复用包，核心不是“怎么导入”，而是“模块路径是否可解析 + go.mod 是否声明了正确依赖 + 包路径是否与文件结构一致”。本地复用、私有仓库复用、跨模块复用，出问题基本都卡在这三点上。
本地包复用：路径必须匹配 module 声明和目录结构
Go 不支持相对路径导入（如 import "./utils"），所有导入路径都是相对于 go.mod 中的 module 名。比如你的 go.mod 是：
module github.com/yourname/myproject
那么你新建一个 pkg/utils 目录，里面放 utils.go，就必须用：
import "github.com/yourname/myproject/pkg/utils"
而不是 "./pkg/utils" 或 "myproject/pkg/utils"。常见错误包括：
-
import "utils"→ 编译报错：no required module provides package utils - 目录是
pkg/utils，但go.mod的module是example.com/proj，却写了import "github.com/yourname/myproject/pkg/utils"→ 找不到包 - 忘记在
utils目录下写package utils（不能是package main）
私有 Git 仓库复用：要用完整域名路径，且需配置 GOPRIVATE
如果你把公共工具包放在公司内网 GitLab（如 gitlab.example.com/go/common），直接 go get gitlab.example.com/go/common 会失败——因为 Go 默认走 proxy.golang.org，而它无法访问内网地址。
解决方法分两步：
- 设置环境变量：
GOPRIVATE=gitlab.example.com/go/*（告诉 Go 这些路径不走代理、不校验 checksum） - 确保该仓库能被
git clone访问（SSH key 或 HTTPS 凭据已配置） - 在项目中 import 时，路径必须与仓库根目录的
go.mod的module一致，例如：module gitlab.example.com/go/common
→ 导入写import "gitlab.example.com/go/common"
如果仓库没有 go.mod，go get 会拒绝拉取（Go 1.16+ 默认开启 GOSUMDB=off 也不行）。
同一代码库中多模块复用：慎用 replace，优先用相对路径 + 正确 module 声明
有些项目想把 common 和 api 拆成两个 go.mod，又希望 api 能复用 common。这时容易误用 replace：
replace github.com/yourname/common => ./common
问题在于：replace 只在当前模块生效，下游项目 go get 你时，不会继承这个 replace，导致构建失败。
更可靠的做法是：
- 统一用一个
go.mod（推荐：单模块结构） - 若必须多模块，让
common发布为独立版本（如v0.1.0），api通过go get github.com/yourname/common@v0.1.0引入 - 开发阶段临时调试可用
replace，但上线前必须删掉，并确保common已推 tag
vendor 与 go.work：复用时别混淆依赖来源
启用 vendor 后，go build 默认只读 vendor/ 下的包；但 go list -m all 仍显示 go.sum 里的原始路径。这会导致“本地改了 vendor 里的包，但 go mod graph 看不到变动”这类困惑。
多模块工作区（go.work）适用于同时开发 app 和它依赖的 lib：
go work init go work use ./app ./lib
此时 app 中 import "github.com/you/lib"，会自动链接到本地 ./lib，无需 replace，且 go build 和 go test 都生效。但注意：go.work 文件不能提交到 CI，它只是开发者本地协作机制。
真正容易被忽略的是
MyLib），而文件系统是 macOS/Linux（大小写敏感），但仓库名用了 mylib，就会因路径不一致导致 import 失败——Go 的包路径必须全小写，且严格匹配远程仓库命名。
