为何GitHub可识别符号链接的README文件却无法加载其中符号链接资源文件夹内的图片？

这个问题其实是GitHub对符号链接的特殊处理逻辑导致的，我来给你拆解清楚：

为什么README的符号链接能正常工作？ #

GitHub为了方便用户灵活配置仓库展示的README，对指向README类文件的符号链接做了特殊放行——它会直接读取符号链接指向的目标文件内容，然后在仓库主页渲染出来，相当于把符号链接“替换”成了实际文件的内容，所以你能看到正常显示的README。

为什么资源文件夹的符号链接不行？ #

这就涉及到GitHub对符号链接的通用限制了：

• GitHub在渲染Markdown里的图片时，只会从当前文件的逻辑位置（也就是你的符号链接README所在的.github文件夹）去查找相对路径指向的资源。但这个Resources是文件夹符号链接，GitHub不会递归解析它的指向，只会把它当作一个普通的链接，不会当作真实文件夹去读取里面的图片。
• 另外，GitHub网页端对文件夹类的符号链接默认不做解析，你点击它只会跳转到符号链接的文本路径，而不会进入实际的资源文件夹。

给你几个可行的解决方案： #

• 调整图片路径为仓库根目录相对路径：把README里的图片引用改成/你的实际资源目录/图片文件名.png（比如你的Resources实际在仓库根目录的my-folder/Resources，就写/my-folder/Resources/xxx.png），这样GitHub会直接从仓库根目录找真实文件，本地打开的时候只要你的相对逻辑没问题，也能正常加载。
• 把资源和符号链接README放在同一目录：把Resources文件夹（或者里面的图片）移到.github目录下，这样本地和GitHub的相对路径都能匹配，不过会有文件冗余的问题，适合小资源的场景。
• 如果可以接受本地和GitHub路径不一致：可以在README里写两套路径，用条件注释或者直接在GitHub上用原始文件链接，但这个方案可能会让本地打开体验变差，不是最优解。

备注：内容来源于stack exchange，提问作者Rai