go编译时包查找顺序为：1. 当前目录及向上逐级的vendor/；2. $goroot/src；3. $gopath/src（仅module关闭时）；4. $gopath/pkg/mod缓存。启用module后默认忽略vendor，除非显式指定-mod=vendor。
Go 编译时查找包的顺序是固定的，不是“先找 vendor 再找缓存”，而是严格按路径优先级逐层 fallback —— 错误理解这点会导致 go build 行为不可预测，尤其在混合使用 vendor、replace 和多模块场景下。
go build 时包的实际检索顺序
Go 工具链在解析 import 路径（如 "github.com/gorilla/mux"）时，按以下**硬编码顺序**搜索：
- 当前包所在目录下的
vendor/子目录（即./vendor/github.com/gorilla/mux） - 逐级向上查找，直到遇到
src/目录下的vendor/（例如../vendor/、../../vendor/，但仅限于src/下的 vendor） -
$GOROOT/src（标准库和内置包） -
$GOPATH/src（仅当未启用 module 模式时生效；启用 module 后此路径基本不参与依赖解析） - 模块缓存：
$GOPATH/pkg/mod中已下载的版本（如github.com/gorilla/mux@v1.8.0）—— 这是 mod 模式下的**主依赖来源**
注意：vendor 机制与 module 模式可共存，但一旦项目含 go.mod 文件且未显式启用 -mod=vendor，vendor/ 就**不会被自动读取**；它只在 go build -mod=vendor 时才强制启用。
为什么 vendor 目录有时“不起作用”
常见现象：明明有 vendor/github.com/some/pkg，但 go build 仍报错找不到包，或拉取了线上版本而非 vendor 内容。
- 没加
-mod=vendor参数：默认 mode 是readonly或normal，vendor被忽略 -
go.mod里存在replace指向本地路径（如replace github.com/some/pkg => ./local-pkg），此时即使 vendor 存在，也会优先走 replace 路径 -
vendor/不完整：比如只复制了部分子包，或遗漏了间接依赖（go mod vendor不会自动补全 transitive 依赖，除非先go mod download） - 跨 module 引用：若当前文件属于一个子 module（即该目录下也有
go.mod），则它的 vendor 查找范围仅限于自身目录，不会穿透到父 module 的 vendor
module 模式下真正依赖从哪来
启用 Go Modules 后，绝大多数情况下，go build 不会碰 vendor 或 GOPATH/src，它只依赖两处：
-
$GOPATH/pkg/mod：所有已下载模块的解压快照，路径形如cache/github.com/user/repo@v1.2.3，这是go get、go build、go run默认加载的位置 -
go.sum文件：校验pkg/mod中每个模块内容的哈希值，防止篡改；缺失或不匹配会直接报错checksum mismatch
go list -m all 列出的模块，就是基于 go.mod + pkg/mod 缓存生成的；而 go list ./... 才是实际扫描源码中 import 的包路径 —— 二者可能不一致，尤其当某些包被 _ 导入或条件编译跳过时。
容易被忽略的构建时动态性
同一个 go build 命令，在不同环境或参数下，实际加载的包可能完全不同：
-
GOOS=js go build和GOOS=linux go build可能触发不同条件编译分支，导致.Deps列表差异，甚至某些包根本不会被纳入依赖图 -
go build -tags 'dev'可能激活额外的// +build dev文件，从而引入新 import，改变依赖集合 -
go build -mod=readonly禁止任何自动修改（包括自动下载），此时若pkg/mod缺失某依赖，会直接失败，而不是静默 fallback 到 GOPATH
真正稳定的构建，必须确保 go.mod、go.sum 和 pkg/mod 缓存三者状态一致；靠“本地有 vendor 就万事大吉”的思路，在 CI 或跨团队协作中极易翻车。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
