图床的思考

虽说简中互联网前途黯淡，但某样东西俺们大中华仍然能拿得出手，那便是数量可观的公共图片托管服务。

得益于三大运营商一手打造的网络沃土，自行搭建图床对于很多独立站长而言，已渐渐变得遥不可及。究其原因，要么受限于存储提供商波诡云谲的计费规则，要么头痛于不怀好意的盗刷小贼，要么焦虑于囊中羞涩的经济状态。生存在如今这个感人的 WEB 环境，单单是能够坚持下来更新内容就已经十分不易，还要操心这么多繁杂小事，只能说这个站长确实是不好当。

网络移民​

那么图片究竟该放在哪里？长久以来，勤劳智慧、爱好探索的简中互联网人已经总结出了无数方法。它们大致可以分为两种：放在自己家，以及放在别人家。

显然放在自己家的同志们属于最温婉的一派，愿意牺牲微不足道的金币成本来换取稳定与安全；与之对立地，如果选择“放在别人家”，则首先需要相信免费才是最贵的道理。寄生固然可能不需要花费一分一毫，但同时却需要承担可能存在的风险：或者别人家装了防盗链，或者其被拉入 GFW 而自身不保，或者其开始收费，或者发生了搬家，或者其干脆不加通知地清空我们的一切资产。将图片托管于别处，堪称机遇与风险共存，且需要为了规避风险而付出一定精力。

在很久以前，我对将图片放在 Github 这种行为嗤之以鼻，不过现在这个看法出现了很大转变。这就好比我们润到美国，对于美国公民来说，如此的合法或非法移民性质恶劣，他们的社会福利被进一步均摊给外来入侵物种、人口增多、素质拉低、环境变差；但对于润过去的人自己来说，却貌似没什么大不了的，毕竟多了我一个，问题又不是很大。同样地，将图片放到公共代码托管服务里也是如此，因为我们自己的互联网环境已经足够差劲，充斥着各种垄断以及令人费解的高压政策，最终造就了一团畸形产物，而图床对策只是它的一个附属品。因为足够令人失望的带宽价格，以及足够严格的内容审查，完全可以将这一切视为一场网络上的移民。Github 与 NPM 必然相当厌恶来自国内的专门存放图片的寄生虫们，这和刚刚提到的、现实中的移民又有何实质区别？但没办法，寄生虫们表示也很无奈。

恶性循环​

走的人多了，自然也就有了路，不过显然这个路是越走越窄。随着将 Git 用作图床的人越来越多，我们自然也遭到了此类行为的反噬：jsDelivr 备案被扬了，Vercel 也无了，rawgithubusercontent 也早被墙了，cloudflare 烂了，就连自家 Gitee 都被薅怕了。

我是想到了你能拿来做外链，但没想到能做这么多。——Gitee

点击以展开

现在只要网上出现一篇某个平台的薅羊毛教程，那么不出意外的话，在接下来的半年（甚至更短）中，那家平台肯定得炸。去年（2023）十月份左右，用 NPM 作图床的势头马上就要兴起，而时间来到现如今 2024 年的五月份，我们伟大的 NPM Mirror 就被安排上了庆余年。最终导致的后果就是 Mirror 也怕了，不过好在它是阿里系产品，即便流量被暴刷成这样，最后也只是启用了白名单机制，而非完全封闭化管理，也算是给国内开源作者留了条活路。

将代码托管服务拿来做图床，虽然在当今的环境下这个行为可以被理解，但我还是建议（尤其是 NPM 用户）尽量不要这么做。

总结篇​

只要精神不滑坡，方法总比困难多。图床道路千千万，站长轻松来玩转。下面总结一下图床方案。

典中典之 Github/NPM​

使用 Github，然后通过 jsdelivr 引用图片貌似是个不错的选择。但随着滥用现象与日俱增，加上域名备案被撤掉，现在国内部分地区已经无法正常访问 jsd 主域名；另外有可能被直接重定向至 rawgithubusercontent 网域——众所周知，它被墙了。而使用 NPM 作图床的步骤极为繁琐，且会产生大量垃圾版本，对空间的浪费令人发指，虽说最终仍然可通过 jsdelivr 的几个加速域名访问，但这是彻底的滥用，故不推荐。

自家羊毛之国产 Gitee​

