go build模块路径查找顺序为：先查vendor（需go111module=on且vendor由go mod vendor生成），再查main module，接着是replace，然后是module cache，最后fallback到gopath/src。
go build 时模块路径查找顺序到底怎么走
Go 不会“猜”你想要哪个版本的包，它有一套严格、可预测的查找链。关键不是“能不能找到”，而是“在哪一步停住”。路径优先级直接决定你用的是本地修改版、vendor缓存版，还是远程下载版。
当执行 go build 或 go run 时，Go 工具链按以下顺序查找导入路径（如 "github.com/sirupsen/logrus"）：
- 如果项目根目录存在
vendor目录，且GO111MODULE=auto或on，**先查./vendor/github.com/sirupsen/logrus** —— 找到即用，不往下走 - 否则，检查
go.mod是否存在且GO111MODULE=on：是 → 跳过 GOPATH，只从$GOPROXY下载并缓存到$GOPATH/pkg/mod，再从中加载 - 若
GO111MODULE=off，则完全忽略go.mod和 vendor，只在$GOROOT/src和$GOPATH/src中按路径逐个匹配
注意：GO111MODULE=auto 是默认值，但它只在当前目录或上级有 go.mod 时才自动启用模块模式；否则退化为 GOPATH 模式 —— 这是很多“本地能跑、CI 报错”的根源。
GO111MODULE=auto 为什么总让你掉坑里
GO111MODULE=auto 看似智能，实则依赖文件系统状态，极易被误判。它不是看环境变量，而是看“有没有 go.mod”，而且是从当前工作目录一路向上找，直到根目录。
常见翻车场景：
- 你在项目子目录（如
cmd/myapp/）下执行go run main.go，但go.mod在父目录 —— Go 找不到，降级为 GOPATH 模式，报cannot find package - 你 clone 了一个新 repo，忘记
go mod init，go get会静默失败或写入 GOPATH，后续go build用的却是旧 GOPATH 版本 -
export GO111MODULE=auto写进 shell 配置，但某些 CI 环境未 source，导致行为不一致
最稳做法：明确设为 GO111MODULE=on（Go 1.16+ 默认开启，但显式声明无害），并确保 go.mod 存在于项目根目录 —— 别让它“猜”。
vendor 目录真的会被优先使用吗
会，但有两个硬性前提：项目必须处于模块模式（GO111MODULE=on 或 auto 且能找到 go.mod），且 vendor 目录由 go mod vendor 生成（不是手动复制或 godep save 的旧 vendor）。
如果你用的是老工具（如 godep）生成的 vendor，Go 1.14+ 默认会忽略它，除非额外加 -mod=vendor 参数：
go build -mod=vendor
而现代推荐方式是：
- 运行
go mod vendor（它读取go.mod和go.sum，生成标准 vendor 结构） - 提交
vendor/和go.mod、go.sum - 构建时无需额外参数 —— Go 自动识别并优先使用
漏掉 go.sum 或用错 vendor 生成方式，会导致校验失败或路径错乱。
replace 和 require 共存时谁说了算
replace 永远赢，但只赢在“解析阶段”。它不改变 require 的声明，只重定向实际拉取路径。
例如：
require github.com/sirupsen/logrus v1.9.0<br>replace github.com/sirupsen/logrus => ./local-logrus
效果是：
-
go build仍认为你依赖的是v1.9.0（go list -m all显示该版本） - 但实际编译时，所有对
github.com/sirupsen/logrus的 import 都指向本地./local-logrus目录 -
replace目标目录必须含有效go.mod（哪怕只是module local-logrus），否则报no go.mod file
容易被忽略的一点：replace 对 indirect 依赖无效 —— 它只作用于 require 显式声明的模块。如果某个间接依赖需要 patch，得先用 go get 拉下来，再 replace 它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
