为何部署到曾编译过libcrypto的机器时，Mach-O动态库@rpath被替换为旧编译路径

首先确认两个基础事实：

• 你通过MD5校验判断mylib.dylib二进制本身未被修改，这个结论完全准确
• 你观察到的路径替换不属于dylib内部存储的配置变更，是otool命令的展示层行为，和文件内部的定义无关

具体机制 #

• otool的非原始读取逻辑
  执行otool -L时，工具不会直接原样输出dylib二进制中存储的依赖路径字符串，它会结合当前系统的dyld共享缓存做自动路径解析：当读到依赖条目为@rpath/libcrypto.1.1.dylib时，会遍历系统记录的所有可加载dylib路径，匹配文件名、版本号、二进制哈希完全一致的libcrypto实体，把原始的@rpath条目替换成匹配到的绝对路径做展示。
• 特定机器触发替换的原因
  那台部署用的机器之前编译过libcrypto，编译阶段就把生成的libcrypto.1.1.dylib安装到了/Users/me/Developer/staging/fakeroot/lib/路径下，这个路径下的dylib会被系统dyld共享缓存长期记录。当otool在这台机器上读取你的mylib.dylib时，匹配到了这个和依赖条目完全对得上的本地libcrypto实体，就自动在展示时替换成了缓存记录的绝对路径。
• 环境变量排查无效的原因
  这套路径映射关系存在于系统级的dyld共享缓存文件中，不属于用户态的环境变量配置，常规的环境变量排查自然无法定位到相关条目。

验证方式 #

如果需要查看dylib二进制中真实存储的、未经过otool映射的原始依赖路径，可以执行命令：
otool -l mylib.dylib | grep -A 4 LC_LOAD_DYLIB | grep libcrypto
在任意机器上执行这条命令，得到的结果都是二进制内实打实存储的原始字符串@rpath/libcrypto.1.1.dylib，不会被系统缓存做展示层替换。

说明：这个展示层的替换不会影响dylib的实际运行加载逻辑，dylib查找依赖的实际规则完全以二进制内部存储的@rpath配置为准，otool的自动路径匹配只是辅助查看的优化功能，不会篡改实际加载参数。

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