go mod download卡住时，先执行go env goproxy确认代理是否生效，再curl -i测试代理地址连通性；若返回404或超时，则是代理不通或模块名错误，而非网络或配置问题。
go mod download 卡住时怎么快速定位是网络还是配置问题
先别急着换代理或重装 Go，90% 的卡顿根源就两个：GO_PROXY 没生效，或模块路径本身不可达。执行 go env GO_PROXY 看输出是不是你设的值（比如 https://goproxy.cn,direct）；再手动 curl 一下代理地址：curl -I https://goproxy.cn/github.com/spf13/cobra/@v/v1.8.0.info，如果返回 404 或超时，说明代理不通或模块名拼错。
常见错误现象：
-
go mod download卡在 “Fetching github.com/xxx…” 无响应，几小时不动 -
go list -m all报错no required module provides package，但go.mod里明明写了 require - 同一命令在 CI 上成功，在本地失败，且
go env输出一致
实操建议：
- 用
go mod download -x查看详细请求路径，确认它是否真走的是你设的GO_PROXY，而不是直连proxy.golang.org - 临时禁用代理测试：
GO_PROXY=off go mod download，如果立刻报 403 就证明原代理配置被绕过（常见于 shell 配置未加载或 IDE 启动方式不对） - 非标准开发板上尤其注意：某些嵌入式 Linux 发行版默认没装 CA 证书包，
curl或go会因 SSL 验证失败静默失败，可加export GODEBUG=x509ignore=1临时绕过（仅调试用）
交叉编译环境下 go mod vendor 为什么总漏依赖
因为 go mod vendor 默认只拉取当前构建目标平台能 import 的包，而你在 x86 主机上跑 GOOS=linux GOARCH=arm64 go mod vendor，Go 工具链不会主动下载那些带 // +build linux,arm64 标签、但源码里又没被当前平台 import 的间接依赖——它们只在真正 build 时才触发下载。
使用场景：
- 为 ARM 开发板准备离线 vendor 目录
- 构建镜像前需确保所有依赖已固化，避免构建阶段网络失败
实操建议：
- 先用目标平台参数完整 build 一次：
GOOS=linux GOARCH=arm64 go build -o dummy ./...，让 Go 自动拉全依赖 - 再运行
go mod vendor，此时缓存已齐，vendor 才完整 - 若仍漏包，检查
go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./...输出中是否有未出现在 vendor 中的路径，手动go mod download补全 - 别依赖
go mod vendor -copy——它只复制显式 import 的包，对条件编译块里的依赖无效
私有模块 + go.work 工作区在开发板上无法解析
不是代码问题，是工作区上下文根本没被加载。go.work 文件只在你执行命令的目录及其子目录生效，而开发板上往往直接 cd /app && go build，此时不在工作区根目录，go work 完全被忽略。
关键点：
-
go.work不是全局开关，它不修改任何环境变量，也不影响子模块内部的go.mod - 开发板通常没有 shell 初始化流程，
.zshrc或/etc/profile里的GO_WORK设置无效
实操建议：
- 统一在含
go.work的目录下执行所有命令，例如/workspace/go build -o /app/bin/app ./cmd/app - 删掉所有子模块
go.mod里的replace行——工作区模式下 replace 优先级更高，反而会屏蔽go work use - 验证是否进入工作区：
go work use应列出所有模块路径；go list -m应显示example.com/lib v0.0.0-00010101000000-000000000000 => ./lib这类本地映射 - CI 或开发板部署脚本里避免用
go work init动态生成，直接把预生成的go.work文件随代码一起发布
开发板资源受限时如何最小化模块缓存体积
默认 $GOPATH/pkg/mod 会缓存所有版本的 zip 和 .info 文件，一块 512MB eMMC 的开发板可能刚拉完依赖就爆盘。这不是磁盘空间问题，是 Go 工具链没针对低资源场景做裁剪。
性能影响：
-
go mod download反复解压/校验大量小文件，IO 成瓶颈 -
go list -m all扫描整个pkg/mod目录，耗时从秒级变成分钟级
实操建议：
- 用
go clean -modcache清空后，设置export GOMODCACHE=/tmp/modcache，让缓存落在内存盘（前提是开发板支持 tmpfs） - 禁止保存 .zip 缓存：
export GOPROXY=https://goproxy.cn,direct+export GONOPROXY="*.internal,192.168.1.*"，让私有模块走 direct，避免代理层二次打包 - 定期清理旧版本：
find $GOMODCACHE -name "*.zip" -mtime +7 -delete，保留最近一周的 zip，其余只留 .mod 和 .info - 终极精简：构建完成后执行
go mod download -json | jq -r '.Path' | xargs -I{} rm -rf $GOMODCACHE/{}/，只留当前项目实际用到的模块目录（慎用，调试时需重新下载）
最易被忽略的是：开发板上 shell 启动方式决定环境变量是否生效。systemd service 里直接写 ExecStart=/usr/local/go/bin/go build，根本不会读你的 ~/.profile，所有 GO_* 变量都失效。要么在 service 文件里显式 Environment=GO_PROXY=...，要么改用 wrapper 脚本加载环境后再调 go。
