Windows XP 及更高版本支持符号链接。但是，Windows 仍然使用快捷方式文件（本质上将链接文件的位置存储为文本）。为什么？
答案1
我想有很多原因
- 您可以针对同一个 EXE 的几个不同快捷方式存储不同级别的兼容性，因为它们是由 shell 而不是文件系统解释的。
- 某些快捷方式链接实际上并不存在于文件系统中。其中一些只是对 GUID 或 shell 解释的特殊字符串的引用。
- 您不能在符号链接中包含开关。您当然可以指向 EXE，但您不能告诉该 EXE 任何其他参数。
- 您不能为符号链接选择图标。
- 您无法选择符号链接中要工作的目录。
- 快捷方式文件不仅仅必须指向文件，它们可以是超链接或协议链接（对于 .URL 文件来说）。
- LNK 文件可以存在于任何文件系统中。符号链接由文件系统本身处理，在 Windows 中为 NTFS。
- 没有必要更换它们。它们很实用，体积很小，将来如果需要添加比上面列出的更多的功能，它们还可以扩展。
- 创建符号链接需要管理权限（有充分理由 - 否则只需很少的工作就可以将无辜文件重定向到恶意文件）
原因可能还有很多，但我认为这足以让你开始 :) - @grawity 提供了一个链接这里这将提供有关该主题部分内容的进一步阅读。
答案2
符号链接只不过是被极少量文件系统魔法包裹起来的路径。有许多方法可以使其无效（“损坏”），其中大多数涉及重命名一个或多个文件或目录。由于 Windows 是消费软件，因此在“典型”安装中可能会运行大量设计非常糟糕的程序。因此，与服务器上相比，这种损坏更难避免，因为在服务器上（理论上）每个接触磁盘的程序都是已知量。
快捷方式是不受大多数形式的破损影响因为它们可以独立于路径跟踪目标。这使得它们更加用户友好。它们是专门为消费者设计的，采用“只做我的意思，不要打扰我细节”的方法。
现在，你可以使用硬链接来实现这一点（在某种程度上），但是硬链接有许多复杂属性这使得它们不适合消费者使用。特别是，文件很容易获得新的 inode 编号，并且一些备份软件在遇到硬链接时会相当严重地崩溃。前者可以（也许）通过以下方法解决文件系统隧道（这实际上是捷径解决相关问题的方式），但后者是一个更难的问题。
（我可能还应该指出，使用隧道“解决”硬链接问题绝非易事，因为这不仅仅是重新连接“丢失”的元数据的问题。 Inode 与磁盘分配方案绑定在一起，因此您不能事后随意合并或重新分配它们，除非您做了大量工作。 由于快捷方式使用可以轻松通过隧道传输的其他元数据（例如创建时间），因此它们不会出现此问题。）
答案3
我意识到这是一个老问题，但是我们仍然受到 Windows 资源管理器以几乎难以区分和完全误导的方式显示快捷方式和符号链接的困扰。
在显示图标的资源管理器视图中，两者的左下角都有一个框中指向右上方的小箭头，因此在这里它们的表示难以区分。
在资源管理器树视图中，符号链接（用于目录）显示为节点，而快捷方式不显示。
右键单击 > 属性对话框很混乱。对于符号链接，此对话框中没有提及“链接”或“符号链接”，实际上，该对话框显示一个“快捷方式”选项卡，其中包含有关目标类型、目标位置和实际目标路径的信息。有一个起始于字段（灰色，不适用于符号链接）。
同时，对于实际的快捷方式，常规选项卡显示“文件类型”快捷方式 (.lnk)。并且对话框省略了共享选项卡（用于目录）。
因此，如果所有这些让您不确定什么是什么，您必须求助于命令窗口，其中 dir 命令在类型列中用“”清楚地标识符号链接，而快捷方式则显示为普通文件，其文件名用“ .lnk”扩展名拼写出来。
当然，如果快捷方式的扩展名是“链接”的缩写，而它们根本不是链接，那么这已经是一个问题了。
简而言之，Windows 资源管理器可以更好地清楚地识别和区分这两个截然不同的东西，并且它当然应该停止使用具有误导性或完全错误的术语。