嗨，我来给你拆解这个问题——先呼应下你对C/C++共享库生态的理解，再聚焦到你关心的核心疑问上：

首先你的背景认知完全没问题：

• 类Unix平台的共享库惯例：通常会把.so这类共享库安装到/usr/local/lib这类专门的系统目录，所有依赖它的可执行文件都会从这个固定位置加载库文件。这种方式的好处特别直观，谁都能一眼看出来不同可执行文件之间是如何共享代码的。
• Windows平台的DLL惯例：这边的常规操作确实是把所有传递依赖的.dll都复制到待构建的可执行文件所在目录。这种分散的部署方式把代码共享的链路藏得很深，不仔细排查的话根本没法直观感知到代码的共享逻辑。

接下来是你真正关心的点：我当然知道在Windows上也能配置成让多个可执行文件共享同一个DLL（比如把DLL放到系统目录或者自定义的环境变量路径里），但这种「把DLL随程序复制到可执行目录」的惯例，到底有没有代码共享的实际价值？它能提供的代码共享能力，会不会比静态库更强？

答案是肯定的——哪怕是这种看似“各自为政”的部署方式，依然保留了动态链接的核心优势，比静态库的代码共享能力要实在：

• 同一目录下的多程序共享：如果同一个目录里有多个exe都依赖同一个DLL，你只需要放一份DLL就行。运行时，所有exe都会加载内存中的同一份代码页；而如果用静态库，每个exe都会把库的代码编译进自己的二进制文件，磁盘上会有多份冗余，运行时内存里也会加载多份相同的代码段。
• 跨进程的内存共享潜力：就算你只有一个exe用这个DLL，磁盘上的占用看似和静态库差不多，但运行时如果有其他进程（哪怕不在同一目录，但能找到这个DLL的话）加载它，依然能共享内存中的代码页；静态库的代码会被每个exe单独加载到内存，完全做不到这种跨进程的内存共享。
• 运行时的灵活性：哪怕DLL和exe在同一目录，你依然可以通过LoadLibrary这类API动态加载DLL，甚至在程序运行时替换DLL（只要不违反依赖规则）。这是静态库完全做不到的——静态库的代码是直接编译进exe的，运行时根本没法替换或者动态调整。

当然，Windows的这种默认惯例确实掩盖了代码共享的直观性，但它的核心依然是动态链接——这一点从根本上区别于静态库，代码的内存共享和运行时的灵活性，都是静态库没法提供的。

备注：内容来源于stack exchange，提问作者Nicholas Gulachek