这个问题发现于这么一种操作，首先是用Powershell脚本进行快捷方式（SymbolicLink）创建：
New-Item -ItemType SymbolicLink -Path d:\share_folder\ -Name latest -Target d:\share_folder\v1000 -Force
此命令在d:\share_folder文件夹中创建名叫latest的快捷方式，并指向同级文件夹中的v1000目录，然后将share_folder开启网络共享，从另一台机器通过 \\xxx.xxx.xxx.xxx\share_folder方式访问这个快捷方式latest时，发现会提示：“无法遵循符号链接，因为其类型已禁用”的错误信息，百度一下，查到原因，参考：Windows 挂载磁盘错误 ‘无法遵循符号链接，因为其类型已禁用’ 解决方案 https://www.zywvvd.com/notes/system/windows/symlink-disabled/symlink-disabled/
原来Windows默认对符号链接的跟随跳转仅限本地，远程到本地（共享里的快捷方式指的本地路径），远程到远程（共享里的快捷方式指的是另外的共享路径）都是禁止的，于是参考上面的解决方案，fsutil behavior set SymlinkEvaluation R2L:1 打开远程到本地的遵循，结果再次访问时发现提示目标文件夹不存在！
稍微反应了一下，原来Windows不会自动认为共享文件夹里的快捷方式是由共享主机创建应该指向此主机本地文件夹的，而是认为要跳转到本地此盘的这个路径，这样当然就会提示目标文件夹不存在了（当然如果巧了的话，那就…），所以这么看确实是有必要默认关闭两种远程快捷方式的follow操作的。
之前在Linux上通过smb开出来的Windows共享默认就能正确处理这种情况，即在Linux上通过ln创建的符号链接，在通过smb服务由windows访问时，会正确跳转到被共享的目标路径，但是在Windows上看来并不能这样，于是最终采取了曲线救国的方法：
首先，在访问共享的客户机windows上，打开R2R遵循设置（就是上面提到的命令，换下参数就行），然后在共享服务器上创建快捷方式时，目标不要在写本地路径，而是直接写映射后的共享文件夹路径，如：
New-Item -ItemType SymbolicLink -Path d:\share_folder\ -Name latest -Target \\192.168.0.10\share_folder\v1000 -Force
当然，为了防止DHCP类IP改变，可以把IP换成主机名，然后客户机相关发现设置也要设对。这样创建的快捷方式就可以做到在客户机访问时自动跳转了，同时共享服务机上也能正确访问跳转，虽然跟Linux+smb比起来感觉还是有点怪吧，但好歹是实现了目的。
博主友情提示：
如您在评论中需要提及如QQ号、电子邮件地址或其他隐私敏感信息，欢迎使用>>博主专用加密工具v3<<处理后发布，原文只有博主可以看到。
