Go 编译报错排查：vendor/golang.org/x/crypto/cryptobyte/asn1 no Go source files

看似简单的编译(make)错误，往下查询竟然是 GOROOT 被污染

一、背景与报错信息

在执行 make 构建 Go 项目时，遇到如下报错：

看到这个报错信息（出现vendor）的时候就觉得很奇怪。项目本身是基于 Go Modules 构建的，本地 go 的版本也是1.22.x，并没有使用 vendor 机制，但奇怪的是编译器却去按理来说不应该存在的 vendor/ 目录下寻找依赖

二、问题排查与解决

1. 初步检查，看是否误用了 vendor

检查相关环境变量配置如下：

GO111MODULE=on
GOPROXY=（脱敏处理）
GOPRIVATE=（脱敏处理）
GONOSUMDB=（脱敏处理）
GOSUMDB=off

明确使用了 Go Modules 模式，不应该触发 vendor 机制

2. 执行 go clean -modcache + go mod tidy

尝试清空 mod 缓存并重新整理依赖：

go clean -modcache
go mod tidy

操作后依赖全部重新拉取，但进行 make 时报错依旧

3. 确认是否存在 vendor/ 目录

执行：

rm -rf vendor

删除本地项目可能存在的 vendor 目录，确认无误后再次构建，依然报错，向下查，发现仍然指向 /usr/local/go/src/vendor 路径，这提示问题可能不在项目本身，而在 Go 安装目录（GOROOT）

4. go list 检查依赖路径定位报错的根本原因

执行：

go list -f '{{.ImportPath}} => {{.Dir}}' all | grep cryptobyte

发现输出的目录如下：

vendor/golang.org/x/crypto/cryptobyte => /usr/local/go/src/vendor/golang.org/x/crypto/cryptobyte
vendor/golang.org/x/crypto/cryptobyte/asn1 => /usr/local/go/src/vendor/golang.org/x/crypto/cryptobyte/asn1

进一步查看：

ls -l /usr/local/go/src/vendor

输出结果：

golang.org/
modules.txt

确认是 GOROOT 的 vendor/ 目录 中残留了第三方依赖，导致 go build 时强制走 vendor 模式，无法通过 Go Modules 拉取正确的依赖版本

5.清理并修复 GOROOT

卸载并清空旧的 GOROOT，确保彻底删除所有遗留文件

sudo rm -rf /usr/local/go

重新安装 Go 最新版本，从官网下载并解压最新版 Go（1.24.4），安装到 /usr/local/go

返回项目根目录，重新拉取依赖，执行 make 命令，构建成功，问题解决！

此时已经可以make成功了，但是为了避免再出现这种情况，将该目录删除

sudo rm -rf /usr/local/go/src/vendor

再执行：

go list -f '{{.ImportPath}} => {{.Dir}}' all | grep cryptobyte

三、深入思考

思考一：为什么 GOROOT 会被污染？

在大多数日常开发中，GOROOT 是稳定的、由官方维护的“系统目录”，用户和工具理论上不应该去写入任何文件，但本次问题中 GOROOT 被污染，其实是一个不太常见但非常危险的问题。查询相关信息，发现常见的污染方式包括：

• 错误的构建脚本：某些脚本可能误将 vendor 目录复制到 /usr/local/go/src

• 误操作：开发者或管理员可能将项目文件写入 GOROOT

• 非官方 Go 安装包：如果使用了第三方安装包，可能附带了额外的 vendor 文件

• IDE 或工具误写入：某些插件或构建工具可能意外将缓存写入 GOROOT

由于GOROOT 污染的影响具有 全局性和隐蔽性：一旦污染，即使在项目中使用的是 Go Modules，工具链可能依然优先查找 GOROOT/vendor，导致“脏路径”优先生效，表现为“明明依赖管理没问题，却莫名其妙报错”

思考二：为什么同事的 GOROOT 目录也被污染了，但是 make 却没有报错？

在同事的电脑上调用命令

go list -f '{{.ImportPath}} => {{.Dir}}' all | grep cryptobyte

发现 GOROOT 下也存在这个 vendor 文件，存在被污染的情况，但是它的项目进行 make 的时候，并不会报错，可能原因有：

• 依赖缓存差异 ，同事的模块缓存可能包含正确依赖版本，绕过了污染路径

• Go 的路径优先级策略导致查找分歧，Go 在构建过程中使用一个“层级路径查找”策略，如果路径结构、module 根目录、软链接存在差异，都可能影响依赖查找结果