图床 | Liang‘s Blog

type

status

date

slug

summary

图床是什么

图床就是，把自己的图片上传到网络（服务器），直接使用网址链接访问图片，很多网络上的图片放在一个地方，取名字叫做图床。

图床实现拿到链接就可以访问图片，不需要本地存储就可以访问图片，其优势在于：

解决了图片该如何传输

解决 Markdown 的图片痛点

几乎不占用文件体积（只保存链接的大小，而非图片本身大小）

图床能做什么

图床，可以实现用 Markdown 语法格式插入图片，与他人分享时，免去图片传输的痛点。只需要有网络，拿到图片链接，便可以访问。

当然，图床除了写 Markdown 文档外，只要是能打开链接的地方，都可以使用。比如说，在某某社交网站评论时，就可以使用图床里的图片链接。

如何使用图床

要使用图床，那么需要解决三个问题，上传网络的服务器，快捷上传图片的应用，编辑器支持图床服务。

上传图片的服务器

要使用图床，首先要解决的就是图片该上传到哪里，目前（2024）有不少免费公益的图床服务，这也是不是新手入门图床的首选，毕竟谁不希望白嫖。不过，免费公益的图床，稳定性和可持续性非常的不确定，很有可能在未来的某一天，服务停止了，其后果将造成曾经上传到这个图床服务的图片全部失效。

那么有没有相对来说更加稳定的图床方案呢？当然是有的，那就是钞能力，不错就是付费图床服务，关于付费图床，有许多方案，主流的有各大云服务厂商提供的 OSS 对象存储服务、VPS 自建图床服务器等。

本篇博文写于 2024 年，为了便于入门图床，采用免费公益图床服务，目前来说相对比较稳定的免费公益图床服务有：

smms：https://smms.app/

图壳图床：https://imgkr.com/

路过图床：https://imgse.com/

聚合图床：https://www.superbed.cn/

快捷上传图片的应用

有了上传图片的服务器，即图床，那么总不能每要上传一张图片，就要打开上传服务器网站上传吧，如此繁琐重复的操作，就需要有一款应用，能够对接上传服务器和本地图片。这就是为什么需要快捷上传图片的应用。常用的快捷上传图片应用有 PicGo、iPic、、Picsee、uPic等。

由于博主的主力使用 Apple 生态的软硬件，故使用的是 uPic。uPic 对 Mac 的支持非常好，直接在应用商店下载即可，不仅有 Mac 端的 APP ，还有 iOS 端的 APP。

编辑器支持图床服务

有了图床服务器和快捷上传的应用，理论上已经完全 OK 了，不过要是编辑器能够对图床服务进行优化，那么就皆大欢喜了。

博主常用的 Typora，就支持一键将本地图片通过快捷上传应用，上传到图床服务器，并自动替换本地图片成网络图片链接。

图床的弊端

图床虽好，仍有弊端，甚至于这个弊端是你所不能够接受的。图床的弊端归纳为三个字就是——稳定性。当然这个弊端可以通过钞能力解决。

将图片上传到网络，需要网络服务器，那么就有两条路选，一是公益图床，二是付费图床。

若是选择公益图床，即便是稳定运行了很久的公益图床，公益的没有收入，只有云服务的支出，跑路的风险极大，一旦跑路，那么以前写过的文章图片，便会全部丢失，此时要恢复，只能一个个替换链接，要写脚本批处理也不好实现，一个个换……非常劝退人。

若是选择付费图床，一十面对琳琅满目的云服务厂商推出的服务，选择的空间大了，选择的成本也大了，同时即便是知名的云服务厂商，也存在未来关闭所提供的云服务和倒闭的风险，即便风险相对公益图床小，但不能否认其存在。当然要追求极致的零风险，是不可能，这点算是在可控范围内可以忽略。二是费用，我只是存个图片，就要花那么多钱，实在是心疼啊，按照正常的写博文和笔记来计算，用云服务商的 OSS 存储大致 50 ￥每年，且随着存储空间的增大，每年的费用也会增大，这种增长架势，后期的费用会非常吓人，一旦付费中止了，便不能再使用了，这实在是难为情了。

我的图床使用心得

上述博主探讨了图床是什么、能做什么、如何使用、弊端。接下来，博主要分享自己使用图床的心得，从中你可以收获，博主是如何最大化图床的优势及规避图床的弊端。这一套心得可以与博主的笔记系统文章一起看，会有不一样的收获。

博主使用图床的最重要原因是在本地写好 Markdown 文档后，需要进一步的迁移到博客里，图片的传输就成了大难题。而且有时候，博主也会直接分享 md 文件给他人，此时图片的传输也成了大问题，还有博主会云同步笔记和博文，同步的 APP 端可以预览文件，此时如果是本地图片的便会无法显示。为解决上面的 3 个痛点，博主便将矛头指向了图床。

在博主真正开始使用图床前，有 3 点要求，一博主的 MacBook 本地一定是使用本地图片；二博主只有在需要的时候上传图片到图床；三博主的图床需求，分为短期和长期。

博主的要求一是为了，确保图片一定会留下，而不依赖于图床服务器（这点可以通过博主的笔记系统了解博主的笔记存储和同步逻辑体会为什么）。要求二是同样是为了要求一服务，在需要分享时才上传，不需要时就用本地图片，这样不仅可以节约图床服务器资源，也可以大大提高图片访问效率。要求三是为了规避图床的稳定性，需要长期存储的图片上传到付费相对稳定的图床，而只需要短期分享和使用的就上传到免费的公益图床，反正后面就不用了，失效了，也不知道。

展望未来（2024 视角）

博主在写这篇博文时，收集资料意外发现了，一个新的解决 Markdown 图片传输问题的方案。此方案就是将 md 文件和图片打包成一个新的文件格式TextBundle，通过这种方案传输，确实解决了 Markdown 图片的痛点，缺陷就是占用文件体积吧，和 Word 等格式一样，将图片打包在一起。当然就现在来说，最大的缺陷是——未普及。主流编辑器很少支持这种格式，基本都是支持 md 文件格式。不过这个解决方案，倒是一个不错的图片解决方案，它不能替代图床，但在解决 Markdown 图片问题上，倒是在本地和文件传输方面，以及稳定性上优于图床。

最后，完美的稳定是不存在的，博主的观点，追求 5 年、10 年以内的稳定就可以了，未来不可知，谁又会知道未来 10 年后，会不会出现新的解决方案，或者你的笔记博文已经过时，图片失灵只是在提醒你需要更新了，别落伍了。

💡

欢迎您在底部评论区留言（评论区可选是否登录及匿名），一起交流~