Go Modules缓存不使用硬链接，而是通过软链接指向只读解压目录实现空间复用；每个版本仅存一份不可变、可校验的解压内容，多项目共享，已默认高效节省磁盘空间。
Go Modules 本身不支持“启用全局硬链接”这种操作，go mod 的本地缓存（$GOPATH/pkg/mod）默认使用的是**软链接 + 只读解压目录**结构，而非硬链接。所谓“节省磁盘空间”的诉求常见于误读文档或混淆了其他语言包管理器（如 Rust 的 cargo 或 Node.js 的 pnp）行为。
为什么 go mod 不用硬链接
Go 模块缓存设计上要求每个模块版本的解压目录是**不可变、可校验、可并行安全**的：
-
go mod download下载的是 zip 包，解压后存为$GOPATH/pkg/mod/cache/download/…/unzip/下的只读目录 - 项目中通过符号链接（symlink）指向该只读目录，多个项目引用同一版本时共用同一份解压内容 —— 这已是空间复用，但不是硬链接
- 硬链接在跨文件系统、不同 UID、或需要写入时会失效；而 Go 构建过程可能临时 patch 或生成文件（如
go:generate输出），硬链接会破坏隔离性
实际生效的空间节省手段
真正能减少重复占用的，是以下三项已默认启用的行为：
- 所有项目共享
$GOPATH/pkg/mod缓存 —— 同一模块同一版本只存一份解压体 - 未使用的模块版本可通过
go mod tidy -v确认后，手动清理：go clean -modcache（慎用，会清空全部缓存） - 用
go mod download -json查看各模块实际存储路径，确认是否已复用（字段Dir值相同即为复用）
容易被当成“硬链接优化”的误操作
有人尝试用 ln -f 手动替换 $GOPATH/pkg/mod/xxx@v1.2.3 为目标目录的硬链接，这会导致：
-
go build失败：报错cannot write to module cache或permission denied -
go.sum校验失败：因为硬链接绕过了 Go 对只读目录的保护逻辑 -
go mod verify报告哈希不匹配 —— 解压内容被意外修改或覆盖
Go Modules 的空间效率已经足够高，强行引入硬链接既无必要，也不被工具链支持。真正该关注的是：是否长期积累大量未 tidied 的间接依赖、是否误用了 replace 导致重复拉取 fork 分支、以及是否启用了国内代理（如 GOPROXY=https://goproxy.cn）避免反复下载失败重试。
