共享库 symlink 纪律

多工程共享框架栈之后，链接（symlink）成为工作区的血管系统。这篇讲共享库 symlink 的纪律——Air 工作区几十个工程与几个共享前缀之间的关系全靠它，管不好会出各种灵异问题。

▍基本形态
工程目录里的引用路径（如构建脚本里的 install 位置）指向共享前缀；上游源码树与框架源码树统一放在集中目录，工程内的旧位置经链接保持原样。原则：链接在原位置保留，构建脚本零改动兼容。

▍为什么禁止删除或修复链接
历史教训：有人看着工程里的链接觉得是冗余，删掉或改成物理复制，结果框架栈升级后该工程还在用旧副本，行为与全组不一致，排查半天发现是副本分叉。所以纪律第一条：链接不动，看着奇怪也要先查它指向哪。

▍链接的检查
三个命令就够：查看指向（readlink 或 ls 的长格式）、验活（指向的目标存在且非死链）、验唯一（物理路径只有一份真身）。工程接手第一件事就是把引用路径逐个验活，死链是构建失败里最便宜也最常见的原因。

▍相对与绝对的选择
链接用绝对路径最省心（脚本怎么引用都对），缺点是整树搬家要批量修；相对链接可搬迁但引用深度敏感。Air 工作区用绝对链接为主，配合一个验活脚本。选哪种不重要，重要的是全工作区统一。

▍与打包的关系
链接只存在于构建期：打包时库物理拷贝进应用包。要警惕的一类坑：打包脚本跟随链接拷贝时把整个前缀都拖进来（链接指向目录而非文件），包体积爆炸。打包侧对库清单要白名单制。

▍常见错误
一，把链接当目录复制：cp 跟随链接拖全家。二，在链接目标里就地改文件：等于改共享栈，全组受影响。三，同一库在不同工程出现两个物理版本：查链接拓扑，收敛回单份。

▍建议
把验活检查做进构建脚本第一步，死链直接报错退出，别让构建带着缺依赖跑。

免费无广告的安装包可以在官网下载体验。