这确实是个挺让人头疼的问题——那些常规的获取可执行文件路径的手段（比如Windows下的GetModuleFileName、Linux下的readlink("/proc/self/exe", ...)），本质上都是读取程序加载时系统记录的路径。一旦你在程序运行期间移动了可执行文件，系统并不会自动更新这个旧路径记录，所以这些方法自然只会返回原来的位置。

下面分平台给你说说可行的解决方案：

Linux/Unix 类系统 #

Linux允许你移动正在运行的可执行文件，但这里要分两种情况：

1. 同文件系统内移动 #

这种情况下，可执行文件的inode（文件系统内的唯一标识符）没有变化，只是路径变了。你可以通过以下步骤找到它的新路径：

• 先获取自身进程可执行文件的inode和设备号：通过stat("/proc/self/exe", &stat_buf)拿到st_ino（inode号）和st_dev（设备号）。
• 遍历整个文件系统（通常从根目录/开始），对每个文件执行stat，对比其st_ino和st_dev是否和你拿到的一致。匹配到的文件路径就是当前实际路径。

这里有个小技巧：可以优先遍历常见的目录（比如/usr/bin、~/bin等），加快查找速度。

2. 跨文件系统移动 #

当你把可执行文件移动到不同分区时，原文件实际上会被标记为"已删除"（但因为进程还在运行，所以磁盘空间不会被释放），而新位置的文件是一个全新的副本（inode不同）。这种情况下，你没法直接关联原进程和新文件，除非你在程序启动时记录了文件的唯一标识（比如SHA256哈希），然后遍历磁盘查找和该哈希匹配的文件。

Windows 系统 #

Windows默认情况下不允许移动正在运行的可执行文件（会提示"文件正在使用中"），除非你用特殊工具绕过了这个限制。如果真的发生了这种情况：

• 进程加载的其实是原文件的内存镜像，原路径的文件可能已经被删除。要找到新位置的文件，同样需要依赖程序启动时记录的唯一标识（比如文件版本号、数字签名、哈希值），然后遍历磁盘查找匹配的文件。

通用建议 #

这种场景本身就属于非常规操作，所以没有完美的跨平台解决方案。如果你的业务场景需要处理这种情况，最好提前做预案：

• 在程序启动时，计算可执行文件的哈希值（比如MD5、SHA256）并保存到内存或配置文件中。
• 当需要获取当前实际路径时，遍历磁盘（或指定目录）查找哈希值匹配的文件。
• 可以给可执行文件添加自定义的资源标记（比如Windows的资源段、Linux的ELF注释），作为更高效的唯一标识，避免计算大文件哈希的性能开销。

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