Go build包路径解析顺序为：先当前模块go.mod声明路径，再vendor/目录，最后GOROOT和GOPATH中已安装包（模块模式下GOPATH/src基本不参与）；实际行为由go.mod的replace/exclude/require控制，而非自定义搜索顺序。
Go build 时包路径解析顺序是怎样的
Go 不会像 Python 那样动态扫描 GOPATH 或 GOROOT 下所有目录来“发现”包；它只认三类明确路径：当前模块的 go.mod 声明路径、vendor/ 目录、以及 GOROOT 和 GOPATH 中已安装的包（仅限 GOPATH 模式）。模块模式下，GOPATH/src 几乎不参与搜索——除非你显式用 replace 指向它。
关键判断：你无法“自定义” Go 编译器的默认搜索顺序，但可以通过 go.mod 的 replace、exclude 和 require 控制**实际使用哪个版本的包**，这才是真正影响行为的地方。
用 replace 覆盖远程包路径到本地目录
这是最常用、也最可靠的“干预”方式。它不是改搜索顺序，而是告诉 go build：“当遇到这个 import path 时，请直接用我指定的本地路径代替。”
-
replace必须写在当前模块的go.mod文件里，且只能作用于该模块及其依赖树中匹配的require条目 - 路径必须是绝对路径或相对于
go.mod的相对路径；推荐用./local/pkg这种相对写法，避免 CI 环境路径不一致 - 如果被 replace 的包本身有子模块（比如
github.com/foo/bar/v2），你需要为每个子模块单独写replace，Go 不会自动递归覆盖 - 执行
go mod tidy后，replace会生效；但go list -m all可以验证是否真的被替换了
replace github.com/example/lib => ./vendor/local-lib
为什么 GOPATH 和 GOROOT 通常不起作用
Go 1.11+ 默认启用模块模式（GO111MODULE=on），此时 go build 完全忽略 $GOPATH/src 下未被 go.mod 显式 require 的代码。哪怕你在 $GOPATH/src/github.com/myorg/util 放了代码，只要没在 go.mod 里 require github.com/myorg/util，就压根不会被看到。
立即学习“go语言免费学习笔记（深入）”；
-
GOROOT下的包（如fmt、net/http）永远优先，不可替换，也不该替换 -
GOPATH只在GO111MODULE=off时才作为 fallback 搜索路径，但这种模式已被弃用，且与模块共存时行为混乱 - 常见错误现象：
import "mylib" not found—— 很可能是因为没加require mylib，而不是路径没配对
vendor 目录不是“搜索路径”，而是“快照副本”
go mod vendor 把当前模块依赖的所有包拷贝到 vendor/ 目录，之后 go build -mod=vendor 会强制只从这里读包。但它不是添加一个新搜索层级，而是切换整个依赖解析上下文。
- 启用 vendor 后，
replace依然有效，但只作用于 vendor 内已存在的包路径；如果 replace 指向一个 vendor 里没有的路径，会报错 -
vendor/里的包仍然要遵守 import path 规则：比如vendor/github.com/some/pkg对应 import"github.com/some/pkg"，不能改成"some/pkg" - CI 构建建议统一用
go build -mod=vendor，避免网络波动导致依赖拉取失败，但本地开发一般不需要开它
真正的复杂点在于嵌套 replace 和多级 module 的组合：比如 A 依赖 B，B 用 replace 指向本地 X，而 A 又想用另一个本地 Y 替换 B —— 这时 A 的 replace 会覆盖 B 的，但 B 的 replace 不再生效。这种叠加关系容易被忽略，调试时得用 go list -m -f '{{.Replace}}' <module> 逐层确认。
