自建图床怎么选：三条路线对比与 GitHub + PicGo/PicList 主线搭建
把博客图片交给第三方图床，最怕的不是某天它收费，而是它悄悄关停、改域名或者限制外链——文章还在，配图先一步集体失效。自己搭图床的意义正在于此：图片的存放位置、链接形式和迁移路径都握在自己手里。但「自建」不是只有一种做法，选错路线，后面全是补救。本文先把三条主流路线摆在一起讲清代价，再以门槛最低的 GitHub 仓库托管为主线完整走一遍，最后补上域名、防盗链、备份和迁移这些决定图床寿命的部分。
一、先选路线：三条路的真实代价
图床的本质是两件事：文件存在哪、链接怎么分发。按这两个问题的答案，自建图床可以分成三条路线。
| 维度 | 对象存储 + CDN | 图床程序自托管 | 代码仓库托管（GitHub） |
|---|---|---|---|
| 存放位置 | 云厂商对象存储桶 | 自己的 VPS 磁盘或挂载存储 | GitHub 公开仓库 |
| 搭建门槛 | 中：开桶、绑域名、配 CDN | 高：装程序、配环境、长期运维 | 低：建仓库加一个上传工具 |
| 持续成本 | 按用量付费，小流量很低 | VPS 租金，固定支出 | 零，靠平台免费额度 |
| 分发质量 | 最好，可绑自有域名、全球节点 | 取决于服务器线路，可再套 CDN | 依赖 jsDelivr 等公共 CDN 转发 |
| 防盗链能力 | 强，Referer 白名单是标配 | 中，靠程序或 Web 服务器规则 | 弱，公开文件基本无防护 |
| 主要风险 | 欠费停服、流量被刷产生账单 | 程序漏洞、服务器单点故障 | 仓库体积上限、平台政策变化 |
| 适合谁 | 长期认真写、图片量大的站长 | 已有 VPS、愿意折腾的玩家 | 个人博客、笔记配图、刚起步的人 |
三条路线没有高下，只有匹配不匹配。对象存储加 CDN 是「正统解法」：链接是自己的域名，速度、防盗链、扩容都可控，代价是要绑卡付费，并且必须盯着账单和流量异常。自托管图床程序（常见的有 Lsky Pro 兰空图床、EasyImage 等）适合手里已经有 VPS 的人，上传管理体验最接近商业图床，但程序本身的安全更新、数据库备份都成了你的新工作。代码仓库托管胜在零成本和十分钟能上线，短板也同样明显：它本质上是在借用代码托管平台的存储和公共 CDN 的转发，体积、单文件大小都受平台规则约束（具体上限以 GitHub 与 jsDelivr 官方文档现行说明为准），流量大了既慢也不合规矩。
本文的主线选第三条，理由是它最适合「先跑起来」：对刚开始写博客的人，图床的第一需求是稳定出链接，而不是一步到位的架构。但请带着第二部分的认知往下看——主线里的每一步，我都会顺手指出它对应到另外两条路线时该怎么做，以及什么信号出现时应该迁移。
如果你已经决定直接上对象存储，主线部分可以跳读：你需要完成的是开通存储桶、绑定自定义域名并开启 HTTPS、在上传工具里换成对应的存储配置（PicGo/PicList 都内置主流对象存储的支持），防盗链和备份部分则完全通用。
二、主线：GitHub 仓库图床从零搭完
整条链路只需要四样东西：一个 GitHub 账号、一个专门放图的公开仓库、一枚访问令牌、一个本地上传工具。先把准备项一次备齐：
第一步：建一个只放图的仓库
登录 GitHub 后新建仓库，命名建议用 img-bed、images 这类一眼能认出用途的名字，后续迁移和排查都省事。关键选项只有两个：可见性必须选 Public——私有仓库的文件无法通过链接匿名访问，图床也就无从谈起；同时勾选添加 README 初始化仓库，免得空仓库没有分支可用。
仓库要专用，不要和代码仓库、博客源码仓库混用。一是图片提交频繁，混在一起会把代码仓库的提交历史冲得没法看；二是将来迁移图床时，一个纯图片仓库打包搬走最干净。
第二步：生成访问令牌
上传工具往仓库里写文件靠的是访问令牌（Token），它等同于这个仓库的钥匙。
- 生成 Token
- 进入页面后选择生成新令牌
生成时注意三点。第一，备注写清用途和工具名，比如「PicList 图床上传」，将来在令牌列表里一眼能认出哪个能删。第二，权限只给图床需要的范围：经典令牌（classic）勾选 repo 即可；如果用细粒度令牌（fine-grained），把仓库范围只圈定到图床仓库、权限只开 Contents 的读写，比经典令牌的全仓权限更稳妥，推荐优先用这种。第三，过期时间别图省事选永久，设一个你能记住的周期，到期轮换一次，泄露的风险窗口就被关小了。
令牌生成后只完整显示一次，立刻存进密码管理器。任何把令牌写进公开仓库、截图发群里、塞进前端代码的行为，都等于把仓库钥匙贴在门上——真发生泄露时，唯一有效的补救是马上回令牌页面把它删掉，再生成新的并更新工具配置，同时检查仓库有没有多出不认识的提交。
第三步：选上传工具并完成配置
PicGo 和 PicList 是同源的两个工具，选哪个取决于你要不要「管理」图片：
| 对比项 | PicGo | PicList |
|---|---|---|
| 定位 | 只做上传这一件事 | 上传加本地管理 |
| 图片压缩 | 不带，靠插件 | 内置，可设质量与尺寸上限 |
| 自动重命名 | 不带 | 支持按时间、哈希等规则改名 |
| 批量与相册 | 基础 | 更完整，能回看、删除已传图片 |
| 上手成本 | 装完填四个字段就能用 | 设置项多，需要花十分钟熟悉 |
我的建议是：只想要「截图、粘贴、拿到链接」的人用 PicGo（安装包在 GitHub Releases 下载）；图片量大、想在上传前统一压缩和改名的人用 PicList（源码仓库在 Kuingsmile/PicList）。两者填的图床参数完全相同：
图床配置名: 随意起，如 GitHub 图床
设定仓库名: 你的用户名/仓库名
设定分支名: main
设置 Token: 上一步生成的令牌
设定存储路径: img/（按月份或用途分子目录都可以）
自定义域名: https://cdn.jsdelivr.net/gh/你的用户名/仓库名@main
其中「自定义域名」一栏填的不是域名，而是链接前缀：它决定上传成功后返回给你的链接长什么样。先用仓库原始地址把流程跑通，再换成下一节讲的 CDN 前缀也不迟——但注意，换前缀只影响之后的新链接，旧链接不会自动跟着变，这正是第三节要强调「链接前缀尽早定死」的原因。
配置完成后拖一张图进上传区测试。返回的链接能在无痕窗口里直接打开、且仓库里能看到对应文件，才算链路通了。写进 Markdown 时就是一行：
此后日常使用无非三种姿势：截图后粘贴上传、把文件拖进窗口、或在 Typora、Obsidian 这类编辑器里把上传工具设为图片处理程序，写文章时粘贴图片自动变链接。
三、域名、CDN 与 HTTPS：链接这层皮要穿对
图传上去了，链接却有讲究。仓库文件的原始链接走的是 GitHub 的 raw 域名，国内访问时快时慢，偶尔直接打不开，所以主线方案实际对外用的都是经 CDN 转发的链接。
最常用的转发是 jsDelivr，它对 GitHub 仓库有一套固定改写规则：
原始链接: https://raw.githubusercontent.com/username/repo/main/images/photo.jpg
转发链接: https://cdn.jsdelivr.net/gh/username/repo@main/images/photo.jpg把上传工具「自定义域名」填成转发前缀，之后每张图的链接自动就是转发版。它免费、节点覆盖广，代价同样要心里有数：缓存刷新不是实时的，替换同名文件后旧图还会存活一阵（它的官方清缓存入口可以手动触发，但别指望秒生效，这也是为什么图片只增不改、改图必改名是最省心的使用纪律）；另外它对单文件大小有上限，大图和视频不要往这条链上放，上限数值以其官方文档为准。
如果愿意多走一步，更稳的做法是让链接从第一天起就长在自己的域名下：给仓库开启 GitHub Pages 并绑定子域名（如 img.你的域名.com），DNS 加一条 CNAME 指向 GitHub Pages，平台会自动签发并续期 HTTPS 证书。这样做的好处在迁移时才显形——将来你把文件从 GitHub 搬到对象存储，只需要改一处回源和解析，全网引用你图片的文章一个字都不用动。对象存储路线同理：绑自有域名加 CDN 分发，链接与存储厂商解耦。
无论哪条路线，HTTPS 都没有商量余地：现在的主流浏览器对 http 图片会警告甚至拦截，混合内容还会拖累整页。凡是你选的方案里出现「证书自己想办法」的环节，就换用平台托管证书的方案，不要在这一项上省事。
四、防盗链与滥用：公开图床的先天短板
先说实话：仓库托管这条路线，防盗链基本是无解题。文件既然能被任何人用链接直接打开，就不存在可靠的「只许我自己的站引用」的开关，jsDelivr 层面也不提供 Referer 白名单。指望它防盗链，等于选错工具——这也是路线对比里我把这一项标弱的原因。
在这个前提下，能做的是把损失关小：
- 文件名不可猜。用时间戳或哈希重命名（PicList 内置），别人拿到一张图的链接，也推不出你其他图片的地址，批量扒图成本陡增。
- 图片上保留水印意识。原创图、截图里如果有不希望被搬运的内容，上传前加水印是唯一跟文件走的防护，与托管方式无关。
- 盯异常。仓库的流量与提交记录偶尔看一眼，发现不认识的提交先删令牌再排查；若某张图被外站大量盗用导致转发服务限流，换名重传、旧图删除是最快的止损。
- 真在意防盗链就换路线。对象存储加 CDN 的组合里，Referer 白名单、URL 鉴权都是控制台里的现成开关，这也是图片开始有真实流量后迁移到对象存储的最硬理由。
与防盗链并列的另一面是别滥用：公共仓库和免费 CDN 是共享资源，拿它们当视频、大文件的分发渠道，触发平台规则后封掉的不只是仓库，还有你全部历史图片链接。图床就只放图，这是这条路线能长期成立的前提。
五、备份与迁移：图床的寿命管理
很多人把「文件在 GitHub 上」等同于「已经备份了」，这是误会。平台账号一旦异常、仓库被误删，云端那一份并不可靠。图床的备份其实极简单，因为它天生就是一个 git 仓库：
# 拉一份完整副本到本地或 NAS
git clone https://github.com/你的用户名/仓库名.git
# 定期增量同步即可
cd 仓库名 && git pull本地保留一份全量副本，再把重要文章里用到的图在写作工具侧留一份原图，图床数据就有了三份。对象存储路线做同样的事，是开版本控制或跨区域复制；自托管路线则是数据库和上传目录一起打包——形式不同，原则一致：图床文件必须在本机有一份不依赖任何平台的副本。
迁移的难度则完全取决于链接当初怎么设计，这也是我反复强调自有域名的原因：
- 链接是自有域名：迁移等于换回源。文件搬到新家，域名解析或 CDN 回源指过去，收尾。
- 链接是平台域名（如 jsDelivr 的 gh 地址）：迁移等于改链接。文件搬完之后，还得把每篇文章里的旧链接批量替换成新前缀，文章越多债越重。
所以即便现在用仓库方案，也建议尽早把 Pages 加自有域名这一步做掉。本节最后给一个现实的迁移触发点：单仓库体积接近平台建议上限、月访问量大到转发明显变慢、或者你开始需要防盗链之日，就是搬去对象存储之时。届时按上面两步走，一个下午足够。
六、上线前检查清单
主线搭完之后，对着这张表逐项确认再正式往文章里用：
| 检查项 | 标准 |
|---|---|
| 仓库可见性 | Public，且为图床专用仓库 |
| 令牌权限 | 只覆盖图床仓库，到期时间明确，存放在密码管理器 |
| 上传测试 | 无痕窗口能打开返回的链接，仓库内文件可见 |
| 链接前缀 | 已定死（优先自有域名，其次 jsDelivr 前缀），不再中途更换 |
| 图片预处理 | 上传前压缩开启，长边尺寸有上限，默认转 WebP 或保留高质量 JPG |
| 文件命名 | 按时间或哈希自动重命名，不使用中文与空格文件名 |
| HTTPS | 所有对外链接为 https，页面无混合内容警告 |
| 回源与刷新 | 知道缓存刷新入口在哪，接受「改图必改名」的纪律 |
| 本地备份 | 仓库已 clone 到本地并纳入自己的例行备份 |
| 防盗链预期 | 清楚本路线无 Referer 白名单；有需求则直接选对象存储路线 |
七、长期成本：免费的从来不是零成本
仓库方案账单上是零，但成本换了一种形式存在。一是配额成本：仓库体积和单文件大小都有平台红线（数值以官方文档为准），不压缩的大图几个月就能把仓库喂胖，所以压缩和尺寸上限要在第一天就打开，而不是等传不上去再补。二是维护成本：令牌轮换、偶尔的链接抽查、本地备份同步，都是小事，但漏掉任何一件，代价都以「全站图片失效」的方式结算。三是机会成本：当博客流量起来之后，公共 CDN 的速度和不可控会反过来拖累页面体验。
我的经验值是：个人博客、周更以下、单篇配图十张以内，这条路线用上几年毫无问题；一旦你开始在意加载速度、防盗链或图片总量，就按第五节的信号迁去对象存储加自有域名——那笔钱买到的是链接的永久可控。各家对象存储与 CDN 的价格和免费额度调整频繁，本文不列具体数字，下单前以厂商官方价格页现行说明为准，自己按「存储量 + 月流量 + 请求数」三项估一遍再选套餐，别被宣传页的起步价带偏。
八、常见故障速查
上传报 404 或认证失败。 十有八九是仓库名写成了完整网址（只需要「用户名/仓库名」）、分支名与实际不符，或令牌没有目标仓库的写权限。按这个顺序核对一遍配置，再重新生成令牌替换，基本能解决。
链接生成了但打不开图片。 先确认仓库是 Public；再区分是 raw 原始链接打不开还是转发链接打不开——前者多半是网络问题，后者可能是文件刚上传、CDN 尚未同步，等几分钟或用清缓存入口刷新；还要检查存储路径是否多写了一层目录，导致链接和文件实际位置对不上。
传过的图在文章里突然全挂。 先看仓库还在不在、账号状态是否正常；再看是不是自己改过仓库名或删过分支——仓库改名后旧链接会失效，这类「全挂」几乎都是链接前缀被动过，而不是图片丢了，文件还在仓库里，恢复前缀即可。
仓库越来越大、拉取变慢。 说明历史图片只进不出。先定位大文件（多半是未压缩的截图和动图），压缩替换并改名，旧文件删除；同时回头检查上传工具的压缩开关是不是被关掉了。