
1. 两个工具对图片的默认态度就不一样这才是裂图的根源1.1 Obsidian优先考虑“内部链接”Typora优先考虑“标准Markdown”Obsidian定位是一个以双向链接为核心的知识库它天生就会把粘贴进来的图片当成内部资源来管理。默认情况下你每粘贴一张截图它会保存为一个“Pasted image 2024xxx.png”这样的文件然后在当前笔记里插入一个![[Pasted image 2024xxx.png]]形式的链接。这是Obsidian的Wikilink语法好处是在它自己的体系里识别得又快又准但坏处是这是一套非标准Markdown语法Typora并不会去解析它。Typora则是一个典型的“标准Markdown优先”编辑器。它插入图片时默认使用这种语法而且它的图片设置里可以直接指定“将图片复制到哪个文件夹”并自动帮你生成相对路径。它全程都不会碰Wikilink也不会理解![[ ]]这种写法。关键在于你过去一直用Typora写作图片路径都是./assets/xxx.png而Obsidian默认创建的却是它自己的附件机制那么切到另一个工具时链接自然就全部失效了。这不是哪个软件不好而是你没有统一两边的“链接方言”。我见过太多人在这两个工具之间倒腾笔记最后崩在图片上根因基本都出在这里。1.2 相对路径和“库根路径”的错位Obsidian在解析链接时优先把整个笔记库当作根目录。比如库根是MyNotes笔记放在MyNotes/日记/2024/图片放在MyNotes/附件/Obsidian根据“附件链接格式”的设置可能会写出附件/xxx.png或../../附件/xxx.png。如果写成“相对于库根”的格式在当前文档里看起来没问题一旦用Typora去打开同一篇笔记Typora只认“相对于当前Markdown文件”的路径它就会去日记/2024/附件/xxx.png找图片找不到图片自然裂开。所以你需要的不是让其中一个软件迁就另一个而是让两个软件都使用同一个标准所有图片路径都写成“相对于当前Markdown文档所在目录”的./或../形式并且所有图片都规规矩矩放在这个相对路径可抵达的目录里。这样无论用哪个编辑器打开解析逻辑都是一模一样的。1.3 只看其中一个工具时问题永远不会暴露这也是为什么很多人会困惑我在Obsidian里写笔记图片都正常显示你为什么说我的路径不行因为在Obsidian自身的环境里它无论用哪种路径都能通过内部机制找到附件。问题一定出现在“切换工具”或者“在另一个编辑器里打开”这一次操作上。如果你这辈子只用Obsidian再乱的路径也无所谓但只要你还有Typora、VS Code、静态博客生成器断图的概率就大大上升。所以下面的方案不是让Obsidian讨好Typora而是让你的笔记资产真正变成通用资产。哪天你换软件、换设备、或者把某篇笔记单独发给别人图片都不会因为路径规则不同而丢失。2. 先定目录再动配置assets文件夹的三种布局与我的选择2.1 三种主流assets布局对比在动手配置之前务必先想清楚图片到底要放哪。我从自己的笔记库和很多朋友的交流中总结了三种常见布局布局方式结构示例优点缺点全库一个assetsMyNotes/assets/管理集中图片便于统一备份文件多了重名概率高跨目录引用要写一堆../../assets按笔记子文件夹MyNotes/日记/2024/01/2024-01-01/每篇笔记自给自足路径短删除笔记可连带清图与Typora的${filename}行为天然一致共享图片会被复制多份按主题分目录MyNotes/assets/日记/、MyNotes/assets/项目A/兼顾集中与分类需要手动维护分类迁移时容易乱三种方案都能做到两端统一但代价不一样。全库一个assets适合图片量少、笔记量少的轻量用户按主题分目录适合内容边界非常清晰的人比如你只写项目笔记所有项目图都能规规矩矩丢进项目对应目录而像我这样笔记主题杂、又经常移动目录结构的人最怕的就是一张图被十几篇笔记引用移动一次断一大片。2.2 我最终采用“按笔记子文件夹”并让两边指向同一个名字我自己日常写作有个特点一篇笔记相对独立图片基本都是为了这篇笔记配的很少出现跨文章复用的图片。就算要复用我也宁可再复制一张也不愿意让一张图被十几篇文章引用——引用越多哪天你移动一次笔记文件断链面就越大。所以我最终选择了“按笔记子文件夹”的布局。简单说每篇笔记xxx.md旁边有一个同名目录xxx/所有属于这篇笔记的图片都放进去图片路径永远写成当你在Obsidian里设置“新附件位置”为“当前文件下的子文件夹”在Typora里设置“将图片复制到./${filename}”两个工具就会生成一模一样的路径结构。即使笔记文件移动了图片也随同移动相对路径不会变。提示如果你更偏好“所有笔记共用一个大assets文件夹”也能做到两端统一只要两边都叫assets并且路径都写成“相对当前文档”。但从我经验来看共用大文件夹在笔记量超过几千篇后重名风险和定位成本会明显上升不建议。3. Obsidian端配置让图片按Markdown相对路径写入3.1 核心设置项与含义打开Obsidian设置 → 文件与链接关注这几个地方新附件位置我选“当前文件下的子文件夹”。第一次粘贴图片时Obsidian会自动创建与当前笔记同名的子文件夹之后的截图都进这里。附件链接格式这里必须选“Markdown”。如果保留WikilinkTypora就无法读取。新版Obsidian里这个选项通常只影响图片等附件不影响你笔记之间的[[双向链接]]放心用。老版本叫法可能不同但意思是一回事。新链接格式如果你没有特殊需求可以继续用Wikilink作为文章内部的笔记链接因为这只影响笔记互链不影响附件。嵌入图片链接格式如果有“相对于当前文件 / 相对于库根 / 最短路径”这几个子选项一定选择“相对于当前文件”。选“相对于库根”的话Typora会看不懂。配置顺序有个小讲究先设置好目录再设置好格式最后再去粘贴图片。这样Obsidian会以的形式插入Markdown。你可以切到源码模式看一眼确认不是![[ ]]这一步就成功了。3.2 处理历史Wikilink图片正则批量转Markdown已经写了很久的笔记里面会残留大量![[Pasted image xxx.png]]。如果你希望统一到Markdown路径、方便Typora打开最简单的办法是用正则替换在所有md文件里搜索。在VS Code里批量替换或者在Obsidian社区插件里跑正则参考模式如下匹配!\[\[(Pasted image \d\.png)\|?\d*\]\] 替换这段正则对每张图不一定都合适因为你过去可能写过![[Pasted image 20240101120000.png|400]]这样的语法后面的|400是缩放参数正则会吃掉它改写为。如果笔记数量庞大推荐用脚本批量处理我在第5章会给出一个完整思路。这里提醒一条正则替换之前先备份整个Vault确认替换结果只影响图片引用绝不碰笔记之间的[[笔记名]]链接。3.3 粘贴图片后我建议立刻做的三件事在源码模式里看一遍路径确保是格式而不是![[文件名]]。关闭再打开一次笔记确认图片还在。用Typora打开同一篇笔记验证Typora能正常渲染。先在少量笔记上试通再全面推广不要一次性把所有笔记全改完才发现方向错了。4. Typora端配置让图片钻进同名子文件夹4.1 偏好设置里的图像组合Typora打开“偏好设置 → 图像”重点看这几项将图片复制到选择./${filename}。这样Typora会为当前md文件创建一个同名文件夹所有新粘贴的图片都进这里。使用相对路径必须勾选。这样才能生成这种相对路径。对所有本地图片应用上述规则这个按钮可以一次性把当前文档里已经存在的本地图片重新整理并更新路径适合单独处理某篇历史笔记。插入图片时建议选择“复制到指定目录”别用“移动”或“上传”。移动会把你原图从原有位置搬走万一原图还被其他地方引用就麻烦了。这样配置后你在Typora粘贴一个截图它生成目录xxx/插入这个路径结构与Obsidian端完全一致。4.2 为什么直接用./${filename}而不是写死./assets因为写死./assets会让整篇笔记的所有图都集中到一个名叫assets的文件夹。如果你每篇笔记都这么干最终库根目录下会出现几十上百个同名assets到时连你自己都分不清哪个图属于哪篇笔记。用${filename}的好处是文件夹跟笔记自己绑定移动笔记文件时它还在旁边Obsidian和Typora都能找到。当然如果你只在某个大分类下使用Typora且能保证所有文档的assets文件夹都统一放在固定位置写死一个./assets也行。只是对我来说“笔记同名文件夹”打包迁移最稳妥删笔记时连文件夹一起删不需要担心有隐藏引用会断。4.3 Typora打开Obsidian库文档时图片不显示先查这四件事文档里图片路径是不是![]()不是![[ ]]。路径是“相对当前文件”而不是带盘符的绝对路径。图片文件名和磁盘上的实际文件名是否完全一致大小写和全角半角空格都要注意。如果开了多端同步确认Typora打开的是同步盘里最新的本地副本不是另一个设备同步过来的残留目录。这四件事按顺序查一遍基本能解决90%的“Typora打开Obsidian笔记图片裂掉”问题。5. 历史资产迁移把一团乱的assets救回来5.1 迁移前备份然后按这五步清理先导出整个Vault备份再按笔记分批处理。我的实操顺序是建立一个_待清理文件夹把所有不再使用的图片先移进去然后逐篇检查MD文件把引用它们的链接改成新路径最后再用脚本扫一遍所有![[...]]图片引用列出未匹配项逐个手工处理。清理时一定不要直接删assets文件夹因为你不知道哪张图还被旧笔记引用。先把文件移走确认全库断链扫描没有异常再处理疑似废弃的图片。5.2 批量替换脚本思路用Python扫全库下面脚本不依赖特定插件只要电脑有Python 3就能跑。它做三件事一是找所有![[图片名]]形式的引用二是在指定附件目录中找同名图片文件三是把引用改成“相对于当前MD文件所在目录”的Markdown图片路径并写回。import re import pathlib vault pathlib.Path(rD:\MyNotes) # 改成你的笔记库根目录 assets_dirs [assets, 附件] # 旧图片可能存在的目录按需增加 wikilink_img re.compile( r!\[\[([^\]|]\.(?:png|jpe?g|gif|bmp|webp|svg))\|?[^\]]*\]\], re.I ) for md in vault.rglob(*.md): text md.read_text(encodingutf-8) changed [] def repl(m): name m.group(1).strip() for ad in assets_dirs: candidate vault / ad / name if candidate.exists(): rel candidate.relative_to(md.parent) changed.append(name) return f}) return m.group(0) # 找不到就保留原样 new_text wikilink_img.sub(repl, text) if new_text ! text: md.write_text(new_text, encodingutf-8) print(f已处理: {md.relative_to(vault)})你需要自己确认assets_dirs里列的是旧库中图片实际所在的目录。找不到的图片会原样保留最后看输出清单手动处理即可。脚本只动匹配到的图片引用不会碰普通[[笔记链接]]相对安全但还是建议先跑一个小范围测试。5.3 同名图片撞车怎么处理“Pasted image 20240101120000.png”这种图片名在多个笔记里完全可能重复。如果两篇笔记都引用同名但内容不同的图片脚本就不知道该替换成哪张。我处理这种问题的办法是先把所有重复文件导入Obsidian利用Obsidian的附件去重机制自动给重名文件加序号然后在Obsidian里逐个用“修复链接”或手动修改引用指向正确的图片。图片量不大的时候人工核对一个小时基本能搞定比写复杂脚本更快。6. 两端匹配后图片全流程怎么跑6.1 Obsidian粘贴 → Typora打开的全链路配置完成后的正常流程是在Obsidian里粘贴截图 → Obsidian自动把图片保存到当前笔记同名的子文件夹 → 笔记里写入→ 你把这篇笔记用Typora打开Typora按当前文档所在目录来解析这个相对路径自然能找到图片。反向也成立在Typora里粘贴图 → 存到./笔记名/→ 回到Obsidian同一个库内相对路径仍然一致。这就是“统一路径规范”带来的好处不会再出现两个软件各写各路径的局面。你甚至可以把同一篇笔记同时放在Obsidian库和Typora的常用目录里只要图片路径始终是相对当前文档的两边打开都能正常显示。6.2 我踩过的坑空格、中文名、路径里带井号路径里的空格和中文通常没事现代编辑器都处理得了但建议不要让文件名里出现#、%、在部分老版本解析器里会被当成特殊字符。比如assets/Pasted image 2024#1.png中的#可能会被当成锚点截断。Obsidian默认的粘贴文件名是安全的但如果自己手动改名尽量去掉这些符号统一用短横线或下划线风格。另外跨平台使用时要特别注意大小写。Windows的文件系统不区分大小写Linux和macOS默认区分在Windows上写着实际文件叫abc.png也能显示换到macOS或Linux就裂了。建议统一小写文件名尤其在配合Git同步的情况下。6.3 多设备同步图片这样跟着走如果你在用同步盘或自建Git库图片比较大的话同步时间会变长。我的习惯是把图片统一放在库内、笔记同目录不使用外部绝对路径这样任何同步方式都只能整体搬运相对路径不会因设备目录不同导致失效。给Git库配置时不要忽略*.png这类后缀否则换一台电脑拉下来就全裂了。另外同步前少用“按文件名排序”手动调整文件夹层级。因为移动文件夹的同时路径会变Obsidian可能自动更新引用但Typora不会所以迁动后要用Typora再抽查几篇笔记。如果你和我一样偶尔会整理目录建议把“自动更新内部链接”打开它能帮你减少一部分手工修正。最后再分享一个很实用的小习惯我每周会做一次全库断链扫描。Obsidian里用自带的“未解析的链接”面板查一遍Typora侧就全局搜索![[看看有没有漏网的Wikilink图片。这个习惯帮我节省了特别多事后救图的时间。工具没有高低之分关键是让它们用同一套语言说话配置一次后面就再也不用跟assets文件夹纠缠了。