企业官网建设流程全解析

在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加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 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 验证上传流程与链接替换机制

配置完成后，先做一个验证。随便打开一篇笔记，按Ctrl+V粘贴一张剪贴板截图，正常情况下Obsidian底部会短暂出现上传中的状态，几秒后Markdown正文里出现一个以https://...开头的图片链接。这时候打开文件资源管理器，找到vault文件夹，你会发现本地根本没有新增这张图片文件。这就是图床生效的标志。

有几个设置项需要顺带确认一下。Obsidian的“设置 -> 编辑器”里有一项“默认图片粘贴方式”，建议选择“Markdown”。因为![[]]这种wiki链接格式是Obsidian特有的，放到其他Markdown工具里没法直接识别；而标准Markdown图片语法![](https://...)的通用性最好，发布到博客、公众号、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后面手动加查询参数，比如?v=20250101，也能强制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的编辑器先识别到剪贴板里的图片内容。如果你粘贴时Obsidian正处于源码模式或者某些特殊光标位置，插件可能不会触发。最稳妥的验证环境是：新的空笔记、聚焦在正文、普通编辑模式。

5.2 两个容易被忽略的重要细节

token过期是个很典型的“定时炸弹”。很多人在配置完图床后一两个月内一切正常，忽然某天发现上传不了图片了，第一反应是网络问题或插件坏了，折腾半天才想起看token有效期。旧图不受影响，因为图片已经以静态形式存在GitHub仓库里，但新建上传会持续失败。建议在手机日历上设一个token过期前的提醒，或者在GitHub token列表页面定期巡检。别等到报错才处理。

另一个细节是本地附件清理。Image Auto Upload插件默认会在上传成功后保留一份本地图片，对于已经转换到纯图床工作流的笔记来说，这会让vault里慢慢堆满重复图片，违背了“让笔记变轻”的初衷。在插件设置里有一个关于上传后是否删除本地图片的选项，建议开启自动删除。这个操作不可逆，所以第一次使用前，先做好vault的备份，确认图床链接都能正常打开后再开启。我实际使用中，每次上传成功后会快速扫一眼笔记里的链接格式，确认是https://开头再继续，基本不会出错。

这套图床配置用下来，最直观的感受其实是两件事：一是多设备打开笔记时终于不用提心吊胆担心图片消失；二是从Obsidian往博客、公众号搬文字时，图片直接跟随链接走，不再需要二次处理文本。顺便分享一个小习惯：如果你和我一样图片更新频率高，给文件名带上日期或版本号再上传，能省掉很多CDN缓存带来的烦恼。这个经验不复杂，但确实能帮你少走一点弯路。