自建图床的方案思考以及搭建教程

前言

现在markdown越来越受欢迎，但是markdown有一个很麻烦而且一直很难解决的问题就是文章中图片资源的处理。

不像word、pdf这种将图片内嵌在文件中，markdown只能引用外部的图片资源，这意味着要么在本地弄一个文件夹专门用来存放图片，通过相对路径引用；要么将图片存放在网上，通过图片链接引用。

如果存放本地以相对路径作为引用的方案，那么传播文档时还要将资源文件进行打包，并且以后想要发表到其他站点，就要考虑如何将这些本地文件转换成网络资源。除非是自用做做笔记，并且是纯本地模式使用，否则这种方案会很麻烦。

所以我个人更倾向于将图片存放在网上引用图片链接的形式，也就是所谓的图床。

但是使用图床也带来了很多的问题。

如果使用免费的图床，以后跑路了怎么办？如果使用GitHub、Gitee这类公共仓库，GitHub的网络稳定性是一个问题，而Gitee后来的审核政策导致图床无法使用也是一个问题。

而使用付费的图床，像是阿里的OSS、腾讯的COS等，万一被刷了，如果没有及时发现，可能一套房就被刷进去了。

图床的易用性也是一个问题，比如使用GitHub当图床，那么就需要在GitHub网页上上传图片，然后点开raw链接，或者在本地提交，然后push到仓库。这在我看来还是稍显麻烦的，不那么优雅。不过还好PC/Mac端有对应的工具，我也没有在移动端写markdown的需求，所以易用性倒是挺容易解决。

所以我思考了一些图床的方案，写下了这篇文章。

当然，我也没有想到一种可以既要又要还要的完美方案，每一种方案都有各自的局限性，只能是根据各种方案的优缺点，以及自身的需求做好取舍，选择一种最适合的方案。

另外，我希望数据是掌握在我自己手中的，所以文中没有列举公共免费图床的方案，这种直接网上一搜就有一大堆，该文章就不赘述了。

好了，废话不多说，接下来我将直接列出各个方案的组合及其优缺点，以供快速参考，不过在这之前先解释一下表格中各个方案的属性表示的含义。

属性解释

成本

就是正常情况下，维持这个图床所需要花的钱。

成本可控

是否会有意外因素，导致成本飙升。比如单OSS方案，可能会被刷流量，导致面临巨额账单。

隐私性

图床中的图片是否全部暴漏在公网中。比如使用GitHub作为图床，图床中的图片几乎是完全暴漏的，不能上传隐私性的图片。

网络稳定性

图片下载的速度。使用国内OSS方案，下载速度比较高，网络稳定性好；而像GitHub图床，由于不可抗力，普通用户无法访问。

是否需要域名

顾名思义，就是是否需要购买一个域名。普通的域名其实很便宜了，需要注意的是购买的时候要注意下续费价格，有些域名可能首年只要几块钱，续费价格很贵。

可迁移性

将一个图床的数据迁移到另一个图床，原来的图片链接是否仍然可访问。

举个例子，我以前使用过Gitee做图床，md文件中直接通过Gitee的域名进行引用，后面政策变更导致无法访问，以前的图片链接全部失效。

如果对可迁移性有要求，那就必须要申请域名，并且做一层路由转发。

举个例子：

原先使用Github作为图床，原图片链接形如：http://raw.github.com/user/repo/b.png；

但是实际md中引用的自己的域名：http://img-gh.flycat.tech/user/repo/b.png。

使用了反代将 img-gh.flycat.tech转发到 raw.github.com而不是直接访问原链接。

如果以后GitHub政策也变更，那只要将GitHub中的repo整个clone下来，然后上传到oss，再将 img-gh.flycat.tech/user/repo路由到对应的桶就行了，这样原来的图片链接仍然能够访问。

备案要求

是否需要备案。国内备案大概需要1~20天左右，周期会比较长，所以也是一个需要考虑的因素。

方案比较

组合	成本	成本可控性	隐私性	网络稳定性	是否需要域名	可迁移性	备案要求
GitHub	无	可控	低	低	否	不可迁移	否
GitHub+域名+Cloudflare	低	可控	低	中	是	可迁移	否
GitHub+域名+Cloudflare+VPS	高	可控	低	中	是	可迁移	否
OSS	低	不可控	高	高	否	不可迁移	否
OSS+域名	低	不可控	高	高	是	可迁移	是
OSS+域名+CDN	低	可控	高	高	是	可迁移	是
OSS+域名+同机房服务器	中	可控	高	中	是	可迁移	是
自建图床	中	可控	高	中	是	可迁移	是

搭建教程地址：https://blog.flycat.tech/archives/self-built-image-hosting-scheme-tutorial