为什么macOS动态库有路径格式的id？与Linux动态库机制有何差异？

1. 什么是动态库ID（install name） #

你提到的动态库ID正式名称为install name，本质是动态库内置的「默认加载路径声明」，设计为路径格式是因为macOS的动态链接器dyld本身就是以路径作为动态库的唯一定位标识，这个值会在其他二进制文件链接该动态库时，直接拷贝到二进制的依赖列表中。
你执行otool -L查看动态库时输出的第一条路径就是该库的install name：

$ otool -L /path/to/lib/libgobject-2.0.0.dylib
/path/to/lib:
    @loader_path/libgobject-2.0.0.dylib <--- 该值就是库的install name
    .. other dependencies

2. 设置install name的必要性 #

• 支持灵活的分发场景：配合@executable_path/@loader_path/@rpath三个特殊路径变量，可以实现不依赖全局搜索路径的相对定位，比如App包内的框架都设置为@rpath/xxx.framework/xxx，不管用户把App放到本地哪个目录，dyld都能正常找到依赖，不需要修改系统配置，也不会和系统自带的同名库冲突。
• 避免同名库冲突：不同目录下的同名动态库可以通过install name明确区分，dyld不会误加载其他路径下的同名称库。
• 绑定版本校验规则：install name会和库的兼容版本号、当前版本号绑定，链接时会自动校验版本匹配度，避免加载版本不兼容的动态库导致运行异常。

3. 和Linux动态库机制的差异 #

Linux的动态链接器确实没有install name机制，依赖soname、LD_LIBRARY_PATH环境变量、ld.so.conf全局配置、rpath来定位动态库。苹果没有采用这套逻辑的核心原因是：

• 苹果生态要求应用沙箱化，不允许普通应用修改系统级的动态库搜索配置，install name配合相对路径变量可以完全实现应用内的依赖自包含，不需要依赖全局配置就能正常运行。
• 历史继承：这套机制源于NeXTSTEP系统，苹果后续接管系统迭代后并没有重构底层动态链接逻辑，只是新增了几个特殊路径变量增强install name的灵活性。

补充操作说明 #

你用install_name_tool -id修改动态库的install name后，只会影响后续链接该库的二进制文件，已经完成链接的二进制需要单独执行install_name_tool -change 旧路径 新路径 目标二进制来更新依赖记录。

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