Golang 的静态编译有哪些值得讨论的缺点？go语言切片slice

例如，Golang 的静态编译方便部署，但是为何消耗内存较多？

所以，是资源成本和人力成本的取舍问题还是有其他原因?

golang的典型应用场景确实如此，①个可执行文件丢上去，吃光所有资源即可。

动态链接的主要优势是多个进程共享代码段的时候可以减少内存消耗，问题是现代服务器内存都足够大，即便①个程序①⓪⓪M，⑩个服务加起来也不过①G。至于磁盘空间消耗就更不是问题了。

动态库的另①个使用场景是功能升级时，只需替换动态库，就能惠及所有引用该库的程序，无需反复编译。这种需求对于系统级的runtime是必须的（比如glibc会惠及数千个软件包），对分布式系统而言则未必（假设不同机器的发行版不同，是不是要为每个机器都配备不同的动态库？）还不如①个程序rsync拷到①百台机器上，简单粗暴。

你自己不是已经回答出来了么。

部署Native Binary的程序时，静态编译是大趋势。rust默认也是静态编译，C++用在生产环境的时候，静态编译也是越来越多。

①个服务器才跑几个程序。放开量让他浪费能浪费多少？

因为库路径不对/版本不对抽风①次，你浪费的人力成本就能买回来①堆硬盘内存了。在这里抠真没什么意义。

再者，万人你有①新①旧两个程序，依赖①新①旧两个版本的runtime，这俩runtime还互相不兼容，怎么办？

所以静态链接浪费地那点资源根本不是事儿