docker 本身不支持 go 程序像 c/c++ 那样通过系统级共享内存或 .so 文件实现运行时共享库；但可通过数据卷容器（data volume container）机制，将编译好的 go 动态链接库（如 cgo 依赖的 .so）集中存储并只读挂载，从而减少镜像体积、降低多容器内存冗余。
docker 本身不支持 go 程序像 c/c++ 那样通过系统级共享内存或 .so 文件实现运行时共享库；但可通过数据卷容器（data volume container）机制，将编译好的 go 动态链接库（如 cgo 依赖的 .so）集中存储并只读挂载，从而减少镜像体积、降低多容器内存冗余。
Go 编译生成的二进制默认是静态链接（CGO_ENABLED=0 时完全无依赖），因此绝大多数纯 Go 应用根本不需要共享库——它们直接打包进单个可执行文件，天然具备“零依赖、易分发、内存隔离”的优势。只有在启用 CGO（CGO_ENABLED=1）并调用 C 代码（如 net, os/user, 数据库驱动等）时，才可能依赖系统级动态库（如 libpthread.so, libc.so, 或自定义 .so）。此时，若多个容器共用同一组 CGO 所需的动态库，确实可优化资源：
✅ 推荐实践：使用只读数据卷容器共享库文件
- 构建一个专用镜像，仅包含所需 .so 文件（例如 /usr/lib/mylib.so），并通过 VOLUME ["/usr/lib/shared"] 声明共享路径；
- 创建该镜像的数据卷容器（不运行进程，仅作存储载体）：
docker create -v /usr/lib/shared --name go-lib-store my-go-libs-image
- 启动各 Go 应用容器时，以只读方式挂载该卷：
docker run --volumes-from=go-lib-store:ro -it my-go-app
⚠️ 关键注意事项：
- Go 二进制不会自动从挂载路径加载 .so —— 必须显式配置 LD_LIBRARY_PATH=/usr/lib/shared，或在构建时通过 -ldflags "-rpath /usr/lib/shared" 写入运行时搜索路径；
- 容器内 /usr/lib/shared 下的库必须与 Go 应用 ABI 兼容（相同 glibc 版本、架构、符号版本）；
- 不建议共享 libc 等核心系统库——不同基础镜像（如 alpine vs debian）ABI 不兼容，极易导致崩溃；
- 更安全的替代方案：统一使用 glibc 兼容的基础镜像（如 debian:slim），并将 .so 预置到镜像层中（利用 Docker 层缓存），而非运行时挂载。
? 总结：Go 容器的“共享库”本质是文件级复用，而非内存级共享（Linux 的 mmap(MAP_SHARED) 对 Go 运行时无意义）。真正的内存节省来自镜像层共享与只读挂载，而非运行时代码段合并。优先保证应用静态编译；若必须使用 CGO 动态库，则通过体积小、职责单一的数据卷容器实现安全、可控的复用。