这条路已经走不通了。现在，Gitee 具备外链流量监控机制。一旦发现流量存在异常，就会执行仓检，如果恰好发现仓库中存着一堆图片，那么你将会喜提强制修改为私有可见性大礼包，且无法再将仓库从私有变为公有——除非删除所有存疑图片，然后提交人工审核。

另辟蹊径之AzureDevOps​

参见此文章。这玩应也是 Git，只不过是微软 Azure 版本。已知微软近期还更换了一波 DevOps 的域名，从原本的 visualstudio.com 改为 dev.azure.com，鸟枪换炮升级成了泛播，速度有所提高，但 max-age 只有区区可怜的 60，且仅支持常见的内容类型，其余均会返回 Content-Type: text/plain。除此之外，后台会记录每一次单独的外链 API 调用，因为显然这个并不是真正纯粹的直链获取。如果你将它用作生产环境图库，那么会在后台见到非常恐怖的日志量。

饭来张口之大厂平台​

现在 99% 的大厂都有防盗链了，不过大家也应该知道——非常好破解，要么页面全局加个 meta 标签，要么批处理所有 img 元素。

拿大厂当图床是绝对的强盗，不过也仅局限在个人非商业用途。事实上我认为大厂图床是最好的解决方案，咱们可以这么想：这些存储服务原本就是为大厂社交平台设计的，这些平台是干啥的？基本都是拿来给大家分享生活或者无聊事情的，基本都是私人用途，也就是说他们的图床里面放的几乎全部是私人图片。比如我们平日里见到的公众号，有很多都是个人或者微不足道的组织在坚持运营，一篇文章里的图片大概率未经压缩，体积动辄高达数 MB，而最后一看...

类似这样的“自说自话”平台还有很多，例如 QQ 空间、微信公众号、百度贴吧、百度百家号、知乎和豆瓣这种。其中我个人觉得 QQ 空间和微信公众号素材库是最稳定的，至少在未来的十五年里不会出事；至于百度系的话，悲观估计也至少还有十年可活。作为他们的用户，上传图片当然包含在用户权益以内，从而规避了道德顾虑。

乱入之 Steam 截图​

这是什么人才想出来的方法，Steam 都能拿来当图床，不过如果域名是 steamcommunity 那还是算了。

此方法甚至还有一个专门的软件。

随缘之自营图床​

不推荐使用任何公共自营图床，无论是免费还是收费。以我多年对一众图床的观测而言，是真的无法预知它什么时候会跑路、什么时候会收费、什么时候会换域名、什么时候会切换到国外，以及什么时候会崩溃，伴随而来的还有不少图床那感人的延迟。而且据我所知，很多图床的运营者甚至还在上初中，或者高中。

投机之各家云盘​

关于云盘引外链，一是服务商能够直接提供链接（如 Onedrive），二是通过第三方或自建程序解析直链。前者能做到的大概也只有 Onedrive，后者则要消耗服务器资源，尤其是请求量比较大的时候，典型的程序如 Alist、OneIndex、ondrive-vercel-index 等等。此种方法由于要在中转解析节点上花费一丢丢时间，然后 302 到图片的真实链接，所以实际延迟（如果存储商在国内如天翼云，则还好）稍高。而对于 Onedrive 而言，人家本来是网盘，所以直链所获取到的图片的缓存策略有点辣眼睛，于是需要频繁取。另外，外链流量也是被监控的，不过微软的政策很宽，再加上图片本身消耗不了多少流量，所以很难引起注意。

老实人之对象存储​

自己动手，丰衣足食，没错——高贵的 ObjectStorage 爷，敢于自掏腰包直面流量账单，这种勇气与担当难能可贵且值得嘉奖。广告哥用着不知道哪里来的杂七杂八跑路云，不差钱的爷直接上华为或者阿里云，外币爷说我选择原生 Amazon S3 甚至 Oracle；小资和中产有自己的良心腾讯云，穷鬼有自己的 Cloudflare，再不济可以选择屈身加入又拍云联盟，大家都有光明的未来。

乱七八糟之剑走偏锋​

经典歪门邪道包括所谓 IPFS“无审计无来源”图床，以及同样依赖 Cloudflare 的 Telegraph，不过后者如果托管域可靠，那么实际速度还是理想的，毕竟泛播。还有一个平台叫做 Coding，类似的还有语雀，不过也都已经凉透了。

另外还有缓存代理方案，参见此文章，专门用于针对防盗链，想必大伙也已经很熟悉了。

梦游之本地存储​

什么？把图片放在服务器本地？