为何MINGW MSYS2的`ln`命令不创建目录连接点？

核心原因：兼容性与行为一致性优先 #

MSYS2的工具链（包括ln）最核心的目标是在Windows环境下模拟POSIX语义，同时兼顾Windows原生程序和MSYS2自身生态的兼容性，这也是它没默认用你提出的两种目录连接点方案的关键：

1. 目录连接点和POSIX符号链接的语义差异无法抹平 #

虽然你提到的两种方案看起来更贴近POSIX行为，但目录连接点本身的特性会带来不可忽视的差异：

• 目录连接点只能指向本地NTFS卷的绝对路径，不能跨文件系统，也不支持POSIX符号链接那种“基于当前工作目录动态解析相对路径”的特性。如果ln -s自动把相对路径转成绝对路径创建连接点，一旦用户移动链接或目标目录，连接点直接失效，这和POSIX符号链接的逻辑完全相反。
• POSIX符号链接允许指向不存在的目标（也就是“断链”），但目录连接点要求目标必须存在才能创建，这会打破ln -s在POSIX下允许创建断链的特性，导致依赖该特性的脚本直接报错。

2. 避免混淆MSYS2与Windows原生程序的行为 #

MSYS2的ls会把目录连接点显示成符号链接，但这只是MSYS2层的“伪装”，Windows原生程序对连接点的处理和符号链接完全不同：

• 不少Windows程序会直接识别目录连接点为特殊重解析点，不会像MSYS2工具那样透明地跟随它，比如遍历目录、备份文件时可能出现异常；如果ln -s默认创建连接点，用户混用MSYS2工具和Windows原生工具时，会遇到预期外的问题，排查起来很麻烦。
• 普通用户默认没权限创建符号链接，但创建目录连接点不需要特殊权限，这会导致ln -s的行为在不同权限环境下不一致：有权限时创建符号链接，没权限时创建连接点，这种隐性切换会让用户摸不清工具的逻辑。

3. 复制行为是兼容性兜底策略 #

MSYS2默认让ln -s复制文件/目录，本质是一种稳当的兜底方案：在没法创建符合POSIX语义的符号链接时，保证操作能完成，而且所有用户的行为一致，不会因为Windows版本、权限配置不同出现差异。虽然这种行为和POSIX差别大，但胜在稳定、可预测，适合大多数不熟悉Windows权限限制的用户。

关于混淆与API兼容性的疑问 #

如果强制让ln -s采用你说的两种方案，确实会出问题：

• 混淆问题：用户会以为自己创建的是POSIX语义的符号链接，但实际是目录连接点，遇到跨卷移动、相对路径解析失效等场景时，会出现莫名其妙的错误，很难排查。
• API兼容性问题：MSYS2的工具依赖自身的文件系统抽象层（MinGW的路径转换逻辑），如果默认创建目录连接点，部分依赖符号链接语义的MSYS2程序（比如Git本身）可能出现逻辑错误；而Windows原生程序处理连接点时，会触发和符号链接不同的重解析逻辑，导致程序行为异常。

替代方案：手动创建目录连接点 #

如果你需要在MSYS2里用类POSIX的目录链接，可以手动用cmd //c mklink //j <link> <target>创建目录连接点，就像你示例里那样，MSYS2的工具会自动识别并按符号链接的逻辑处理它，这是目前兼顾兼容性和需求的最优方式。

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