根本原因是多租户沙箱未隔离gocache、gomodcache等路径，导致缓存复用、代理失效或模块根识别失败；须为每个租户配置唯一缓存路径、可信goproxy、显式go111module=on，并预载验证过的依赖快照。
为什么 go build 在多租户沙箱里会找不到模块？
根本原因不是 Go 本身不支持多租户，而是 GOROOT 和 GOPATH（或模块缓存路径）被多个租户共享或误复用。沙箱常通过 chroot、user namespace 或容器隔离，但若未显式重置 GOCACHE、GOBIN、GOPROXY，Go 工具链仍会读写宿主机或前一个租户残留的缓存，导致 go: downloading 失败或拉取错误版本。
-
GOCACHE默认指向$HOME/.cache/go-build，多租户下易冲突 —— 必须设为租户唯一路径，如/tmp/go-cache-<uuid></uuid> -
GOPROXY若设为direct，且沙箱无外网访问权限，go mod download直接卡住；应强制设为可信代理或离线file:///path/to/local/mirror - 未禁用
GO111MODULE=auto的隐式行为：当目录含vendor/但go.mod缺失时，可能降级为 GOPATH 模式，触发不可控依赖解析
如何让 go mod vendor 在沙箱里真正可重现？
沙箱中 go mod vendor 失败，通常是因为它依赖本地 go.sum 和模块缓存一致性，而沙箱启动时缓存为空或被清空。不能只靠 go mod vendor，得提前固化依赖快照。
- 构建前在可信环境运行
go mod download+go mod verify，再打包整个$GOMODCACHE目录（默认$HOME/go/pkg/mod）进沙箱镜像 - 沙箱内启动前执行
export GOMODCACHE=/readonly/path/to/pkg/mod，并设chmod -R a-w /readonly/path防止写入污染 - 避免在沙箱内运行
go get或修改go.mod—— 这些操作在只读环境中会报go: cannot find main module或permission denied
go run 启动失败提示 cannot load package 怎么快速定位？
这不是代码问题，而是沙箱中模块根路径缺失或 go.mod 解析错位。Go 要求当前工作目录或其任意父目录存在 go.mod 才能识别为 module 根，否则退化为 GOPATH 模式，而沙箱通常没配 GOPATH。
- 检查
pwd是否在含go.mod的目录内 —— 错误示例：/tmp/build/app/main.go但go.mod在/tmp/build，需cd /tmp/build && go run ./app - 确认
go.mod第一行是module example.com/project，且所有import路径与该 module path 前缀匹配，否则go list会返回空 - 临时加
-x参数看真实命令：go run -x ./main.go，输出里若出现go list -f {{context.Dir}}返回空，说明模块根未识别
租户间模块缓存共用导致构建结果不一致怎么办？
最隐蔽的问题：A 租户构建时下载了 github.com/some/lib v1.2.3，B 租户后续构建用了同一缓存，但该版本已被作者撤回（yanked），go mod download 却不校验 —— 因为缓存中 .zip 和 go.sum 记录不匹配，但 Go 默认跳过 checksum 验证。
- 强制每次验证：沙箱内始终设
GOINSECURE=""（清空）且不设GOSUMDB=off，让go命令联网查 sum.golang.org；若无法联网，必须预载sumdb快照并设GOSUMDB=sum.golang.org+<hash></hash> - 禁止跨租户复用缓存：每个租户启动时生成随机
GOCACHE和GOMODCACHE，并在退出后自动清理（例如用defer os.RemoveAll(cacheDir)或容器tmpfs挂载） - 关键构建步骤后加
go mod verify，失败则立即中止，别等跑到go build才暴露
模块依赖在沙箱里不是“跑起来就行”，而是每一步都要控制路径、缓存、网络策略和校验开关 —— 少一个环境变量，就可能让两个相同代码在不同租户产出不同二进制。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
