Ruby 2.2.5以上Windows环境下FFI gem无法从PATH加载动态库问题

本质是Ruby 2.3版本针对Windows平台的原生DLL加载逻辑做了安全加固，完全推翻了2.2及更早版本里“运行时修改PATH可直接生效”的行为，具体可以拆解为几点：

• 从Ruby 2.3开始，Windows版Ruby进程会在启动初始化完成的瞬间，对当前环境的PATH变量做全量快照，将这个快照值作为后续所有原生DLL加载操作的固定搜索路径依据。你后续在Ruby代码里通过ENV['PATH'] = ...做的动态修改，只会更新进程内存里的环境块内容——这也是你在C扩展里用getenv能打印出修改后PATH值的原因，但这个修改后的值完全不会同步到Ruby内部的DLL搜索路径缓存里，自然没法被加载逻辑读取。
• 这套逻辑和Windows系统本身的安全策略是对齐的。从Windows Vista开始，系统为了防范DLL劫持攻击，对LoadLibrary/LoadLibraryEx类的系统API做了调整：当以默认标志加载无完整路径的DLL时，只有进程初始化阶段的加载调用会实时读取环境块里的PATH值；一旦进程完成完全初始化，就算运行时修改了环境块里的PATH，系统API也会直接使用进程启动时缓存的路径列表做搜索，不会扫描修改后的PATH路径。2.2.5及更早的Ruby版本没有适配这套安全策略，加载时会实时读取当时的PATH值，因此动态修改的逻辑可以正常跑通。
• 你遇到的“绝对路径能加载目标库，但连带依赖加载失败”的现象，本质是因为：指定绝对路径加载主DLL时，确实绕过了PATH搜索逻辑可以定位到主库文件，但主库自身的依赖DLL加载，依然会走固化的搜索路径列表，就算你把依赖目录加入了运行时修改的PATH，因为路径缓存没有更新，系统也找不到对应的依赖文件。
• 配套的FFI库在适配Ruby 2.3时，也同步取消了运行时实时读取ENV['PATH']的逻辑，完全对齐Ruby核心的DLL搜索行为，因此老版本里“在调用ffi_lib之前动态拼接PATH”的写法会直接失效。

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