Obsidian 图片链接失效怎么排查：附件路径、仓库设置与重建索引

Obsidian 里图片突然变成破损图标，通常不是图片本身损坏，而是笔记内的链接和本地仓库实际文件位置匹配不上。你可以先确认附件是否还保存在当前库中，再检查「文件与链接」分类下的附件保存位置配置，最后再考虑重建元数据缓存，按这个顺序排查就不会把普通路径问题误判成索引故障。

先判断：图片是丢了，还是链接指错了

打开图片显示异常的笔记，先把光标移动到出问题的图片链接附近，再在左侧文件列表顶部搜索原文件名。如果能搜到对应文件，说明源文件大概率没有丢失；如果侧边文件列表和系统自带的文件管理器都找不到这张图，优先检查系统回收站、同步生成的冲突目录，以及你近期做过的批量重命名操作记录。

Obsidian 的 vault 本质上就是你指定的本地文件夹，所有笔记和附件都存放在这个文件夹内。官方的使用说明也提到，你用外部文件管理器修改目录内容之后，Obsidian 会自动刷新库的整体状态，所以排查时不要只盯着编辑器内的预览效果，一定要同步核对本地文件夹里的实际文件情况。

在“文件与链接”里核对附件入口

点击左下角齿轮图标打开设置面板，进入「文件与链接」分类。重点查看附件默认保存位置配置：如果你选择了指定独立文件夹，所有拖入的图片都应该存入这个目录；如果选择的是「当前文件所在文件夹」或者其子文件夹，后续移动笔记位置时，附件对应的相对路径也会同步发生变化。

这部分配置不要着急反复来回切换。先记录下当前的配置值，再随便找一张新截图做小范围测试：把新图拖进笔记，观察它实际被存放到文件列表的哪个目录，再切到笔记的源码编辑模式查看自动生成的相对链接是否正常。确认逻辑完全符合预期之后，再批量修复旧笔记的异常链接，避免新导入的附件继续写入错误目录。

文件名和大小写也会造成“看似存在但打不开”

跨设备同步时，Diagram.png 和 diagram.png 可能被当成不同路径。不要手动只改链接中的一个字母；把文件名统一后，在引用它的笔记中重新插入一次图片，并重新打开笔记确认预览。

路径正确但仍不显示：重建元数据缓存

如果侧边文件列表里可以直接打开图片预览，笔记内的链接也指向了正确的存储路径，但图片预览、全局搜索或者关系图功能仍没有正常更新，问题大概率出在本地存储的元数据缓存上。回到设置面板的「文件与链接」分类，找到重建元数据缓存的对应选项执行操作，等待索引重建完成之后，重新打开之前受影响的笔记查看效果。

重建缓存不能替代文件恢复操作，也不会自动把存放在当前库文件夹之外的图片搬入库内。它只适合处理「源文件确实存在，但Obsidian记录的本地文件状态滞后于实际情况」这类场景。如果重建之后问题仍没有解决，还是要回到本地文件系统检查路径拼写、文件夹权限，以及同步工具生成的冲突文件。

一个不容易走偏的排查顺序

1. 复制失效图片的文件名，在当前库的全局搜索框内检索。
2. 确认图片可以用系统自带的图片查看器正常打开，核对文件扩展名和文件名大小写是否和笔记链接完全匹配。
3. 进入「文件与链接」设置页检查附件保存位置配置，用一张新的图片验证实际写入目录是否符合预期。
4. 重新插入旧图片的链接，确认笔记源码模式下生成的相对路径完全正确。
5. 最后执行重建元数据缓存操作，重启Obsidian复核图片预览和搜索功能是否恢复正常。

常见问题

移动笔记后，图片为什么一起失效？

如果所有附件都采用相对路径规则保存，移动笔记的存储位置之后，解析相对路径的起始位置也会同步改变。把所有附件统一放到固定的公共目录再重新插入链接，远比手动批量修改大量旧笔记的路径要稳妥。

重建缓存会删除图片吗？

不会。重建元数据缓存操作只会修改Obsidian自身存储的本地文件索引记录，不会触发任何文件搬迁或者删除动作；真正需要留意的反而是同步工具自动生成的冲突副本，以及你用外部工具做的批量文件移动操作。

总结

图片链接失效排查时，先确认源文件存在，再核对相对路径和附件配置，最后才尝试重建缓存。按这个递进顺序处理，可以把「文件意外丢失」「链接路径错误」「索引状态滞后」三类问题完全区分开，修复完成后也能很清晰地验证具体是哪一层环节出了问题。