咱直接把你的两个问题拆开来，结合实际场景给你讲明白：

一、替换导出全部原符号且可能新增符号的DLL，程序能正常运行吗？ #

答案是不一定，核心看ABI（应用二进制接口）兼容性，而不只是符号名称一致：

• 要是新DLL完全保留了原DLL的ABI：比如所有原导出函数的参数类型/数量、返回值都没变，结构体/类的内存布局（大小、成员顺序、对齐方式）完全一致，那大概率能正常跑——新增的符号因为程序根本没调用，不会造成任何影响。
• 但要是新DLL只是符号名相同，实际ABI或者隐性逻辑变了：比如某个函数的参数虽然类型没变，但内部依赖的全局变量初始值改了，或者函数返回值的语义变了（原返回0表示成功，新返回1才是成功），甚至结构体偷偷加了成员导致内存布局变了，那程序轻则功能异常，重则直接崩溃。
• 举个真实例子：你要是把系统自带的kernel32.dll换成一个导出所有相同符号但内部逻辑乱改的版本，几乎所有依赖它的程序都会崩，因为很多系统调用的隐性行为被彻底破坏了。

二、静态链接的二进制文件，用导出相同符号的不同DLL可行吗？ #

这里得先澄清一个容易搞混的概念：静态链接和动态链接是完全独立的机制：

• 如果是真正的静态链接：也就是编译时链接的是包含完整代码的静态库（.lib），而非用于动态链接的导入库，那程序编译完成后，静态库的代码已经被直接嵌入到你的二进制文件里了——程序运行时根本不会去加载任何对应的DLL，所以“替换DLL”对它来说完全没意义，换不换都不影响程序运行。
• 如果是通过导入库做的静态链接（本质还是动态链接）：也就是编译时用导入库链接，但程序运行时依然会加载对应的DLL，那这种情况就和第一个问题完全一样了——能不能用不同DLL还是得看ABI是否完全兼容，和普通动态链接程序的规则一致。

内容的提问来源于stack exchange，提问作者user1832484