go mod download报permission denied本质是写入路径错误，非网络问题；根本原因是GOPATH未设或不可写，导致Go退至只读GOROOT/pkg目录，需检查并确保GOROOT、GOPATH、GOCACHE、GOBIN均指向用户可写路径。
go mod download 报 permission denied 是路径写入问题，不是网络失败
看到 permission denied 就去换代理或重试网络，基本走错方向。真正原因往往是 Go 工具链 fallback 到了只读的 GOROOT 下的 pkg 目录（比如 /usr/local/go/pkg 或 /usr/lib/go/pkg），而你没权限往里写解压后的包文件。
这种现象多发生在：GOROOT 设对了但 GOPATH 没设、GOBIN 没设、或者 $HOME/go 目录结构不完整（缺 pkg/ 子目录）时。Go 会退而求其次，尝试把下载解压后的 .a 文件写进 $GOROOT/pkg —— 这里普通用户根本不能写。
- 验证方式：运行
go env GOROOT GOPATH GOBIN，确认GOPATH非空且指向你有写权限的路径（如$HOME/go） - 手动创建缺失目录：
mkdir -p $HOME/go/{src,pkg,bin} - 确保
$HOME/go/pkg可写：touch $HOME/go/pkg/test && rm $HOME/go/pkg/test - PATH 中必须包含
$HOME/go/bin，否则go install生成的工具你也用不上
go mod vendor 失败提示 cannot write to /usr/local/go/pkg
go mod vendor 不只是复制代码，它内部会先调用 go list -mod=readonly 和 go build -toolexec 类似逻辑，过程中仍需解压依赖到本地缓存目录。如果缓存位置（GOCACHE）或模块安装目标（GOPATH/pkg）不可写，就会直接报错写入失败。
注意：GOCACHE 默认是 $HOME/Library/Caches/go-build（macOS）或 $HOME/.cache/go-build（Linux），但某些容器或受限环境可能被挂载为只读，或 $HOME 权限异常。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 显式设置可写缓存路径：
go env -w GOCACHE=$HOME/go/cache - 检查
$HOME/go/cache是否真能写：mkdir -p $HOME/go/cache/test && rmdir $HOME/go/cache/test - 避免在 root 用户下初始化模块后切回普通用户操作——
go.mod里可能残留// indirect引用，触发跨用户路径访问 - 如果用 CI/CD 环境（如 GitHub Actions），确认 runner 的
$HOME挂载点不是 tmpfs 或只读卷
go get github.com/xxx 报 failed to extract module: permission denied
这个错误明确指向“解压”环节失败，和 go mod download 类似，但更常出现在使用 replace 或本地 file:// 路径时。Go 会尝试把替换路径下的源码软链接或硬链接进模块缓存，若目标路径属主不一致、或挂载选项含 noexec/nosuid，就会卡在这步。
典型场景：你在 Docker 容器里挂载了宿主机的 ~/myproject，但该目录属主是 root；或 WSL2 中 Windows 挂载点默认无执行权限。
- 别用
replace github.com/xxx => ./local/path指向挂载点外的路径，尤其不要跨文件系统 - 改用
replace github.com/xxx => ../relative/path并确保相对路径在当前GOPATH内 - Linux 下检查挂载选项：
findmnt -D | grep "noexec\|nosuid"，必要时用bind重新挂载并加exec - Windows + WSL2：在
/etc/wsl.conf加[automount] options = "metadata,uid=1000,gid=1000,umask=022,exec"后重启 WSL
go mod tidy 卡住后报 permission denied，其实是 proxy fallback 导致的静默降级
看起来是权限问题，实则是网络超时后 Go 自动 fallback 到 direct 模式，然后试图从原始仓库（如 GitHub）直连拉 zip 包，再解压——但此时它已放弃用 GOPROXY 缓存的预编译包，转而走最慢最不稳定的路径，且解压目标仍是 GOPATH/pkg。一旦网络抖动或仓库限流，就容易在解压阶段出错。
这不是 bug，是 Go 的容错机制，但对权限受限环境极不友好。
- 强制全程走代理：
go env -w GOPROXY=https://goproxy.cn,direct（注意direct放最后） - 禁用 fallback：
go env -w GOPROXY=https://goproxy.cn（去掉,direct），让失败更早暴露 - 加
-v看真实行为：go mod tidy -v 2>&1 | grep -E "(Fetching|unzip|extract)" - 如果公司用私有 GitLab，务必同时设
go env -w GOPRIVATE=gitlab.example.com，否则它会坚持走代理查不存在的模块路径，最终 timeout 后 fallback 出错
权限限制下的模块管理，核心不是“怎么让它写”，而是“让它知道该往哪写”。GOROOT、GOPATH、GOCACHE、GOBIN 四者指向必须全部落在用户可写路径内，且彼此不交叉覆盖。任何一项漏配，都可能让工具链在某个环节突然转向系统目录——而那个时刻，你看到的永远是 permission denied，而不是配置缺失提示。
