无服务器环境中go mod易失败，因其默认依赖网络拉取、磁盘写入缓存和go.sum校验，而平台通常禁网络、禁写磁盘、不保留缓存；解决方式是在CI/CD中执行go mod tidy与go mod vendor，并用go build -mod=vendor实现完全离线构建。
无服务器环境里 go mod 为什么容易失败
因为无服务器平台（如 AWS Lambda、Cloudflare Workers、Vercel Edge Functions）通常限制网络访问、禁止写入磁盘、不保留构建缓存，而 go mod 默认行为依赖这三者：它会尝试从远程拉取模块、写入 $GOPATH/pkg/mod 缓存、生成并校验 go.sum。一旦网络被拦截或 /tmp 不可写，go build 就会在 go mod download 阶段卡住或报错 failed to load cache 或 no such file or directory。
- 平台默认禁用 GOPROXY（尤其私有云或内网环境），导致
go get直连 GitHub/GitLab 超时 -
go.sum校验失败常见于镜像层复用时未同步更新，比如 CI 构建用的是旧go.sum，但 runtime 环境里模块已变更 - 某些平台（如 Cloudflare Workers）根本不允许执行
go mod，要求所有依赖必须提前 vendor 或打包进二进制
如何让 go mod 在无服务器部署中稳定运行
核心思路是「构建阶段完成所有依赖解析，运行时零依赖下载」。不能依赖平台现场 go mod download，必须把依赖固化到构建产物里。
- 始终在 CI/CD 中执行
go mod tidy和go mod vendor，然后将vendor/目录提交或打包进镜像 —— 这样go build -mod=vendor就完全离线 - 设置
GOPROXY=https://goproxy.cn,direct（国内）或https://proxy.golang.org,direct（海外），避免因 DNS 或防火墙导致超时；注意direct是 fallback，不是跳过代理 - 对私有模块，必须提前配置
GOPRIVATE=git.internal.company.com，否则即使设了 GOPROXY，私有域名仍会被代理转发，触发 401 或 404 - 禁用 sumdb 校验：设
GOSUMDB=off（仅限可信构建环境），否则go build会尝试连接sum.golang.org，而多数无服务器环境不允许外连
vendor 与 -mod=vendor 的实际效果差异
go mod vendor 只是把依赖复制进 vendor/ 目录，真正起作用的是构建时加 -mod=vendor 参数。没加这个，Go 工具链仍会读 go.mod 并尝试联网解析 —— 这正是无服务器环境下最常踩的坑。
-
go build -mod=vendor：强制只从vendor/读包，忽略go.mod中的require声明，也不检查go.sum -
go build -mod=readonly：允许读go.mod，但禁止修改它 —— 仍可能触发下载，不适合无服务器 - 如果用了
replace指向本地路径（如replace example.com/lib => ./local-lib），-mod=vendor会失效，必须确保replace目标也在vendor/里，或改用replace指向已 vendor 的路径
构建镜像时 go mod 相关环境变量要固化
别依赖平台默认值。不同平台 Go 版本、模块模式开关（GO111MODULE）、代理策略可能不一致，必须显式声明。
立即学习“go语言免费学习笔记（深入）”；
- 始终设
GO111MODULE=on，避免降级到 GOPATH 模式（某些旧 Lambda 运行时默认 off） -
GOPROXY和GOPRIVATE必须在Dockerfile的ENV或构建命令中写死，不要指望 runtime 从宿主机继承 - 推荐在
Dockerfile里分两层：先RUN go mod download（利用 layer 缓存），再COPY . .，最后RUN go build -mod=vendor—— 这样既快又确定
