1. 问题背后的真相为什么 Obsidian 和 Typora 图片总是“打架”用 Markdown 写笔记的人基本都绕不开 Obsidian 和 Typora 这两款工具。一个主打双链和知识库管理一个专注极简编辑体验很多人是两者混着用——白天在 Typora 里速记灵感晚上回 Obsidian 里整理归档。这个工作流本身没问题但图片路径这件事几乎成了所有人的噩梦。我在 Obsidian 和 Typora 之间切换了三年踩过无数坑。最典型的一个场景在 Typora 里写了一篇带截图的笔记图片自动存到assets文件夹当时显示正常切到 Obsidian 一看图片裂了。反过来也一样在 Obsidian 里贴的图用 Typora 打开时路径全部失效。为什么会这样说白了两个工具对“图片路径”的解释逻辑完全不同。Typora 默认情况下插入图片时写入的是绝对路径也就是从盘符开始的完整路径比如D:\我的笔记\assets\图片1.png。这台电脑上没问题但换一台电脑、改一次文件夹位置这个路径就断了。Obsidian 则更聪明一些它默认使用相对路径也就是相对当前笔记文件所在位置的路径比如assets/图片1.png。这个设计的好处是只要整个仓库文件夹一起移动图片和笔记的相对关系不变就不会失效。但问题在于当你用 Typora 编辑 Obsidian 仓库里的笔记时Typora 会在粘贴图片时直接写死绝对路径。一旦切回 Obsidian它当然找不到那个“只有 Typora 自己认得的”路径。这就是两个工具“打架”的根本原因。还有一个更隐蔽的坑Obsidian 里如果开启了“新链接格式”为基于仓库根目录的绝对路径就是/assets/图片1.png这种以斜杠开头的写法在 Typora 里打开时Typora 会把这个路径理解成当前磁盘根目录下的assets文件夹而不是仓库内的assets文件夹结果还是找不到图。所以要实现两个工具之间无缝切换、图片永远不裂核心就一句话统一路径规则让两个工具都使用“相对路径”并把图片集中存放。1.1 两个工具各自对图片路径的处理规则我不是爱翻官方文档的人但为了搞清这两个工具的图片机制我确实是翻了。简单说一下它们各自的存储逻辑理解了这个后面配置起来才不会有“怎么我按你说的设置了还是不行”的困惑。Obsidian 的图片路径处理机制Obsidian 在仓库Vault内部图片路径有三种模式可以选设置项实际含义链接样式最短路径只显示文件名比如![[图片1.png]]适合单仓库但同名图片会冲突相对路径相对当前笔记的路径比如适合双工具混用基于仓库根目录的绝对路径从仓库根目录写起比如仓库内部稳定但 Typora 会误解如果你在 Obsidian 的设置 → 文件与链接 → “新链接格式”中选了“基于仓库根目录的绝对路径”这其实是 Obsidian 的默认推荐选项因为它能让同一张图片在任何笔记里都能用同一个链接访问不必关心当前笔记在哪个子文件夹。但问题是这个格式恰恰是 Typora 的“天敌”。Typora 对以/开头的路径会当成当前磁盘分区的根目录而不是 Obsidian 仓库的根目录。比如笔记在D:\知识库\读书笔记\里Typora 会把/assets/图.png解析为D:\assets\图.png结果当然是找不到。Typora 的图片路径处理机制Typora 在偏好设置 → 图像中提供了好几个选项设置项实际含义复制图片到自定义文件夹粘贴图片时自动复制到你指定的文件夹并把链接改成相对路径上传图片配合 PicGo 等图床工具上传到云端应用上述规则到本地图片对已有的本地图片也统一处理关键就是第一项。你可以在 Typora 里设定“复制图片到 ./assets 文件夹”同时勾选“优先使用相对路径”。这样Typora 在粘贴图片时会把图片文件复制到当前笔记所在的assets子文件夹里然后在 Markdown 中写入相对路径assets/图片.png。这个路径规则和 Obsidian 的“相对路径”完全一致两个工具就都能正确显示了。1.2 问题的症结路径基准不一致把上面两个机制放在一起看问题的本质就清楚了Obsidian 默认的链接格式是“仓库根目录绝对路径”Typora 默认的是“系统绝对路径”这两种路径在对方工具里都不通用只有“相对笔记文件的相对路径”是两边都认的。所以所谓“终极指南”核心方案就是三个字改设置。把 Obsidian 的新链接格式改成“相对路径”把 Typora 的图片插入规则设置成“复制到 ./assets 文件夹 使用相对路径”。两边统一世界就安静了。2. 终极双工具方案从零配置你的图片路径同步下面我按顺序给出完整的配置步骤。这套方案我已经用了大半年在 macOS 和 Windows 双系统之间切换在 Obsidian 和 Typora 之间来回打开再也没有出现过一张裂图。2.1 先改造 Typora让它写入相对路径Typora 的配置非常关键因为它是“主动写入图片路径”的那一方。打开 Typora → 文件 → 偏好设置 → 图像你会看到几个核心配置项插入图片时选择“复制图片到自定义文件夹”。自定义文件夹填写assets。注意这里的assets不带./前缀Typora 默认会把它解释为“当前笔记所在目录下的 assets 文件夹”。如果你有多个子目录想在每个子目录下各放一个 assets 文件夹就填assets如果你想让所有笔记共用仓库根目录下的一个 assets 文件夹可以填../../assets这个相对路径的计算有点绕后面我会详细说。对本地位置的图片应用上述规则建议勾选。这样你拖入一张已经存在本地的图片时Typora 也会自动把它复制到 assets 文件夹。优先使用相对路径这个必须勾选。这是让 Typora 放弃系统绝对路径的关键。配置完成后建议重启一下 Typora。这时你在 Typora 里新建一篇笔记比如建在知识库/项目A/需求文档.md然后粘贴一张截图。Typora 会做什么自动创建知识库/项目A/assets/文件夹如果不存在把粘贴的图片文件复制进去并可能自动重命名在 Markdown 中写入这样的相对路径链接。把这个文件用 Obsidian 打开因为 Obsidian 能找到同一目录下的assets文件夹图片自然就显示了。这是最标准的“笔记所在目录下的 assets 子文件夹”模式。2.2 再调整 Obsidian让它的链接格式兼容 TyporaObsidian 这边打开设置 → 文件与链接做两处关键调整新链接格式选择“基于仓库根目录的相对路径”部分版本叫“相对路径”。这一步是为了让 Obsidian 新建的链接也使用相对路径和 Typora 保持一致。注意如果你选择的是“最短路径”那么 Obsidian 的链接会显示成![[图片.png]]这种双向链接格式 Typora 是识别不了的——Typora 只认 Markdown 标准语法。所以这里一定要选带路径的相对格式。附件默认存放路径建议设置为“仓库根目录下的 assets 文件夹”或“当前文件所在文件夹下的 assets 文件夹”。两种都可以取决于你想要的目录结构。这里我先说明区别选当前文件所在文件夹下的指定附件文件夹每个子目录各自有一个 assets优点是模块化程度高迁移单独某个子目录时图片跟着走缺点是如果你有一百个子目录就会有一百个 assets 文件夹。选仓库根目录下的指定附件文件夹全仓库只有一个知识库/assets图片高度集中备份方便配合 Git 管理也比较清爽但所有笔记都引用同一个 assets 路径多级子目录下的笔记写相对路径时../会比较多视觉上略乱。我个人推荐后者也就是全仓库一个 assets 文件夹。原因很简单集中意味着可控而且后面配合 Git 跟踪附件变更时特别好用。我自己的库就是我的知识库/assets/里面目前有两千多张图片全部集中在同一个目录下。内部链接类型如果版本中提供这个选项选择“Markdown 格式”而不是“Wikilink 格式”。这样 Obsidian 生成的是标准 Markdown 图片语法和 Typora 完全互通。配置完成后在 Obsidian 里粘贴一张图片Obsidian 会把图片保存到指定的 assets 文件夹并在当前笔记中插入相对路径链接。2.3 为什么一定是 assets 文件夹很多人在笔记文件夹里直接粘贴图片图片文件就和 .md 文件堆在一起。短时间看没问题时间一长一个目录里既有笔记又有几百张截图找文件全靠翻而且同步工具比如 OneDrive、Syncthing扫描起来也吃力。单独建一个 assets 文件夹是从 Notion、WordPress 等成熟工具沿用过来的惯例本身不算新鲜。但在 Obsidian 和 Typora 的组合里它更有一个实际操作上的好处两个工具的设置项里都专门为assets这类文件名做了默认支持。Typora 的自定义文件夹填写是所见即所得Obsidian 的附件路径也支持指定文件夹名几乎不需要额外写配置。这算是两个工具难得达成默契的地方。还有一个更实际的原因如果你需要把笔记发布到博客或者其他平台绝大多数静态博客框架Hugo、Hexo、VuePress都约定俗成地使用一个图片资源文件夹直接复制过去改一下前缀就能用不用逐张处理图片路径。2.4 关于相对路径计算的说明我发现很多人在填../../assets这种路径时容易懵这里展开讲一下相对路径的计算方法。相对路径的基准是“当前笔记文件所在的位置”。比如你的笔记在D:\我的知识库\学习笔记\数学\微积分.mdassets 文件夹在D:\我的知识库\assets\那么从“微积分.md”所在目录即D:\我的知识库\学习笔记\数学\出发要到达D:\我的知识库\assets\需要先往上走两级先回到学习笔记再回到我的知识库然后进入assets。所以路径就是../../assets/图片名.png。在 Typora 里如果你想让所有笔记都共用仓库根目录的 assets你需要在自定义文件夹中填写../../../assets吗不一定。Typora 的“复制图片到自定义文件夹”有一个特点它会把路径解释为相对“当前打开的文件所在目录”。所以如果你的笔记分布在多个深度的子目录里用一个固定的相对路径无法适配所有情况。这一点我实测过同一个 Typora 设置在知识库/笔记A.md里工作正常在知识库/子目录/笔记B.md里填../../assets就可能指向错误位置。所以实际操作上我更推荐两条路如果接受“每个子目录一个 assets”Typora 里填assetsObsidian 里把附件路径也设为“当前文件所在文件夹下的指定附件文件夹”名字也叫 assets。这是最省心的方式无论笔记在哪一层图片都在它旁边的 assets 里相对路径永远是assets/xxx.png。如果坚持“全仓库一个 assets”那建议你干脆别用 Typora 的复制到自定义文件夹功能而是手动把图片拖到仓库根目录的 assets 里或者在 Obsidian 里粘贴图片。反正我实测下来纯靠 Typora 自动写../../assets这种路径在多层级目录里很容易出错。3. 实操演示新建笔记到双工具无缝切换光说理论不够我来完整走一遍流程从零建立一篇带图片的笔记分别在两个工具里验证效果。3.1 场景设定假设我已经有一个 Obsidian 仓库路径是D:\我的知识库仓库里有assets文件夹存放全库附件还有若干子目录。现在我要写一篇笔记位置在D:\我的知识库\项目复盘\3月复盘.md。3.2 用 Typora 写入带图笔记打开 Typora打开已有文件项目复盘\3月复盘.md注意不能从外部新建文件再另存一定要在仓库内部创建或打开已有笔记。截图直接在 Typora 里 CtrlV 粘贴。弹出“是否复制图片到自定义文件夹”的提示如果没弹出来检查设置里的“当插入本地图片时立即应用规则”是否勾选。确认后Typora 会自动在项目复盘\目录下创建assets文件夹并生成类似3月复盘/资产/assets/图片1.png你目录里的实际路径。此时松开 Alt查看 Markdown 源码链接是这样的这个路径是相对当前笔记所在目录的所以只要assets文件夹和3月复盘.md在同一层就能正确显示。3.3 用 Obsidian 打开验证直接切换到 Obsidian找到3月复盘.md点开。图片显示正常不需要任何额外操作。到这里你可能会说这不是废话吗图片就在笔记旁边的 assets 里Obsidian 当然找得到。对但这里的重点是如果 Typora 写的是绝对路径D:\我的知识库\项目复盘\assets\图片1.png那 Obsidian 其实也能打开——只要你的知识库不移动。但一旦你把整个知识库拷贝到另一台电脑的E:\新位置\下绝对路径就全断了。而相对路径assets/图片1.png在这种情况下依然有效因为图片和笔记的相对位置没变过。3.4 反向验证从 Obsidian 粘贴图片再说一个日常场景我在 Obsidian 里读文献时随手截图想补充到笔记里。Obsidian 的设置里我把“附件默认存放路径”设置成了“仓库根目录下的 assets 文件夹”。所以粘贴后图片被自动存到D:\我的知识库\assets\Pasted image 20240331.png笔记里写入的链接类似。注意这里有两个问题需要处理空格Obsidian 生成链接时会把空格编码为%20这是标准 Markdown 做法。Typora 能正常识别%20编码的路径实测没问题。路径深度因为统一存在根目录的 assets 里而3月复盘.md在子目录项目复盘下所以相对路径带了../前缀。如果笔记放在了更深层目录../会变成../../。这种情况在 Typora 里也能正常显示因为它支持标准相对路径。我用 Typora 打开3月复盘.md验证图片正常显示。反向验证通过。3.5 已有笔记的批量迁移如果你已经写了很多笔记图片路径已经乱成一锅粥怎么办我提供两种方案方案一用 Obsidian 内置的“修复路径”功能Obsidian 现在的版本里右键点击一张显示不出来的图片会有一个“使用‘修复路径’重新定位”或者类似选项。这个功能是单个修适合零散几张裂图。方案二用 Typora 的“对所有本地图片应用规则”Typora 偏好设置 → 图像 里有一个按钮叫“对已有的本地图片应用上述规则”。你打开一篇旧笔记点击这个按钮Typora 会扫描文档中所有引用本地图片的链接把图片统一复制到 assets 文件夹然后把链接改写为相对路径。这个操作会修改文件建议操作前先备份或者用 Git 管理仓库。我实测过Typora 这个批量处理对“绝对路径的本地图片”有效但对“网络图片”或者“不存在的路径”会跳过整体比较安全。但有一点要注意如果之前 Obsidian 用的是 Wiki 链接格式![[图片.png]]Typora 不认这种格式无法处理。这种情况只能先在 Obsidian 里把链接批量转为 Markdown 格式或者手动改。4. 进阶图片管理还能这样玩图片路径统一之后你其实就拿到了一个非常规整的附件结构。这时候可以玩一些高级操作让知识库的管理效率进一步提升。4.1 用 Git 管理图片变更图片的删除、新增、重命名在知识库的日常维护中非常频繁。如果直接用网盘同步你不知道哪一张图是哪一天加进来的删了也无法恢复。用 Git 之后每次改动的 diff 一目了然。我为知识库建了 Git 仓库提交规则很简单git init git add . git commit -m 初始提交每次写完笔记统一提交一次大概流程git add -A git commit -m 新增3月复盘补充相关截图Git 没法做二进制图片的可视化 diff但能记录文件名变更和增删记录。回滚的时候可以用git checkout -- assets/图片1.png恢复误删的图片。这一点是真的救过我一次有一次我不小心批量删除附件时误删了二十几张截图Git 一条命令全部找回比任何网盘的回收站都好用。配合上一步步安全的仓库结构你就可以放心频繁提交、频繁整理不用怕出错。我把这个流程写成了脚本每次提交时自动生成 commit message 按日期命名。没什么技术含量但非常省事。4.2 云同步时的路径注意点Obsidian 官方同步服务、OneDrive、Syncthing、坚果云这些都是 Obsidian 知识库常用的云同步工具。图片路径本身是相对路径后云同步出现问题的概率会大大降低但还是有几个坑要提前避开不要用 iCloud 直接同步 Obsidian 仓库至少对图片不要在笔记编辑的同时让 iCloud 后台同步。iCloud 的“优化存储空间”功能会自动把本地文件改成占位符你正在编辑的图片容易变成云端副本而无法读取。如果非要用苹果生态可以关掉“优化 Mac 存储空间”或者改用 iCloud 同步整个远端文件夹的方案。OneDrive 的文件按需同步功能同理虽然比 iCloud 稳定一些但如果你在 Typora 里粘贴图片时 OneDrive 正在同步这个文件夹偶尔会出现短暂的“文件被占用”提示。实测下来问题不大但建议在粘贴大图后等一两秒再切换窗口。跨平台Windows ↔ macOS使用相对路径时不需要额外担心分隔符问题因为 Markdown 链接统一使用/两个系统都认。但如果你在 Windows 下用过\分隔符的路径在 macOS 上一定会失效这个无解只能手动改。批量改的脚本我放在后面。4.3 自定义脚本批量修复路径如果你之前写了大量使用绝对路径或\分隔符的笔记可以用 Python 脚本批量替换。这是一个简单的思路不追求通用但有类似情况的人可以直接改改参数用。import os import re # 仓库根目录 VAULT_ROOT rD:\我的知识库 # 旧的图片目录前缀比如 D:\我的知识库\ OLD_PREFIX os.path.join(VAULT_ROOT, ).replace(\\, /) for root, dirs, files in os.walk(VAULT_ROOT): # 跳过 .git 隐藏目录 if .git in root: continue for file in files: if not file.endswith(.md): continue path os.path.join(root, file) with open(path, r, encodingutf-8) as f: content f.read() # 替换反斜杠为斜杠 content content.replace(\\, /) # 替换旧的绝对路径前缀为相对路径相对仓库根目录 if VAULT_ROOT.replace(\\, /) / in content: content content.replace(VAULT_ROOT.replace(\\, /) /, ) with open(path, w, encodingutf-8) as f: f.write(content) print(路径修复完成)运行这个脚本前一定要先备份仓库或者确认在 Git 仓库里可以随时回滚。这个脚本的核心思路是把D:\我的知识库\assets\图.png替换成assets/图.png也就是把绝对路径变成相对仓库根目录的路径。但注意这种替换只适合图片在仓库内、且所有笔记的图片引用都相对于仓库根目录的情况。如果你的笔记分布在子目录里改成assets/图.png后子目录内的笔记可能还需要补../前缀这就是相对路径的坑——它依赖笔记自身的位置。所以我个人更推荐全仓库统一使用根目录下的 assets 文件夹这样脚本处理逻辑最简单。5. 常见问题与排查技巧实录图片问题千奇百怪但追根溯源基本就那几种。我把一年来收集的高频问题整理成一个速查表每条都是踩过坑后总结出来的。问题现象直接原因解决方案Typora 里图片正常Obsidian 里裂图Typora 写入了绝对路径改 Typora 设置为“复制到 ./assets 优先使用相对路径”Obsidian 里图片正常Typora 里裂图Obsidian 使用了“基于仓库根目录的绝对路径”或 Wiki 链接把 Obsidian 新链接格式改为“相对路径”和 Markdown 格式两个工具都正常换一台电脑裂图图片文件没有随笔记一起复制或者路径中带盘符确保 assets 文件夹和笔记一起拷贝用相对路径文件名带空格Typora 显示但 Obsidian 不显示Obsidian 对%20解码有问题少部分旧版本重命名文件名不要带空格或者升级 Obsidian移动笔记文件后图片全部失效相对路径基准变了移动文件时连 assets 子文件夹一起移动或者改用统一根目录 assets文件名带中文在某些编辑器里正常但在服务器上 404GBK/UTF-8 编码不一致保持系统编码 UTF-8文件名尽量避免特殊字符粘贴的图片在 assets 里但 Obsidian 里还是裂Obsidian 的附件设置指向了另一个文件夹检查 Obsidian 设置 → 文件与链接 → 默认附件路径Typora 批量应用规则后部分图片被跳过图片路径本身是网络图片或者 Wiki 链接手动处理或先在 Obsidian 中转换链接格式5.1 图片裂了先判断是哪种裂遇到图片裂图第一步永远是搞清楚是 Markdown 语法写错了还是路径指向的文件不存在。在 Obsidian 里把编辑模式打开看链接的写法在 Typora 里切换到源码模式或直接看图片链接。如果链接长这样那问题就是反斜杠和绝对路径。把这个改成assets/图片1.png如果笔记文件就在仓库根目录下大概率就好了。如果链接长这样而图片的实际位置是D:\我的知识库\项目复盘\assets\Pasted image 20240331.png那问题就是路径层级不对——多往上跳了一级。直接把../去掉就行。翻看十年前的技术博客和论坛里关于“Markdown 图片不显示”的讨论多到数不清但方法至今没变先查链接语法再查文件路径最后查文件名编码。这条排查路线适用性非常广。5.2 文件名中的空格和特殊字符我一直坚持一个建议图片文件名和笔记文件名最好不要带空格不要带括号不要带表情符号。不是不能带是带了之后各个工具表现不一致。Obsidian 在生成内部链接时会把空格自动编码成%20。Markdown 解析器应该都能正确处理%20Typora 实测可以但有些第三方工具、静态博客框架、Git 管理工具对%20的处理并不可靠。中文文件名也同理虽然现代工具基本都支持 UTF-8 中文路径但在旧版本 Typora 和某些 Linux 服务器上中文文件名偶尔会引发编码问题。建议的做法是在 Typora 的图像设置里把“自动重命名图片文件”打开文件名自动带上时间戳并做 URL 编码或者在 Obsidian 的附件设置里开启“自动重命名”。反正最后用 Obsidian 内粘贴的图片会自动加前缀最坏情况也就是文件名长一点。长文件名总比裂图好。5.3 Typora 激活问题的无关提醒在整理这个主题的搜索关键词时我注意到不少人搜“Typora 激活”和“Typora 序列号”。这里多说一句Typora 现在是付费软件官方也提供了免费试用期但版本更新频繁网上流传的“免激活”基本都有安全风险。如果你是重度 Markdown 用户我建议还是支持正版或者直接转向 Obsidian 的编辑器。毕竟 Obsidian 免费且开源配合好用的插件写作体验并不输 Typora。当然这只是个人建议工具选择看个人习惯。这个主题本身就比“怎么激活”更值得关注路径统一了之后你根本不需要在两个工具之间反复折腾也更愿意长期维护自己的知识库。5.4 批量把 Wiki 链接转为 Markdown 链接如果你之前的 Obsidian 仓库大量使用了![[图片.png]]这种 Wiki 链接而现在想在 Typora 里正常显示就需要转换成格式。Obsidian 社区插件有自动转换工具比如“Convert wikilinks to markdown”可以一键把全仓库的内部链接全部转为标准 Markdown 格式。但注意这个转换是不可逆的转换前先备份。我自己其实没做全库转换而是选择了一个折中方案日常大部分时间在 Obsidian 里看笔记只有写作和速记时才打开 Typora。Typora 主要用来“写新笔记”和“编辑个别文件”这时候只要新写的部分保持相对路径就能正常显示。旧笔记保持 Wiki 链接格式在 Obsidian 里完全没问题万一需要导出这些旧笔记到别处再单独跑一次批量转换。这样既兼顾了 Obsidian 原生的双链体验也不耽误 Typora 的写作流。如果你实在需要在 Typora 里看旧笔记还有一个临时方案直接在 Typora 里 CtrlF 搜索
长河君 · 2026/9/16 22:08:10 · 阅读 1.2k Obsidian与Typora无缝切换：图片路径统一终极指南
1. 问题背后的真相为什么 Obsidian 和 Typora 图片总是“打架”用 Markdown 写笔记的人基本都绕不开 Obsidian 和 Typora 这两款工具。一个主打双链和知识库管理一个专注极简编辑体验很多人是两者混着用——白天在 Typora 里速记灵感晚上回 Obsidian 里整理归档。这个工作流本身没问题但图片路径这件事几乎成了所有人的噩梦。我在 Obsidian 和 Typora 之间切换了三年踩过无数坑。最典型的一个场景在 Typora 里写了一篇带截图的笔记图片自动存到assets文件夹当时显示正常切到 Obsidian 一看图片裂了。反过来也一样在 Obsidian 里贴的图用 Typora 打开时路径全部失效。为什么会这样说白了两个工具对“图片路径”的解释逻辑完全不同。Typora 默认情况下插入图片时写入的是绝对路径也就是从盘符开始的完整路径比如D:\我的笔记\assets\图片1.png。这台电脑上没问题但换一台电脑、改一次文件夹位置这个路径就断了。Obsidian 则更聪明一些它默认使用相对路径也就是相对当前笔记文件所在位置的路径比如assets/图片1.png。这个设计的好处是只要整个仓库文件夹一起移动图片和笔记的相对关系不变就不会失效。但问题在于当你用 Typora 编辑 Obsidian 仓库里的笔记时Typora 会在粘贴图片时直接写死绝对路径。一旦切回 Obsidian它当然找不到那个“只有 Typora 自己认得的”路径。这就是两个工具“打架”的根本原因。还有一个更隐蔽的坑Obsidian 里如果开启了“新链接格式”为基于仓库根目录的绝对路径就是/assets/图片1.png这种以斜杠开头的写法在 Typora 里打开时Typora 会把这个路径理解成当前磁盘根目录下的assets文件夹而不是仓库内的assets文件夹结果还是找不到图。所以要实现两个工具之间无缝切换、图片永远不裂核心就一句话统一路径规则让两个工具都使用“相对路径”并把图片集中存放。1.1 两个工具各自对图片路径的处理规则我不是爱翻官方文档的人但为了搞清这两个工具的图片机制我确实是翻了。简单说一下它们各自的存储逻辑理解了这个后面配置起来才不会有“怎么我按你说的设置了还是不行”的困惑。Obsidian 的图片路径处理机制Obsidian 在仓库Vault内部图片路径有三种模式可以选设置项实际含义链接样式最短路径只显示文件名比如![[图片1.png]]适合单仓库但同名图片会冲突相对路径相对当前笔记的路径比如适合双工具混用基于仓库根目录的绝对路径从仓库根目录写起比如仓库内部稳定但 Typora 会误解如果你在 Obsidian 的设置 → 文件与链接 → “新链接格式”中选了“基于仓库根目录的绝对路径”这其实是 Obsidian 的默认推荐选项因为它能让同一张图片在任何笔记里都能用同一个链接访问不必关心当前笔记在哪个子文件夹。但问题是这个格式恰恰是 Typora 的“天敌”。Typora 对以/开头的路径会当成当前磁盘分区的根目录而不是 Obsidian 仓库的根目录。比如笔记在D:\知识库\读书笔记\里Typora 会把/assets/图.png解析为D:\assets\图.png结果当然是找不到。Typora 的图片路径处理机制Typora 在偏好设置 → 图像中提供了好几个选项设置项实际含义复制图片到自定义文件夹粘贴图片时自动复制到你指定的文件夹并把链接改成相对路径上传图片配合 PicGo 等图床工具上传到云端应用上述规则到本地图片对已有的本地图片也统一处理关键就是第一项。你可以在 Typora 里设定“复制图片到 ./assets 文件夹”同时勾选“优先使用相对路径”。这样Typora 在粘贴图片时会把图片文件复制到当前笔记所在的assets子文件夹里然后在 Markdown 中写入相对路径assets/图片.png。这个路径规则和 Obsidian 的“相对路径”完全一致两个工具就都能正确显示了。1.2 问题的症结路径基准不一致把上面两个机制放在一起看问题的本质就清楚了Obsidian 默认的链接格式是“仓库根目录绝对路径”Typora 默认的是“系统绝对路径”这两种路径在对方工具里都不通用只有“相对笔记文件的相对路径”是两边都认的。所以所谓“终极指南”核心方案就是三个字改设置。把 Obsidian 的新链接格式改成“相对路径”把 Typora 的图片插入规则设置成“复制到 ./assets 文件夹 使用相对路径”。两边统一世界就安静了。2. 终极双工具方案从零配置你的图片路径同步下面我按顺序给出完整的配置步骤。这套方案我已经用了大半年在 macOS 和 Windows 双系统之间切换在 Obsidian 和 Typora 之间来回打开再也没有出现过一张裂图。2.1 先改造 Typora让它写入相对路径Typora 的配置非常关键因为它是“主动写入图片路径”的那一方。打开 Typora → 文件 → 偏好设置 → 图像你会看到几个核心配置项插入图片时选择“复制图片到自定义文件夹”。自定义文件夹填写assets。注意这里的assets不带./前缀Typora 默认会把它解释为“当前笔记所在目录下的 assets 文件夹”。如果你有多个子目录想在每个子目录下各放一个 assets 文件夹就填assets如果你想让所有笔记共用仓库根目录下的一个 assets 文件夹可以填../../assets这个相对路径的计算有点绕后面我会详细说。对本地位置的图片应用上述规则建议勾选。这样你拖入一张已经存在本地的图片时Typora 也会自动把它复制到 assets 文件夹。优先使用相对路径这个必须勾选。这是让 Typora 放弃系统绝对路径的关键。配置完成后建议重启一下 Typora。这时你在 Typora 里新建一篇笔记比如建在知识库/项目A/需求文档.md然后粘贴一张截图。Typora 会做什么自动创建知识库/项目A/assets/文件夹如果不存在把粘贴的图片文件复制进去并可能自动重命名在 Markdown 中写入这样的相对路径链接。把这个文件用 Obsidian 打开因为 Obsidian 能找到同一目录下的assets文件夹图片自然就显示了。这是最标准的“笔记所在目录下的 assets 子文件夹”模式。2.2 再调整 Obsidian让它的链接格式兼容 TyporaObsidian 这边打开设置 → 文件与链接做两处关键调整新链接格式选择“基于仓库根目录的相对路径”部分版本叫“相对路径”。这一步是为了让 Obsidian 新建的链接也使用相对路径和 Typora 保持一致。注意如果你选择的是“最短路径”那么 Obsidian 的链接会显示成![[图片.png]]这种双向链接格式 Typora 是识别不了的——Typora 只认 Markdown 标准语法。所以这里一定要选带路径的相对格式。附件默认存放路径建议设置为“仓库根目录下的 assets 文件夹”或“当前文件所在文件夹下的 assets 文件夹”。两种都可以取决于你想要的目录结构。这里我先说明区别选当前文件所在文件夹下的指定附件文件夹每个子目录各自有一个 assets优点是模块化程度高迁移单独某个子目录时图片跟着走缺点是如果你有一百个子目录就会有一百个 assets 文件夹。选仓库根目录下的指定附件文件夹全仓库只有一个知识库/assets图片高度集中备份方便配合 Git 管理也比较清爽但所有笔记都引用同一个 assets 路径多级子目录下的笔记写相对路径时../会比较多视觉上略乱。我个人推荐后者也就是全仓库一个 assets 文件夹。原因很简单集中意味着可控而且后面配合 Git 跟踪附件变更时特别好用。我自己的库就是我的知识库/assets/里面目前有两千多张图片全部集中在同一个目录下。内部链接类型如果版本中提供这个选项选择“Markdown 格式”而不是“Wikilink 格式”。这样 Obsidian 生成的是标准 Markdown 图片语法和 Typora 完全互通。配置完成后在 Obsidian 里粘贴一张图片Obsidian 会把图片保存到指定的 assets 文件夹并在当前笔记中插入相对路径链接。2.3 为什么一定是 assets 文件夹很多人在笔记文件夹里直接粘贴图片图片文件就和 .md 文件堆在一起。短时间看没问题时间一长一个目录里既有笔记又有几百张截图找文件全靠翻而且同步工具比如 OneDrive、Syncthing扫描起来也吃力。单独建一个 assets 文件夹是从 Notion、WordPress 等成熟工具沿用过来的惯例本身不算新鲜。但在 Obsidian 和 Typora 的组合里它更有一个实际操作上的好处两个工具的设置项里都专门为assets这类文件名做了默认支持。Typora 的自定义文件夹填写是所见即所得Obsidian 的附件路径也支持指定文件夹名几乎不需要额外写配置。这算是两个工具难得达成默契的地方。还有一个更实际的原因如果你需要把笔记发布到博客或者其他平台绝大多数静态博客框架Hugo、Hexo、VuePress都约定俗成地使用一个图片资源文件夹直接复制过去改一下前缀就能用不用逐张处理图片路径。2.4 关于相对路径计算的说明我发现很多人在填../../assets这种路径时容易懵这里展开讲一下相对路径的计算方法。相对路径的基准是“当前笔记文件所在的位置”。比如你的笔记在D:\我的知识库\学习笔记\数学\微积分.mdassets 文件夹在D:\我的知识库\assets\那么从“微积分.md”所在目录即D:\我的知识库\学习笔记\数学\出发要到达D:\我的知识库\assets\需要先往上走两级先回到学习笔记再回到我的知识库然后进入assets。所以路径就是../../assets/图片名.png。在 Typora 里如果你想让所有笔记都共用仓库根目录的 assets你需要在自定义文件夹中填写../../../assets吗不一定。Typora 的“复制图片到自定义文件夹”有一个特点它会把路径解释为相对“当前打开的文件所在目录”。所以如果你的笔记分布在多个深度的子目录里用一个固定的相对路径无法适配所有情况。这一点我实测过同一个 Typora 设置在知识库/笔记A.md里工作正常在知识库/子目录/笔记B.md里填../../assets就可能指向错误位置。所以实际操作上我更推荐两条路如果接受“每个子目录一个 assets”Typora 里填assetsObsidian 里把附件路径也设为“当前文件所在文件夹下的指定附件文件夹”名字也叫 assets。这是最省心的方式无论笔记在哪一层图片都在它旁边的 assets 里相对路径永远是assets/xxx.png。如果坚持“全仓库一个 assets”那建议你干脆别用 Typora 的复制到自定义文件夹功能而是手动把图片拖到仓库根目录的 assets 里或者在 Obsidian 里粘贴图片。反正我实测下来纯靠 Typora 自动写../../assets这种路径在多层级目录里很容易出错。3. 实操演示新建笔记到双工具无缝切换光说理论不够我来完整走一遍流程从零建立一篇带图片的笔记分别在两个工具里验证效果。3.1 场景设定假设我已经有一个 Obsidian 仓库路径是D:\我的知识库仓库里有assets文件夹存放全库附件还有若干子目录。现在我要写一篇笔记位置在D:\我的知识库\项目复盘\3月复盘.md。3.2 用 Typora 写入带图笔记打开 Typora打开已有文件项目复盘\3月复盘.md注意不能从外部新建文件再另存一定要在仓库内部创建或打开已有笔记。截图直接在 Typora 里 CtrlV 粘贴。弹出“是否复制图片到自定义文件夹”的提示如果没弹出来检查设置里的“当插入本地图片时立即应用规则”是否勾选。确认后Typora 会自动在项目复盘\目录下创建assets文件夹并生成类似3月复盘/资产/assets/图片1.png你目录里的实际路径。此时松开 Alt查看 Markdown 源码链接是这样的这个路径是相对当前笔记所在目录的所以只要assets文件夹和3月复盘.md在同一层就能正确显示。3.3 用 Obsidian 打开验证直接切换到 Obsidian找到3月复盘.md点开。图片显示正常不需要任何额外操作。到这里你可能会说这不是废话吗图片就在笔记旁边的 assets 里Obsidian 当然找得到。对但这里的重点是如果 Typora 写的是绝对路径D:\我的知识库\项目复盘\assets\图片1.png那 Obsidian 其实也能打开——只要你的知识库不移动。但一旦你把整个知识库拷贝到另一台电脑的E:\新位置\下绝对路径就全断了。而相对路径assets/图片1.png在这种情况下依然有效因为图片和笔记的相对位置没变过。3.4 反向验证从 Obsidian 粘贴图片再说一个日常场景我在 Obsidian 里读文献时随手截图想补充到笔记里。Obsidian 的设置里我把“附件默认存放路径”设置成了“仓库根目录下的 assets 文件夹”。所以粘贴后图片被自动存到D:\我的知识库\assets\Pasted image 20240331.png笔记里写入的链接类似。注意这里有两个问题需要处理空格Obsidian 生成链接时会把空格编码为%20这是标准 Markdown 做法。Typora 能正常识别%20编码的路径实测没问题。路径深度因为统一存在根目录的 assets 里而3月复盘.md在子目录项目复盘下所以相对路径带了../前缀。如果笔记放在了更深层目录../会变成../../。这种情况在 Typora 里也能正常显示因为它支持标准相对路径。我用 Typora 打开3月复盘.md验证图片正常显示。反向验证通过。3.5 已有笔记的批量迁移如果你已经写了很多笔记图片路径已经乱成一锅粥怎么办我提供两种方案方案一用 Obsidian 内置的“修复路径”功能Obsidian 现在的版本里右键点击一张显示不出来的图片会有一个“使用‘修复路径’重新定位”或者类似选项。这个功能是单个修适合零散几张裂图。方案二用 Typora 的“对所有本地图片应用规则”Typora 偏好设置 → 图像 里有一个按钮叫“对已有的本地图片应用上述规则”。你打开一篇旧笔记点击这个按钮Typora 会扫描文档中所有引用本地图片的链接把图片统一复制到 assets 文件夹然后把链接改写为相对路径。这个操作会修改文件建议操作前先备份或者用 Git 管理仓库。我实测过Typora 这个批量处理对“绝对路径的本地图片”有效但对“网络图片”或者“不存在的路径”会跳过整体比较安全。但有一点要注意如果之前 Obsidian 用的是 Wiki 链接格式![[图片.png]]Typora 不认这种格式无法处理。这种情况只能先在 Obsidian 里把链接批量转为 Markdown 格式或者手动改。4. 进阶图片管理还能这样玩图片路径统一之后你其实就拿到了一个非常规整的附件结构。这时候可以玩一些高级操作让知识库的管理效率进一步提升。4.1 用 Git 管理图片变更图片的删除、新增、重命名在知识库的日常维护中非常频繁。如果直接用网盘同步你不知道哪一张图是哪一天加进来的删了也无法恢复。用 Git 之后每次改动的 diff 一目了然。我为知识库建了 Git 仓库提交规则很简单git init git add . git commit -m 初始提交每次写完笔记统一提交一次大概流程git add -A git commit -m 新增3月复盘补充相关截图Git 没法做二进制图片的可视化 diff但能记录文件名变更和增删记录。回滚的时候可以用git checkout -- assets/图片1.png恢复误删的图片。这一点是真的救过我一次有一次我不小心批量删除附件时误删了二十几张截图Git 一条命令全部找回比任何网盘的回收站都好用。配合上一步步安全的仓库结构你就可以放心频繁提交、频繁整理不用怕出错。我把这个流程写成了脚本每次提交时自动生成 commit message 按日期命名。没什么技术含量但非常省事。4.2 云同步时的路径注意点Obsidian 官方同步服务、OneDrive、Syncthing、坚果云这些都是 Obsidian 知识库常用的云同步工具。图片路径本身是相对路径后云同步出现问题的概率会大大降低但还是有几个坑要提前避开不要用 iCloud 直接同步 Obsidian 仓库至少对图片不要在笔记编辑的同时让 iCloud 后台同步。iCloud 的“优化存储空间”功能会自动把本地文件改成占位符你正在编辑的图片容易变成云端副本而无法读取。如果非要用苹果生态可以关掉“优化 Mac 存储空间”或者改用 iCloud 同步整个远端文件夹的方案。OneDrive 的文件按需同步功能同理虽然比 iCloud 稳定一些但如果你在 Typora 里粘贴图片时 OneDrive 正在同步这个文件夹偶尔会出现短暂的“文件被占用”提示。实测下来问题不大但建议在粘贴大图后等一两秒再切换窗口。跨平台Windows ↔ macOS使用相对路径时不需要额外担心分隔符问题因为 Markdown 链接统一使用/两个系统都认。但如果你在 Windows 下用过\分隔符的路径在 macOS 上一定会失效这个无解只能手动改。批量改的脚本我放在后面。4.3 自定义脚本批量修复路径如果你之前写了大量使用绝对路径或\分隔符的笔记可以用 Python 脚本批量替换。这是一个简单的思路不追求通用但有类似情况的人可以直接改改参数用。import os import re # 仓库根目录 VAULT_ROOT rD:\我的知识库 # 旧的图片目录前缀比如 D:\我的知识库\ OLD_PREFIX os.path.join(VAULT_ROOT, ).replace(\\, /) for root, dirs, files in os.walk(VAULT_ROOT): # 跳过 .git 隐藏目录 if .git in root: continue for file in files: if not file.endswith(.md): continue path os.path.join(root, file) with open(path, r, encodingutf-8) as f: content f.read() # 替换反斜杠为斜杠 content content.replace(\\, /) # 替换旧的绝对路径前缀为相对路径相对仓库根目录 if VAULT_ROOT.replace(\\, /) / in content: content content.replace(VAULT_ROOT.replace(\\, /) /, ) with open(path, w, encodingutf-8) as f: f.write(content) print(路径修复完成)运行这个脚本前一定要先备份仓库或者确认在 Git 仓库里可以随时回滚。这个脚本的核心思路是把D:\我的知识库\assets\图.png替换成assets/图.png也就是把绝对路径变成相对仓库根目录的路径。但注意这种替换只适合图片在仓库内、且所有笔记的图片引用都相对于仓库根目录的情况。如果你的笔记分布在子目录里改成assets/图.png后子目录内的笔记可能还需要补../前缀这就是相对路径的坑——它依赖笔记自身的位置。所以我个人更推荐全仓库统一使用根目录下的 assets 文件夹这样脚本处理逻辑最简单。5. 常见问题与排查技巧实录图片问题千奇百怪但追根溯源基本就那几种。我把一年来收集的高频问题整理成一个速查表每条都是踩过坑后总结出来的。问题现象直接原因解决方案Typora 里图片正常Obsidian 里裂图Typora 写入了绝对路径改 Typora 设置为“复制到 ./assets 优先使用相对路径”Obsidian 里图片正常Typora 里裂图Obsidian 使用了“基于仓库根目录的绝对路径”或 Wiki 链接把 Obsidian 新链接格式改为“相对路径”和 Markdown 格式两个工具都正常换一台电脑裂图图片文件没有随笔记一起复制或者路径中带盘符确保 assets 文件夹和笔记一起拷贝用相对路径文件名带空格Typora 显示但 Obsidian 不显示Obsidian 对%20解码有问题少部分旧版本重命名文件名不要带空格或者升级 Obsidian移动笔记文件后图片全部失效相对路径基准变了移动文件时连 assets 子文件夹一起移动或者改用统一根目录 assets文件名带中文在某些编辑器里正常但在服务器上 404GBK/UTF-8 编码不一致保持系统编码 UTF-8文件名尽量避免特殊字符粘贴的图片在 assets 里但 Obsidian 里还是裂Obsidian 的附件设置指向了另一个文件夹检查 Obsidian 设置 → 文件与链接 → 默认附件路径Typora 批量应用规则后部分图片被跳过图片路径本身是网络图片或者 Wiki 链接手动处理或先在 Obsidian 中转换链接格式5.1 图片裂了先判断是哪种裂遇到图片裂图第一步永远是搞清楚是 Markdown 语法写错了还是路径指向的文件不存在。在 Obsidian 里把编辑模式打开看链接的写法在 Typora 里切换到源码模式或直接看图片链接。如果链接长这样那问题就是反斜杠和绝对路径。把这个改成assets/图片1.png如果笔记文件就在仓库根目录下大概率就好了。如果链接长这样而图片的实际位置是D:\我的知识库\项目复盘\assets\Pasted image 20240331.png那问题就是路径层级不对——多往上跳了一级。直接把../去掉就行。翻看十年前的技术博客和论坛里关于“Markdown 图片不显示”的讨论多到数不清但方法至今没变先查链接语法再查文件路径最后查文件名编码。这条排查路线适用性非常广。5.2 文件名中的空格和特殊字符我一直坚持一个建议图片文件名和笔记文件名最好不要带空格不要带括号不要带表情符号。不是不能带是带了之后各个工具表现不一致。Obsidian 在生成内部链接时会把空格自动编码成%20。Markdown 解析器应该都能正确处理%20Typora 实测可以但有些第三方工具、静态博客框架、Git 管理工具对%20的处理并不可靠。中文文件名也同理虽然现代工具基本都支持 UTF-8 中文路径但在旧版本 Typora 和某些 Linux 服务器上中文文件名偶尔会引发编码问题。建议的做法是在 Typora 的图像设置里把“自动重命名图片文件”打开文件名自动带上时间戳并做 URL 编码或者在 Obsidian 的附件设置里开启“自动重命名”。反正最后用 Obsidian 内粘贴的图片会自动加前缀最坏情况也就是文件名长一点。长文件名总比裂图好。5.3 Typora 激活问题的无关提醒在整理这个主题的搜索关键词时我注意到不少人搜“Typora 激活”和“Typora 序列号”。这里多说一句Typora 现在是付费软件官方也提供了免费试用期但版本更新频繁网上流传的“免激活”基本都有安全风险。如果你是重度 Markdown 用户我建议还是支持正版或者直接转向 Obsidian 的编辑器。毕竟 Obsidian 免费且开源配合好用的插件写作体验并不输 Typora。当然这只是个人建议工具选择看个人习惯。这个主题本身就比“怎么激活”更值得关注路径统一了之后你根本不需要在两个工具之间反复折腾也更愿意长期维护自己的知识库。5.4 批量把 Wiki 链接转为 Markdown 链接如果你之前的 Obsidian 仓库大量使用了![[图片.png]]这种 Wiki 链接而现在想在 Typora 里正常显示就需要转换成格式。Obsidian 社区插件有自动转换工具比如“Convert wikilinks to markdown”可以一键把全仓库的内部链接全部转为标准 Markdown 格式。但注意这个转换是不可逆的转换前先备份。我自己其实没做全库转换而是选择了一个折中方案日常大部分时间在 Obsidian 里看笔记只有写作和速记时才打开 Typora。Typora 主要用来“写新笔记”和“编辑个别文件”这时候只要新写的部分保持相对路径就能正常显示。旧笔记保持 Wiki 链接格式在 Obsidian 里完全没问题万一需要导出这些旧笔记到别处再单独跑一次批量转换。这样既兼顾了 Obsidian 原生的双链体验也不耽误 Typora 的写作流。如果你实在需要在 Typora 里看旧笔记还有一个临时方案直接在 Typora 里 CtrlF 搜索![[并替换成![](但后面的路径补全工作仍然无法自动完成所以前提还是笔记中的图片链接本来就用了相对路径。如果已经是 Wiki 链接加相对路径替换起来会很干净否则逐个手工处理会特别痛苦。5.5 双工具共用一套配置还需要做什么收尾配置改到这一步基本已经能保证“新写的笔记、新贴的图片”在两个工具里都不会裂了。还有几个收尾动作建议做一遍清理旧的残留图片文件夹。以前你可能在多个目录里都散落着图片统一 assets 方案后旧的图片文件夹可以移入统一的 assets 目录或者归档到一个叫archive-assets的文件夹里确保没有笔记引用它们之后再手动删除。这一步别急先搜索确认没有引用后再动。养成检查的习惯。我每次把一个 Markdown 文件从 Typora 切换到 Obsidian 时习惯性按一下 CtrlP输入“files”在“文件搜索”里确认图片文件是否存在。Obsidian 的文件搜索非常快基本是秒出。这个习惯帮我查出了不少路径问题特别是深度嵌套目录下的笔记。把配置固化下来。Obsidian 和 Typora 的设置都是跟着软件走的如果你换了台电脑重新装工具这些配置不会被自动迁移。所以建议把配置项记录下来或者直接把 Obsidian 的.obsidian文件夹加入版本控制里面可能包含你的插件和设置注意.obsidian文件夹中不能有个人敏感信息这样 clone 到新电脑后设置一并恢复。我用的是 Obsidian 官方同步配置也会跟着走所以换新设备基本零负担。如果你用 Git 管理仓库记得把.obsidian的 workspace 文件排除或处理一下否则每次打开关闭 Obsidian 都会有一堆无关 diff很烦。6. 这套方案的局限和后续扩展没有任何方案是万能的我把这套方案的边界也说清楚免得你遇到问题后怀疑自己配置错了。局限性一只解决本地图片。如果你用的是图床比如阿里云 OSS、腾讯云 COS、PicGo 上传那图片链接是云端 URL不存在本地路径问题。但代价是图片脱离本地离线看不了搬家换捆绑服务时会很痛苦。本地 assets 方案和图床方案不是二选一的关系可以结合日常笔记用本地 assets写完想发布的文章再上传图床替换链接。局限性二对多设备弱网场景需要一点容忍度。如果你的知识库在 Windows 和 Android 手机之间通过坚果云同步偶尔会有一张图没同步过去导致裂图。这不是路径问题而是同步时效问题。通常手动触发一次同步就能恢复不用太担心。局限性的另一面是扩展性。这套“相对路径 assets 文件夹”的结构天然兼容很多工具静态博客把.md文件和assets文件夹整个拷贝到 Hugo/Hexo 项目的content目录下图片路径只要把assets改成assets如果博客配置了静态资源目录一般就能正常工作。Obsidian 发布服务Obsidian Publish 对相对路径支持很好。Logseq它本身也支持assets文件夹模式。同一份 md 笔记放到 Logseq 的 pages 目录下只要图片路径保持相对 assetsLogseq 也能显示。这也是我最终选择“统一相对路径 assets”的根本原因——它不仅是 Obsidian 和 Typora 之间的通用协议更是 Markdown 生态里所有工具之间的通用语言。关于 Obsidian 和 Typora 的图片路径同步问题我目前这套方案已经稳定运行了接近一年。中间遇到的所有坑基本都写在上面了。如果你想省事就记住三条核心Obsidian 用相对路径格式Typora 复制图片到 assets 文件夹并开启相对路径所有图片统一放在 assets 里。这三点做到位你的知识库图片管理就算彻底完工了。