go modules 不使用硬链接或软链接管理依赖，所有模块均按内容哈希独立存储于 gopath/pkg/mod，各版本目录完全隔离，vendor 也仅复制文件；链接仅在自定义脚本中手动调用 os.link/os.symlink 时出现。
Go Modules 本身不使用硬链接或软链接管理依赖，所有模块下载和缓存都基于内容哈希与目录复制，所谓“链接处理”是开发者误将文件系统操作套用到模块机制上。
go mod download 和 GOPATH/pkg/mod 的存储机制不是链接
Go Modules 下载的依赖默认存放在 GOPATH/pkg/mod（或 $GOMODCACHE），每个模块版本以 module@v1.2.3 形式独立存放。这些目录之间没有硬链接或软链接关系——即使两个模块引用同一 commit hash 的不同 tag，Go 也会分别解压、校验、存储为不同路径。
-
go mod download总是提取 zip 包并完整解压，不复用 inode，也不调用os.Link或os.Symlink - 缓存中相同模块的不同版本（如
github.com/foo/bar@v1.0.0和@v1.0.1）是完全隔离的目录，无共享数据块 - 即使你手动在
pkg/mod下创建软链接指向另一个版本，go build也不会识别或使用它——模块解析由go工具链控制，只认go.mod声明和缓存目录结构
vendor 目录里也不存在自动链接，只有文件复制
执行 go mod vendor 时，Go 将依赖包源码逐文件复制进项目根目录下的 vendor/，不使用任何链接技术：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 复制过程调用的是
io.Copy+os.Create，不是os.Link - vendor 中的文件与缓存中原始模块内容一致，但 inode 不同，修改 vendor 内文件不影响全局缓存
- 若想节省磁盘空间或实现“共享编辑”，需自行用
os.Symlink手动链接——但 Go 工具链不保证兼容性，且go build -mod=vendor仍按普通文件读取，不会特殊处理符号链接
什么时候真会遇到 os.Link / os.Symlink？只在自定义构建脚本里
真正需要考虑硬/软链接的场景，仅限于你写构建辅助工具时对本地文件做快捷访问，比如：
- 把
./bin/mytool软链接到/usr/local/bin/mytool：必须用os.Symlink，且要os.MkdirAll(filepath.Dir(dst), 0755)确保父目录存在 - 在 CI 中为测试构造“同一文件多路径”视图：可用
os.Link，但必须先os.Stat(src).Sys().(*syscall.Stat_t).Dev == os.Stat(dstDir).Sys().(*syscall.Stat_t).Dev校验同设备 - Windows 上
os.Symlink失败不要怀疑路径逻辑——先检查是否启用“开发者模式”或以管理员身份运行
模块依赖路径是纯逻辑映射，跟文件系统链接无关；硬链接和软链接只存在于你主动调用 os.Link 或 os.Symlink 的那一刻——而 Go Modules 从不这么做。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
