大多数Go容器根本不需要共享依赖目录，因为默认静态链接（CGO_ENABLED=0）下，net、os/user等走纯Go实现，生成单个零依赖二进制，可直接运行于scratch或alpine镜像；所谓“依赖目录”仅存在于构建阶段，不应进入运行时镜像。
Go 应用在轻量化容器中根本不需要“目录共享依赖”——因为默认就是静态链接、零运行时依赖。只有当你启用 CGO_ENABLED=1 并调用 C 代码时，才可能引入动态库（如 libpthread.so、libc.so 或自定义 .so），此时才需考虑共享方案；但这类场景本身已偏离 Go 轻量化的初衷。
为什么大多数 Go 容器根本不需要共享依赖目录
Go 编译生成的二进制默认是静态链接的：CGO_ENABLED=0（默认值）下，net、os/user 等标准库会走纯 Go 实现，不依赖系统 .so；最终产物是单个可执行文件，直接扔进 scratch 或 alpine 镜像就能跑。你看到的“依赖目录”（比如 /go/pkg/mod）只存在于构建阶段，不会也不该进入运行时镜像。
- 多容器共用同一组
.so的动机通常来自 C/C++ 项目经验，但对 Go 来说这是反模式 - 共享动态库会破坏容器进程隔离性，且无法规避
LD_LIBRARY_PATH冲突、版本错配等运行时风险 -
docker volume或数据卷容器挂载/usr/lib类路径，在多版本服务混部时极易引发Symbol not found或version mismatch
真要共享 .so 文件时，只读挂载是唯一可行方式
若你确实在用 CGO_ENABLED=1（例如驱动 sqlite3、postgresql 或调用硬件 SDK），且多个容器依赖同一组编译好的 .so，那必须确保：这些库是 ABI 兼容的、只读挂载的、路径固定的。
- 构建专用镜像，仅含
.so文件，并在Dockerfile中声明VOLUME ["/usr/lib/shared"] - 启动数据卷容器：
docker create --name libvol -v /usr/lib/shared:/usr/lib/shared:ro alpine true - 业务容器启动时挂载：
docker run --volumes-from libvol -v /usr/lib/shared:/usr/lib/mydeps:ro your-app - 应用内显式设置
LD_LIBRARY_PATH=/usr/lib/mydeps:/usr/lib，否则dlopen找不到
go mod cache 和 vendor 目录不适用于容器间共享
go mod download 下载的模块缓存在 $GOCACHE 和 $GOPATH/pkg/mod，它们是构建期产物，不是运行时依赖。试图在容器间共享这些路径，只会导致：
立即学习“go语言免费学习笔记（深入）”；
-
go build失败：不同 Go 版本生成的 cache 格式不兼容 - 权限错误：多容器写入同一 cache 目录引发
permission denied - 镜像分层污染：把
pkg/mod打进镜像会使镜像体积暴增数倍，且无法复用 layer -
vendor/是为离线构建设计的，不是运行时共享机制；容器内go mod vendor后仍需CGO_ENABLED=0才能避免运行时 .so 依赖
真正需要关注的，是构建阶段是否用了多阶段 Dockerfile 清理掉 /go 目录，以及运行时镜像是否真的做到了无 CGO、无 libc 依赖——而不是在容器间费力共享某个“依赖目录”。
