在Linux机器上创建另一个符号链接的符号链接是否有任何副作用（特别是在性能方面）？
答案 0 :(得分：22)
一般来说，没有。从技术上讲，间接会有一个非常的轻微性能损失，但是对于你的应用程序来说它不会引人注意。例如，大多数共享库是符号链接的符号链接（例如libQtCore.so - ＆gt; libQtCore.so.4 - ＆gt; libQtCore.so.4.7 - ＆gt; libQtCore.so.4.7.1）。
答案 1 :(得分：9)
这主要是对Daniel Gallagher的论点的评论，但它不适合评论框，因此这将使其更具可读性。来自Wikipedia on symbolic links：
符号链接的早期实现将符号链接信息存储为常规文件中的数据。该文件包含对链接目标的文本引用，以及指示[需要澄清]表示它作为符号链接。
这种方法很慢，并且在小型系统上使用磁盘空间效率低下。称为快速符号链接的改进允许在用于在磁盘（inode）上存储文件信息的数据结构内存储目标路径。此空间通常存储分配给文件的磁盘块地址列表。因此，可以快速访问具有短目标路径的符号链接。如果目标路径超过可用的inode空间，则具有快速符号链接的系统通常会回退到使用原始方法。原始风格被追溯称为慢速符号链接。它还用于与其他或较旧版本的操作系统的磁盘兼容性。
尽管在inode中存储链接值可以保存磁盘块和磁盘读取，但操作系统仍然需要解析链接中的路径名，这总是需要读取其他inode，并且通常需要读取其他的，可能还有很多，目录，处理文件列表和每个文件的inode，直到找到与链接的路径组件匹配。只有当链接指向同一目录中的文件时，“快速符号链接”才能提供比其他符号链接更好的性能。
因此，/usr/lib中使用符号链接到库的符号链接的惩罚不如长路径查找那么严重，甚至可能跨越几个挂载点。
我还没有看到关于这个主题的原始数字，但从个人经验来看，我认为它最多只是轻微的性能打击，在大多数情况下并不明显。结合我所听到的（未见过的）符号链接的性能一直存在（可能很糟糕）实现，其中使用系统分支来查找某个符号链接的目标。
我很乐意看到关于符号链接和性能的“更有趣”的评论，因为这是几个月来我第二次调查而没有得出明确的结论。
答案 2 :(得分：3)
副作用
是。在内核和/或应用程序拒绝跟踪链之前，您只能将如此多的符号链接堆叠在一起。 （因为循环检测在内存方面成本很高，特别是在内核中，没有使用“看到”标志，而是递归深度被限制。）