在Obsidian里写笔记写得越久图片管理的问题就越躲不开。默认情况下粘贴一张截图进笔记Obsidian会把图片存成vault里的一个本地文件笔记正文里用相对路径引用它。这个设计单独看没什么毛病但只要你尝试过“换了台电脑继续写笔记”或者“把一篇笔记发给朋友”就会立刻撞上一堵墙图片没了、链接断了、整篇笔记只剩一堆文字。这个教程要解决的就是给Obsidian配一个图床让图片在粘贴进笔记的同时自动上传到远端正文里只留一个永久可访问的HTTPS链接。核心用法不复杂准备一个图床仓库、拿到访问密钥、装一个Obsidian插件、填几行配置。接下来我会把每一步的原理和坑都摊开来讲适合正在搭建Obsidian知识库、准备把笔记发布到博客或公众号以及已经踩过本地图片失效坑的人参考。1. 为什么Obsidian一定要配图床1.1 本地图片方案的三处硬伤先说一个多数人刚开始没意识到的问题Obsidian的图片默认存储在笔记同一目录或指定附件目录里Markdown文本通过相对路径引用它。这套方案在“素材库自给自足”时很好用因为笔记和图片一起走本地离线也能看。但放到真实使用场景里三处硬伤很快就暴露了。第一处是跨设备同步。我自己的使用习惯是工作电脑、笔记本、手机三端轮流写笔记vault通过网盘同步。问题是不同设备上vault的绝对路径不一样如果某台设备没有完整同步附件目录或者同步工具中途出错漏掉了一批图片打开笔记时就会看到一堆断裂的图片引用。相对路径在本地可靠但一牵扯到多端同步和文件版本冲突图片就成了最脆弱的一环。第二处是分享和发布。当你把一篇Obsidian笔记导出成PDF或Markdown发给别人或者直接粘贴到博客后台、公众号编辑器里本地图片引用会原样暴露出去对方根本看不到图。做技术博客的人应该深有体会很多文章写得不错但配图全部丢失阅读体验直接减半。如果不走图床每次发布都得手动把图片重新插入一遍效率极低。第三处是备份与仓库体积。图片是二进制文件一多起来vault的体积会明显膨胀。用Git管理笔记仓库的话每次改动图片都会生成新的blob对象仓库很快变成几GB克隆和提交都变慢。把图片从笔记仓库里挪出去vault和Git仓库都能保持轻量备份速度会快很多。1.2 图床到底做了什么图床的全称是“图片托管服务”它的本质就是把图片上传到一个远端存储并返回一个以http开头的图片地址。Obsidian配合图床插件后整个流程被压缩成一个无感操作你在笔记里粘贴截图插件自动把图片传到远端然后把笔记里对应的引用替换成网络图片链接。用大白话理解就像你本来把照片夹在笔记本里带着本子到处跑很重现在改成把照片上传到云相册本子里只留一个相册链接。不管本子在哪、被谁翻开点链接就能看到照片。图床方案的核心价值是让笔记变成“纯文本依赖”——唯一的非文本内容也被搬到了远端本地仓库里只有文字和一堆URL换设备、同步、备份、发布全都变轻了。顺带说一句图床不是只针对Obsidian。Typora、VS Code写Markdown、Hugo/Hexo写博客甚至Joplin、思源笔记这些工具都适用同一套思路。本教程以Obsidian为操作主体但配置逻辑可以平移。1.3 主流的四类图床方案怎么选图床方案市面上不少我按配置成本和实际使用体验分成四类新手直接照着表格选就够用。方案成本国内访问速度稳定性适合谁GitHub jsDelivr CDN免费较快中等CDN偶尔需要回源个人笔记、博客配图追求零成本Gitee 码云免费较快对外链有限制经常需要审核不太推荐除非完全自用阿里云OSS / 腾讯云COS按量付费每月几元快高有备案域名、追求稳定访问的用户七牛云 / 又拍云有免费额度快高但测试域名受限已有备案域名的博客作者我自己的主力方案是GitHub加CDN原因很简单免费、配置一次后续几乎不用管、生成的图片链接还能直接用在博客和公众号里。Gitee以前也是免费图床的好选择但现在外链访问需要登录审核用作图床的体验已经不太行了不建议再花费精力。云对象存储的访问速度和稳定性最好适合对图片访问有强需求的场景但需要绑域名和备案新手第一站不建议直接上这个。2. 准备图床仓库、分支与访问密钥2.1 创建图床专用仓库这一节以GitHub为例。没有账号的先注册一个这是基础操作不展开。登录GitHub后点击右上角加号选择New repository。仓库名称建议取images、blog-images或obsidian-assets这类一眼能认出的名字方便以后管理和替换链接。可见性这里关键想走CDN加速就必须选Public因为jsDelivr只能代理公开仓库的内容。如果你图片私密性要求极高那就不适合用这个方案后面我会单独说明。仓库创建页面里有一个“Add a README file”的选项很多人容易忽略但这一步非常关键。勾选它GitHub会在仓库初始化时生成一个默认分支同时创建首次提交。如果不勾选仓库是空的不存在main分支。后面PicGo上传时会对仓库指定分支做提交仓库没有分支的话上传必然报错得一通排查才能发现是这里埋的雷。创建完成之后仓库地址形如https://github.com/你的用户名/仓库名。后面配置插件时需要把用户名和仓库名分开填写这一串URL本身用不上别直接整个复制进去。2.2 生成Personal Access Token图床工具要往GitHub仓库上传文件不能只靠账号密码因为密码登录在GitHub API里已经不被支持了。需要的是Personal Access Token简称PAT。这是GitHub官方提供的API访问令牌相当于一把带有特定权限的钥匙。生成路径是GitHub右上角头像 - Settings - Developer settings - Personal access tokens - Tokens (classic) - Generate new token (classic)。这里推荐用classic类型因为当前主流图床工具对Fine-grained token的兼容性还不太统一classic最省心。进入配置页面后Note随便填比如obsidian-image。Expiration是有效期选项至少要选90天最长的自定义到期时间理论上可以拉得很远但我的建议是选一个适中的周期比如90天或半年。选太短过期之后如果忘了更新上传会突然失败选太长token泄露的风险窗口大。这个度自己权衡。权限区域里勾选第一个大项repo即可它会覆盖仓库内容的读写权限其他权限一概不需要不要图省事勾全选。配置完成后点击生成页面会显示一个以ghp_开头的一串字符复制保存好。这个值只在创建时显示完整内容一旦关掉页面就再也看不到了。注意token就相当于你账号的“机械钥匙”绝对不能手滑提交到博客仓库或者公开笔记里。如果发现token意外泄露最快的补救方式是去GitHub对应页面点Regenerate重新生成旧token会立即失效。2.3 为什么用公开仓库而不是私有仓库这是一个很典型的认知陷阱。很多人觉得“图床就是要存图片私有仓库更安全”于是把仓库设成Private结果发现jsDelivr的图片URL打不开只能绕回使用raw.githubusercontent.com的地址国内访问速度很不稳定。原因很简单jsDelivr的gh功能专门服务GitHub公开仓库私有仓库没有对应的CDN能力。所以我的建议是把“仓库可见性”和“图片内容”分开看。图床只放笔记里需要展示的普通配图截图、流程图、临时素材这些东西本身没有多少保密价值公开了也没问题。真正私密的内容比如身份证照片、内部文稿截图本来就不应该进笔记更不应该放图床。做到这两类内容分离公开仓库就没啥心理负担。如果你确实对图片私密性有硬性要求那GitHub方案就不太合适了可以绕开CDN改用云厂商的私有桶搭配签名URL不过那套逻辑会复杂不少本教程就不展开讲了。3. Obsidian端插件安装与配置实操3.1 安装Image Auto Upload插件Obsidian端需要安装的是Image Auto Upload插件。这个插件的作用是接管剪贴板粘贴图片的动作自动调用内置的PicGo Core完成上传并把笔记里的图片引用替换成图床链接。安装路径Obsidian左下角设置图标 - 第三方插件Community plugins- 关闭安全模式如果第一次使用- 浏览 - 搜索“Image Auto Upload”- 点击安装 - 启用。安装完成后建议重启一次Obsidian让插件完全加载。这一步很多人会省略结果发现插件设置界面打不开误以为是安装失败了。其实大多数Obsidian插件都建议重启一次再继续配置特别是涉及剪贴板监听和设置界面渲染的插件。这个插件内置了PicGo Core不需要你再单独安装PicGo桌面应用。这个设计对新手特别友好因为PicGo应用本身需要图形界面和系统托盘常驻在命令行工具和服务器环境里根本跑不起来。内置Core后Obsidian插件进程内部就能完成上传逻辑更轻配置项也更集中。3.2 插件参数逐项填写说明启用插件后进入设置找到Image Auto Upload。不同版本界面字符可能略有差异但核心字段是固定的。我这里把每一项的参数含义和注意事项拆开讲。字段填写内容常见错误Repo HostGitHub选成GiteeRepo OwnerGitHub用户名填成仓库完整URLRepo Name仓库名填成用户名/仓库名的组合Branch仓库默认分支名用了master实际是mainToken之前生成的ghp_开头字符串填成密码Storage Path图床内的目录如img/开头多写一个斜杠Custom URLhttps://cdn.jsdelivr.net/gh/用户名/仓库名main把仓库名重复写了两次逐个解释。Repo Owner和Repo Name一定要拆开填很多人在Owner里填了完整的https://github.com/username/repo上传时拼接地址就会变成https://github.com/https://github.com/...必失败。Branch填仓库默认分支绝大多数新建仓库是main极老仓库可能是master不确定的话回GitHub仓库页面看分支名。Storage Path是图床内的目录建议填img/这样所有上传的图片都归到仓库的img文件夹里避免仓库根目录被一堆png文件塞满。这里有一个细节路径不要以/开头也就是填img/而不是/img/。因为工具拼接完整路径时会自动加上根目录符号开头再多一个斜杠就会生成无效路径。Custom URL这里推荐直接用jsDelivr CDN地址https://cdn.jsdelivr.net/gh/用户名/仓库名main。注意结尾不需要再加main之后的目录工具会自动把Storage Path和文件名拼到后面。如果你完全不管CDN也可以不填这个字段工具会默认使用https://raw.githubusercontent.com/...的地址。但前面已经说过这个地址在国内访问不稳定图片在笔记里加载会很慢所以还是把CDN地址填上更稳妥。另外如果你打开插件的JSON配置文件想手动核对内容最终的PicGo Core配置大约长这样{ picBed: { uploader: github, github: { repo: 你的用户名/你的仓库名, branch: main, token: ghp_你的token, path: img/, customUrl: https://cdn.jsdelivr.net/gh/你的用户名/你的仓库名main } } }这里repo字段是用户名/仓库名的合并格式和插件设置界面里拆分填写的逻辑不同。正常情况下你不需要手动改JSON插件设置界面保存后会自动生成这个示例只是帮你理解它最终存储的结构。3.3 验证上传流程与链接替换机制配置完成后先做一个验证。随便打开一篇笔记按CtrlV粘贴一张剪贴板截图正常情况下Obsidian底部会短暂出现上传中的状态几秒后Markdown正文里出现一个以https://...开头的图片链接。这时候打开文件资源管理器找到vault文件夹你会发现本地根本没有新增这张图片文件。这就是图床生效的标志。有几个设置项需要顺带确认一下。Obsidian的“设置 - 编辑器”里有一项“默认图片粘贴方式”建议选择“Markdown”。因为![[]]这种wiki链接格式是Obsidian特有的放到其他Markdown工具里没法直接识别而标准Markdown图片语法的通用性最好发布到博客、公众号、GitHub时都不用再转换。这个插件还提供了一个很实用的批量命令在命令面板里搜索“upload all local images”可以把当前笔记里所有引用本地附件的图片一次性上传到图床并替换链接。我迁移旧笔记时主要靠这个命令。操作前建议先复制一份vault或确保Git仓库已提交因为替换操作会批量改写Markdown文件内容万一有意外可以回滚。3.4 进阶图片路径管理与CDN缓存小知识存储路径的规划在图片不多的时候看不出差别图片一多就很重要了。我见过有人在仓库根目录上传了上千张图文件名全是随机哈希后期想批量清理或迁移时非常痛苦。建议从第一天开始就给不同的用途建立目录比如img/blog/用作博客配图img/notes/用作日常笔记截图。这样后面想单独导出某个分类的图片或者按目录做CDN刷新都方便得多。CDN有一个特性需要知道jsDelivr会对远端文件做缓存图片第一次访问时回源到GitHub之后的访问直接从CDN节点返回。这意味着如果你覆盖上传了同名图片文件名没变但你看到的内容可能还是旧的因为CDN缓存还没过期。解决办法有两个一是文件名里带上版本号比如architecture-v2.png改文件名即可绕过缓存二是在图片URL后面手动加查询参数比如?v20250101也能强制CDN重新回源。这个技巧在更新博客配图和文档截图时很实用我实际踩过好几回“改了图但页面没变”的坑最后都是靠改名解决的。4. 备选图床云对象存储配置一览4.1 腾讯云COS与阿里云OSS的通用配置思路GitHub方案无论如何免费国内访问速度和稳定性还是存在天花板。如果你的笔记配图需要被比较正式的文章或站点引用或者你本身就有备案域名可以考虑云对象存储。这里不展开十几种云产品的细碎差异只说通用配置逻辑用哪家都能对上。第一步开通对象存储服务创建一个Bucket存储桶存储地域一般选离你最近的城市节点。访问权限务必选择“公有读私有写”图床需要让所有访客都能通过URL读取图片但只有你自己能上传。如果选成私有读写图片链接直接打不开会以为是自己配错了其实权限不对。第二步创建API密钥。在云服务商的访问控制台里创建AccessKey ID和AccessKey Secret这一步相当于给工具开通账号。密钥的权限建议只勾选目标存储桶的读写权限不要直接给账号最高权限。很多云厂商支持“子用户自定义策略”能做到最小权限安全性更好。第三步在PicGo类的图床插件或PicGo应用中选择对应的云服务商上传器填入密钥、Bucket名称、存储区域等字段。各字段名称在PicGo里都有明确提示照着复制进去就行。配置完成后测试上传一张图片把返回的URL放到浏览器打开能正常显示图片就说明通了。4.2 免费额度与绑定域名需要留意的问题七牛云、又拍云这类服务商常年提供免费存储额度和每月固定流量用来当图床表面上很香。但有个前提容易忽略这些服务的免费测试域名通常不能用于生产环境。所谓“生产环境”说白了就是任何正式对外访问的链接。如果只是自己临时预览问题不大但放博客里长期用短则几天长则几个月测试域名会被回收到时候全站图片全部失联。想要稳定使用这些免费额度必须绑定自己的备案域名。如果手头没有备案域名这一条路基本可以画叉。阿里云OSS和腾讯云COS同样有这个问题使用云厂商默认提供的Bucket域名在国内大多数场景下可以直接对外访问但如果要绑定自己的自定义域名域名必须完成ICP备案。所以“有备案域名”是上云图床的一个重要前提条件没有的话先在GitHub方案上把流程跑顺再说。另一件容易忽略的事是对象存储的计费逻辑。存储本身很便宜但图片访问产生的流量费、请求次数费是另外计算的。个人笔记站访问量低一个月几块钱很正常但如果把大尺寸图片设计图直接放上去又被刷了流量账单会让人肉疼。建议图床Bucket里面只放压缩处理过的图片单张控制在几百KB以内既省流量又提升访问速度。5. 踩坑实录与排查技巧5.1 高频报错速查表配置图床过程中我遇到过的以及身边朋友问过的问题主要集中在下面几类整理成一个速查表照着排查比自己瞎试快得多。现象可能原因解决方法粘贴图片后本地还是新增了图片文件插件未成功拦截上传动作检查插件是否启用重启Obsidian上传失败提示404仓库不存在或分支名写错回GitHub核对仓库名和默认分支名上传失败提示401/403token无效、过期或权限不足去GitHub重新生成token确认勾选repo权限上传成功但图片刷新很慢默认走raw地址国内访问不稳定在Custom URL填jsDelivr CDN地址图片偶尔能看到偶尔看不到jsDelivr首次回源耗时较长等待首次缓存生效后续会变快插件市场搜不到该插件Obsidian社区插件市场网络不稳定换个网络环境或稍后重试上传到图床后笔记里显示本地图片失效本地附件和远端链接混用批量上传旧图片并替换链接关于第一条补充一个细节。插件拦截粘贴图片的操作需要Obsidian的编辑器先识别到剪贴板里的图片内容。如果你粘贴时Obsidian正处于源码模式或者某些特殊光标位置插件可能不会触发。最稳妥的验证环境是新的空笔记、聚焦在正文、普通编辑模式。5.2 两个容易被忽略的重要细节token过期是个很典型的“定时炸弹”。很多人在配置完图床后一两个月内一切正常忽然某天发现上传不了图片了第一反应是网络问题或插件坏了折腾半天才想起看token有效期。旧图不受影响因为图片已经以静态形式存在GitHub仓库里但新建上传会持续失败。建议在手机日历上设一个token过期前的提醒或者在GitHub token列表页面定期巡检。别等到报错才处理。另一个细节是本地附件清理。Image Auto Upload插件默认会在上传成功后保留一份本地图片对于已经转换到纯图床工作流的笔记来说这会让vault里慢慢堆满重复图片违背了“让笔记变轻”的初衷。在插件设置里有一个关于上传后是否删除本地图片的选项建议开启自动删除。这个操作不可逆所以第一次使用前先做好vault的备份确认图床链接都能正常打开后再开启。我实际使用中每次上传成功后会快速扫一眼笔记里的链接格式确认是https://开头再继续基本不会出错。这套图床配置用下来最直观的感受其实是两件事一是多设备打开笔记时终于不用提心吊胆担心图片消失二是从Obsidian往博客、公众号搬文字时图片直接跟随链接走不再需要二次处理文本。顺便分享一个小习惯如果你和我一样图片更新频率高给文件名带上日期或版本号再上传能省掉很多CDN缓存带来的烦恼。这个经验不复杂但确实能帮你少走一点弯路。