★ FEATURED ARTICLE 写 Markdown 的人十有八九都被图片折磨过。MarkText 这款 Markdown 编辑器用来写长文、做笔记都很顺手但图片从来不是它的强项PicGo 则正好负责“图片上传”这一件事两者搭配是很多博客作者固定下来的写作工作流。真正让大家纠结的往往是图床本身免费现成的 GitHub 和自建可控的 MinIO到底选哪个这篇文章我就把两者的完整配置、联动方式、踩坑经验以及我个人的选型思路一次性说清楚。我最早写博客的时候也图省事图片直接丢进本地文件夹等换电脑或者把文章同步到其他平台才发现所有图片全挂了。后来改用 MarkText PicGo 的组合才第一次体会到什么叫“截图即贴图”截完图自动上传、自动生成 Markdown 链接、粘贴进正文整个过程不超过三秒。但图床的选择又把我卡住了很久GitHub 免费但有各种限制MinIO 可控但需要服务器。下面是我折腾完两条路之后留下的完整记录。1. 图片问题为什么绕不开图床1.1 Markdown 图片的本质是一个 URL先回到最基础的一件事Markdown 里插图片写法是。这个地址可以是本地相对路径比如./images/foo.png也可以是一个完整的 URL比如https://example.com/foo.png。本地方案的坏处太明显——文章最终要发布到博客、公众号或者笔记平台换一台设备路径就失效图片就成了裂图。所以只要你有长期写作、跨端查看、发布分享的需求图片地址就应该是一个能在任何地方访问的 URL图床解决的就是“提供一个稳定、可达的 URL 来挂图片”。很多新人第一次配图床时会以为这是把图片“存储”在哪里其实问题的核心不是存储而是“公开访问”。对 GitHub 来说它本质是个代码托管平台只是因为你把图片放进了仓库而仓库能生成 raw 访问地址所以可以当图床用MinIO 本身就是一个对标云对象存储的服务只是它部署在你自己的服务器上。两者没有本质上的“能不能用”区别只有“访问链路怎么搭”“数据在谁手里”“成本怎么算”的区别。1.2 一个图床应该满足哪些条件我在实际用下来觉得合格的图床至少得满足这五点可访问返回的 URL 能被浏览器、CDN、RSS 阅读器正常打开没有防盗链。稳定图片地址不会三天两头变平台不会突然停止服务或者删除文件。速度尤其面向公网访客时图片加载不能等半天。可控我能知道图片放在哪能导出、能备份、能清理而不是上传之后石沉大海。成本可接受要么免费但代价清晰要么自建但运维可控。GitHub 和 MinIO 在这五点上的表现是完全不同的。先说说结论GitHub 胜在零成本、配置简单、套上 CDN 后速度也不错MinIO 胜在数据归属你自己稳定性和隐私控制都能掌握。理解完这个前提再进入具体配置就不会一头雾水因为你始终知道自己在为什么而配置。2. MarkText 和 PicGo编辑与上传的分工2.1 谁负责编辑谁负责上传MarkText 的核心能力是编辑 Markdown语法高亮、实时预览、导出文件都做得不错但它不是一个图床客户端。你在设置里通常只能配置本地图片保存目录它并不会帮你把图片上传到远程。PicGo 则恰好相反它不负责编辑只负责一件事把图片上传到你指定的图床并返回一个可用的 URL。它同时支持多个图床插件桌面端和命令行版都有。正因为两者各管一段组合在一起刚好能拼出一条完整的图片处理流水线截图或文件出现 → PicGo 自动上传 → URL 回到剪贴板 → 粘贴进 MarkText。很多刚从普通文本编辑器转过来的人会下意识在 MarkText 里找“上传到图床”的按钮找不到就以为是软件坏了。其实这很正常MarkText 对不同版本和平台的上传支持有过调整有的版本可以在设置里配置自定义上传命令有的版本弱化了这个入口。与其和版本较劲不如直接把 PicGo 当作上传中心用系统级的工作流把两者串起来。2.2 我目前最顺手的组合方式我的日常流程是这样的三步用系统自带截图工具或独立截图软件截取需要的图图片会自动进入剪贴板。PicGo 开启剪贴板监听后会立刻上传剪贴板里的图片并在上传完成后把 URL 以 Markdown 格式复制到剪贴板。回到 MarkText 编辑器直接CtrlV粘贴。如果剪贴板里是 Markdown 链接MarkText 通常会直接插入如果粘贴的是图片内容本身不同版本的表现会有点差异但多数情况会弹出本地保存或 URL 二选一的提示。如果你要插入的是本地已经存在的图片文件而不是截图那就把文件拖进 MarkText让它先按本地图片处理然后再打开 PicGo 选择这张图上传最后把返回的 Markdown 链接替换掉本地路径。这看上去多了一步但实际写作中很少发生因为写博客配图大都是实时截屏。如果你用的 MarkText 版本保留了自定义命令接口也可以尝试在设置里把上传命令指向picgo upload的可执行文件这样在编辑器中插入图片时编辑器会先把图片传给 PicGo 上传再把结果写回文档。这个方案对版本要求比较挑剔我的建议是用不了就不勉强流程顺不顺比功能全不全更重要。2.3 一个版本差异导致的坑这里要特别提一句MarkText 的历史版本里内置图床上传的入口、图片菜单的布局改过好几次。有些老教程直接让你在 MarkText 里选某个图床或者到某个菜单点“上传到云端”放到新版本里可能根本找不到。不要因为找不到按钮就觉得自己配置错了更不要随便去找来路不明的修复包。正确的做法很简单MarkText 只负责编辑和预览图片的“上传”动作统一交给 PicGo这样版本的变动影响最小未来换编辑器也不会推翻整套流程。3. GitHub 当图床三步配置和四个暗坑3.1 配置只要走三步GitHub 当图床本质是利用仓库来存储图片文件通过 raw 地址或 CDN 地址对外提供访问。配置动作本身不复杂但顺序别乱建仓库。在 GitHub 上新建一个公开仓库比如叫blog-images。注意仓库必须设置为 Public否则图片 URL 需要登录才能访问第三方博客展示时全都会抓瞎。生成 Token。打开个人设置里的 Developer settings创建 Personal Access Token勾选repo权限。这个 Token 相当于 PicGo 访问你仓库的钥匙生成后只显示一次一定要先复制保存再关闭页面。在 PicGo 里配置 GitHub 图床。填仓库名格式是“用户名/仓库名”、分支一般是main、Token再填一个存储路径比如img/表示图片上传到仓库的 img 目录下。保存并设为默认图床后上传一张测试图返回的 URL 会类似https://raw.githubusercontent.com/用户名/blog-images/main/img/abc.png。到这里GitHub 图床其实已经可用了。但直接把 raw 地址丢给博客只能保证可访问速度和稳定性就看网络环境了。这也是为什么很多人会用 jsDelivr 之类的公共 CDN 对 raw 地址做分发把 PicGo 里的自定义域名填成https://cdn.jsdelivr.net/gh/用户名/blog-images上传后得到的 URL 就变成带加速域名的形式访客加载图片会更快也能减少直连不稳定带来的失败。3.2 公开仓库和私密信息的边界用 GitHub 当图床最容易被忽视的是隐私边界。仓库既然是 Public那么任何知道你图片 URL 的人都能看到文件搜索引擎也可能索引这些图片。放博客配图没问题但千万别把身份证扫描件、内部文档截图、服务器密码之类的图片传上去。如果你传错了即使马上删文件也不等于世界上没人看过公开仓库的历史里可能还留着记录。我的习惯是单独建一个图片仓库和代码仓库完全隔离万一要清理或者转移影响面可控。3.3 Token 泄漏后的处理方案PicGo 配置里明文保存的 Token如果哪天你的配置文件被上传到公开仓库或者电脑交给别人维修Token 就等于暴露了。一旦发现正确的做法不是改仓库设置而是去 Developer settings 里把这个 Token 删掉或重新生成再去 PicGo 里更新新 Token。不要抱着“可能没人看到”的侥幸心理公网上的扫描行为远比想象中勤快各种明文密钥是第一优先级的收集对象。3.4 仓库膨胀和图片被滥用问题GitHub 对单个文件有 100MB 的大小限制单仓库也建议控制在 1GB 左右。如果图片又多又碎仓库会越来越重操作也会变慢。PicGo 上传时还会受 API 请求速率限制认证后的配额对个人写作完全够用但如果你是重度截图党一天传几百张就可能短时间遇到 403 或上传失败这是限流的正常表现不代表配置有误。还有一个容易被忽视的现实问题公开仓库的图片可能被其他人直接引用、盗链。一旦某张图被放到高流量页面你的仓库会被持续请求虽然一般不会产生直接费用但会影响你正常使用时的访问体验。GitHub 本来就不鼓励把仓库当作图床长期高强度使用所以任何基于它的方案都更适合“轻量、低频、能接受变动”的个人博客场景。3.5 常见故障排查顺序如果你配完之后上传失败或者图片打不开按这个顺序排查上传超时或失败先确认网络环境再看 Token 是否有效最后看仓库名和分支拼写是否正确。图片打不开但仓库里有文件多半是 raw 直连不稳定换 jsDelivr 域名或检查自定义域名是否填写完整。返回的 URL 缺少用户名或仓库名常见原因是自定义域名配置时前缀写错直接把期望的完整 URL 复制到浏览器测试一遍就清楚了。总的来说GitHub 适合作为入门首选零成本、资料多、不需要服务器但想长期稳定使用就得接受它在网络速度和滥用控制上的短板。4. MinIO 自建图床部署、接入和四个必踩的坑4.1 用 Docker 快速部署一个 MinIOMinIO 是一个兼容对象存储协议的服务可以部署在任意一台能跑 Docker 的服务器上。对个人博客来说一台低配置的云服务器就够了部署命令大致是这样docker run -d \ --name minio \ -p 9000:9000 \ -p 9001:9001 \ -e MINIO_ROOT_USERminioadmin \ -e MINIO_ROOT_PASSWORDminioadmin \ -v /data/minio:/data \ minio/minio server /data --console-address :90019000 是对象存储的 API 端口PicGo 上传走的是它9001 是网页控制台端口用来管理 Bucket 和策略。启动后访问http://服务器IP:9001就能打开管理界面用minioadmin / minioadmin登录。正式用于博客之前务必把默认的管理员账号密码改掉默认口令在公网上只要几秒钟就会被扫描到。我个人的建议是不要直接在裸奔的 9000 端口上对接 PicGo而是用 Nginx 或 Caddy 做一层反向代理把请求转发到 9000同时配上 HTTPS 证书。这样 PicGo 端不需要记 IP 加端口后续换服务器、迁移数据时影响也最小。4.2 创建 Bucket 并设置只读策略登录 MinIO 控制台后先创建一个 Bucket名字按你的域名习惯来比如blog-img。创建完成后默认 Bucket 是私有的外部无法直接访问。这时候把图片丢进去浏览器也打不开所以需要给 Bucket 配置一条匿名只读策略允许任何人通过 URL 读取文件但不能上传、不能删除。控制台里可以直接编辑 Bucket Policy一个典型配置是把Principal设为*Action只保留s3:GetObjectResource指向arn:aws:s3:::blog-img/*。理解上这相当于给目录设置了一个“只允许所有人读取”的权限上传动作仍然只能通过带有密钥的客户端完成。如果你常用命令行工具管理对象存储也可以借助mc客户端来设置策略效果一样。这里的关键是 Bucket 策略必须和你的使用方式匹配很多人配完发现图片 403十有八九就是漏掉了公开只读这一环。4.3 PicGo 接入 MinIO 的配置细节回到 PicGo 这边添加 MinIO 图床时主要配置项包括服务地址、端口、AccessKey、SecretKey、存储路径和自定义域名。AccessKey 和 SecretKey 就是上面控制台的账号和密码如果你追求更细的权限控制也可以在 MinIO 控制台里单独生成一对服务账号密钥。几个配置细节在实操中容易踩服务地址不要带协议也不要带路径。例如minio.example.com或服务器 IP端口单独填。如果前面做了 Nginx 反代且走 443端口就填 443并选择 HTTPS。存储路径字段要理解成“存储前缀和目录”。有的版本里有单独的 Bucket 字段路径就写 Bucket 下的目录有的版本没有单独的 Bucket 字段就把 Bucket 名拼在存储路径最前面比如blog-img/。这样上传后的对象会落到对应 Bucket 根目录最终 URL 也能按预期拼接。自定义域名一定要填你能真实访问的地址比如https://img.example.com不要填 MinIO 控制台地址。PicGo 上传成功后会根据自定义域名拼接最终图片 URL如果这个 URL 缺少 Bucket 路径就会一直 404。4.4 四个我实测踩过的坑第一个坑是 Content-Type 问题。有些情况下 MinIO 存储对象后没有正确返回图片的 Content-Type结果浏览器打开图片地址不是展示图片而是直接触发下载。解决方法是上传时通过客户端设置Content-Type或者在 Nginx 反代层根据文件后缀补上image/jpeg、image/png这类 MIME。如果发现图片能访问但浏览器老是下载而不是展示优先检查这一项。第二个坑是指定 HTTPS 后的证书问题。MinIO 默认生成的证书是自签名的你在 PicGo 里强行启用 HTTPS 而不配置受信任证书上传会直接报证书错误。要么给图片域名配置正规证书并让反代完成 TLS要么在测试阶段继续用 HTTP。不要为了省事直接关掉证书校验否则传图时会遇到奇怪的中断。第三个坑是路径和重定向。如果反向代理把根路径原封不动透传到 MinIO 的 9000 端口上传和访问都能成功一旦你加了路径前缀比如把所有请求转发到某个子路径下对象地址和反代规则很容易互相冲突。个人使用最省心的做法是单独用一个域名或子域作为图片域名根路径直接透传。第四个坑是备份意识。MinIO 数据都在服务器本地磁盘一旦磁盘故障、服务器被入侵或误删 Bucket图片就全没了。图床方案里“自建可控”的前提是“你自己负责备份”。我在实际使用中会把 MinIO 的数据目录定期同步到另一块磁盘或远端存储最低限度也要保证服务器故障后能恢复。到这里MinIO 作为图床已经能正常工作了。相比 GitHub 方案它需要一台服务器、一次 Docker 部署和一点维护意识但换来的是稳定的访问速度、可掌控的数据以及不用担心仓库限流或公共服务政策变化。5. GitHub 还是 MinIO给一个能直接套用的选型逻辑5.1 一张表看清差异我整理过一个对比表基本可以覆盖大多数人做决定时关心的点对比维度GitHub 图床MinIO 自建前期成本免费只要有账号需要一台服务器和域名配置复杂度三个字段几分钟服务部署、策略、反代半天起数据掌控在 GitHub 手里公开可见完全在自己服务器上访问速度直连看网络环境可套 CDN取决于带宽可控可内网高速稳定性依赖公共服务政策和 API 配额依赖你的运维能力和机器稳定性隐私保护适合非敏感图片可放截图、文稿等较敏感内容运维成本几乎为零需要关注磁盘、备份、证书、安全更新扩容与长期使用仓库会膨胀限制多磁盘够大就够用成熟协议支持这张表看下来其实没有绝对的好与坏。GitHub 更像“省心但受限”的方案MinIO 更像“投入成本换掌控”的方案。如果你在意的是快速跑通那就选 GitHub如果在意的是长期稳定和隐私边界那就选 MinIO。最怕的是选了 GitHub 又嫌弃它不稳定或者选了 MinIO 又不想做任何运维这都相当于拿错了工具硬干活。5.2 我实际会怎么选如果只是写个人博客、技术笔记图片数量不大想快速跑通整套工作流起步阶段直接选 GitHub 最省事唯一要做的就是及时给仓库套 CDN并注意隐私边界。等积累了上千张图、访问速度开始变慢、或者图片内容变得私密再迁到 MinIO。迁移动作本身不大把 MinIO 部署好去 PicGo 里新建一个图床配置然后把旧仓库里的图片批量下载再上传到 MinIO最后更新文章里的 URL 前缀即可。我在某次写作项目中就经历过从 GitHub 到 MinIO 的迁移触发点不是 GitHub 不能用而是某张被转载的图片带来了大量外部请求导致我日常访问仓库的速度明显下降。迁移之后图片域名换成了自己的子域加载速度可控心里也踏实很多。这个经历让我后来对“免费羊毛”多了一层认识你可以依赖它起步但要有随时能搬走的底气。5.3 一种折中两者同时保留如果你的文章既有普通配图也有少量隐私性较强的图片可以不把两者做成二选一。PicGo 支持多个图床并存你可以在不同场景手动切换。比如公开博客配图走 GitHub CDN内部文档或含隐私信息的笔记走 MinIO。这样一来公开内容不耗服务器流量私密内容不暴露在公共仓库算是一个兼顾成本和隐私的思路。唯一需要注意的是定期检查每个图床的使用情况避免冷门图床里的文件长期无人访问却占着磁盘。6. 图床搭好之后维护比选择更重要6.1 从一开始就规范命名和目录无论是 GitHub 还是 MinIO图片目录结构建议从一开始就规划好而不是让所有图片堆在一个根目录下。我的习惯是按文章主题分目录比如2025-xx-article/作为前缀。PicGo 的上传配置里可以设置存储路径前缀上传时的文件名建议用英文或数字组合关键词里不要带中文、括号或者空格否则在部分 CDN 或 URL 编码场景下会出现乱码和路径截断。截图默认生成的名字通常很乱可以在 PicGo 设置里打开自动重命名加上时间戳减少重名覆盖的概率。6.2 定期体检和备份图床不是配好就能一劳永逸的。每过一段时间我会抽查文章里几张历史图片的 URL 是否还能打开并检查 GitHub 仓库大小和 MinIO 磁盘占用。对 MinIO还会看服务日志里有没有异常访问并定时备份数据目录。这些工作没有多难但能避免某天文章页面突然出现大量裂图时才手忙脚乱。有一个更简单的方法写一个定时脚本每天把文章里出现的图片 URL 批量请求一次状态码不是 200 的列出来就能提前发现隐患。6.3 图片加载变慢时的处理顺序如果遇到图片加载变慢我一般按这个顺序排查先确认是不是域名解析或者 CDN 节点问题再检查原始图片大小很多博客图片其实是几 MB 的原始截图这往往是加载慢的主因而不是图床本身。给图片做一次压缩或转成更适合网页展示的格式往往立竿见影最后才去检查图床的带宽或仓库状态。不要一慢就急着换图床大多数时候是你的图太大了换到哪里都一样。6.4 最后一个小技巧分享一个我用了很久的习惯在 PicGo 里设置上传后自动复制 Markdown 格式链接并把 MarkText 的粘贴操作统一成“直接粘贴链接”。这样整条链路里完全不需要手动点“上传”按钮只需要截图、粘贴写文章的速度会明显提升。工具选型上GitHub 和 MinIO 只要适合你的场景都是好方案真正决定体验的往往是这些日常细节。
阅读完成 · 觉得有帮助？
