主要是历史原因吗？是不是还有其他的理由？

足够不代表可以随意浪费，当节约的成本几乎为 0 的时候为什么还要浪费？

版本管理等，编译时间等？ golang 不就是全静态编译链接了吗

想起了被 node_modules 支配的恐惧,,,

为什么不用 shared lib，反而要采用浪费内存和磁盘的方法？

底层库的 hotfix/upgrade 不会牵一发而动全身
Windows hook
LGPL
obj/linker 的兼容性
等等

哦 我是觉得相对它的收益 成本有点高。作为库的使用者，得保证开发和生产环境的这些依赖版本都一致。还是很痛苦的。

改一个库的功能，把库替换了就好了，就不用把使用这个库的程序再重新编译一次

https://docs.microsoft.com/en-us/windows/desktop/dlls/advantages-of-dynamic-linking

我很喜欢 go 呀 但是有很多有现有 c 库的情况就很尴尬。没太试过用 go 调用 c 不知道好不好

想起了被 node_modules 支配的恐惧
::doge::

如果编译成 static library 的话也是不用重新编译的 只是打包一下

哈哈 package-lock.json

如果操作系统的 runtime 打个补丁，需要重新安装所有的程序。还是说每个程序都静态链接一份操作系统？

库克：mmp。
安卓：内存可能只够开个 QQ。

并不够，比如 office 软件要都搞成静态链接，开了这个你就不用干别的了

别开玩笑，你想折腾死那些官方源和镜像源吗（笑哭）

有道理

我二了

我觉得对于客户端程序动态链接是有必要的，而对于服务端的程序则比较适合使用静态链接的程序

开玩笑吧。比如 windows 操作系统，你看有多少 dll 文件，你要静态链接了，编译一次得多久，而且你的内存能放得下不

很多是为了热更的

作为用户还是喜欢普通应用层软件静态链接，下一个可执行文件到处都能跑。

1. 并不够
2. 修改维护

glibc：我现在要修一个 BUG，请问你准备更新几个软件呢

仔细想了下。像底层库更新这种情况的话，用动态库确实可以不用让依赖它的库重新打包。如果接口和行为没有改变的话是很不错的，但是也是可能带来兼容性问题。比如，底层库做了个 breaking change，那后续的库如果不改动的话也不能跑了。目前这种情况主要是包管理器来做依赖检查，然后决定你不是能更新某个底层库的。所以我觉得各有利弊吧。

不说磁盘，内存这玩意不管多大都是稀缺资源