要不要用个图床

昨天我的一篇Post，使用了几张图片。是avif格式的。这样好在体积比较小。虽然是新的格式，但也只是IE和几个RSS阅读器支持缺失，主流浏览器支持良好。

我这个站点，如读者所见，没什么图片的，以文字为主。需求的图片不多。把图片和文章放在一起，使用的时候比较方便，迁移起来也不难。而且不用担心图床的可靠性带来的问题。

至于如果以后有大规模的图床需求，该如何做。当然是专门的事情专门完成。如果有这样的需求的话，我可能会购买储存服务，或者找一个图床管理器，用于在本地与图床之间同步文件，转换链接以及在图床和图床之间迁移。总之，此处存放一点，彼处存放一点，后果肯定是灾难性的。

基于SSG的，以Markdown等轻量标记语言为中心的站点，优点就在于可迁移。如果有朝一日我对Docusaurus觉得不满，想要迁移到其他的SSG，仅复制内容目录，最多对某些专用语法手动或批量加以修改，即可便捷地迁移到另一个平台。然而依靠图床，就不得不解决服务器上的链接与本地备份的统一性。

之前发现了PicGo，但我觉得它很别扭。如果不内置强大的迁移功能，只作为上传器，用途是有限的，没有命中图床用户的核心痛点。图床在意迁移，一是因为上传细水长流，写一篇传一点图片，但需要迁移的时候，势必有大量积攒下来的图片需要改动。二是因为图床服务（正式的或者非正式的）经常朝三暮四、篡改删除，修复禁用等，可靠性和可用性都不能保障的情况下，管理工具不在平时，而在万一。

因此，一个图床工具着力解决的应该是本地图片的批量上传、图片链接管理、文章链接迁移、远程图片下载和重新上传等一系列问题，而不是作为一个上传器，让用户少使用图床提供的网页或者命令行工具。虽然眼下PicGo正在为了可迁移性而努力，但就其原型设计的硬伤而言，其可迁移性的补救可能需要很长一段时间完成。

一个有用的图床管理工具应该可以做到把整个网站的所有文章的本地图片一下子传到图床上。所以我宁愿先让我的图片占满我的储存空间再说。事实上截至目前，这个网站在GitHub上占据的空间，含图片在内不到1MB。因此我还远远没有到要为图床而担心的程度。

等到有必要解决图床问题时，我大概率会转向付费购买服务，或者自己实现一个简易的批量迁移和管理工具。