库当然是能共用是最好，
但对于微信这个特殊应用，有50G数据占用的情况下，多浪费80M的库根本不值一提了
共用库 更重要的是 访问机制要方便合理
失败的机制导致 npm的反复累赘、linux的库版本冲突，不共用反而是小问题了
所以我这样说嘛。包括Nix在内的很多较新的管理工具都采用了类似中央缓存加虚拟环境的策略。虚拟环境中的包链接到缓存中需要的版本。同时计算引用计数，以便手动/自动清理不在所有虚拟环境中使用的依赖。这样既能共享，又可以多版本共存。
微信只是蹭个热点，不重要
共用一般是硬盘，需要的机制是 库文件版本的定位（目录）：应用定位自己需要的库时，除了现有的机制，增加一个 到应用配置文件指定的库目录找库文件 的机制
内存的共用，则是另外的机制：不同的库文件，只要特征（如hash值）相同均视为同一个库
现在的趋势是不再区分它们：
- 通过 sbin unify 合并 bin 和 sbin
- 通过 /usr merge 合并 / 和 /usr
这里说的就是硬盘呀。你是因为我用了“引用计数”这个词所以觉得我说的是内存？除了内存智能指针外，apt这些传统管理工具也会用到引用计数的思路。它们会计算包被依赖的次数。apt autoremove实际上就是清理引用次数为0并且标记为auto的包。
Nix这些简单说就是软件源中每个包不止包含一个版本，引用计数的对象由特定包改为每个包的特定版本。再配合中央缓存和虚拟环境就可以多版本共存了。
省硬盘 的好处，远无法弥补 库版本不对（需要的版本未能先使用）和版本冲突 的麻烦（docker是缓解了一些，但其实是治标不治本）
哦……怎么感觉你又绕回去了。
- 完全包含依赖所需要空间可能远超一般人的想象，一个以往几MB的小工具可能就会占用几百MB的空间，几百MB的软件可能需要几GB；
- 解决依赖冲突的长远方案应该是发展更好的共享策略，而不是完全放弃治疗，所有场景都打包全部依赖；
- 共享库和打包依赖这两个策略并不互斥，一个程序内都可以同时采用两种策略。
极端了。真正这样极端的，只有npm。
真正要防范版本冲突的都是高层的库，它们用到的底层的库，基本都是稳定的。
所以要应用自带的，也就是那几个。只有npm才把所有依赖都带上，好像是唯一的笑话。
我没看懂你说的极端指什么。
把所有层级的库都带上=极端（就像npm）
一般只带第一层的库（它们依赖的库会比较常规，冲突不太多了）
看来你也认可共享库的必要性，所以我们的看法是一样的嘛。我就是想强调共享库的实现方式还需要大力发展。
DOS也是一样，分为内部命令和外部命令。