一、缘起：我受够了文章里的图一条条变灰

写博客、记笔记、发帖子，图片放哪儿一直是个烦人的问题：

• 丢到某个免费图床，过两年图床跑路，文章里全是裂图；

• 丢进自己的对象存储，要花钱、要备案、还要管密钥；

• 只用一家图床，它清库你图就没了；想用多家，又得记住哪张图传到了哪家。

后来看到 NiuBi 图床 这类「多接口聚合 + 302 智能中转」的玩法，思路一下就通了：

本站不存图，只存"这张图在哪些地方"这份索引；对外永远只发自己域名下的一个链接，哪个源挂了就换下一个。

换句话说，我做的不是图床，而是一堆图床之上的"套利层"：空间用别人的，容灾和索引归自己。

于是有了这个小项目 —— niubi-imgbed。它跑起来只有一个 Python 进程加一个 SQLite 文件，没有 Redis、没有消息队列、没有前端构建，却能做到：图片秒传、多源并发分发、单源失效自动切换、引用链接长期有效。

二、它长什么样

技术栈朴素得有点过分：

Python 3.14 + FastAPI + SQLite  +  原生 HTML/CSS/JS（无 npm、无 webpack）

整个项目（含前端、含测试）不到 9000 行，app/ 目录约 6500 行，main.py 里 38 个路由。

三、核心设计：为什么"不存图"反而更可靠

1. 本站只做索引，不做仓库

图片字节流从来不落在自己服务器上，本站只保存三样东西：

• images 表：这张图的元信息（slug、文件名、SHA256、归属用户、浏览数）；

• sources 表：这张图在每个第三方上的真实直链、健康状态、失败次数；

• data/niubi.db：唯一的数据源，备份就是拷这一个文件。

磁盘占用几乎为零，也就不用担心"自建图床把自己硬盘塞满"。

2. 一张图，多个源

上传时把同一张图并发推给多个接口。某个接口抽风、超时、限流，都不影响整体结果 —— 只要有一个成功，图就有地方待着。源越多，链接的预期寿命越长。

3. 对外只发一个链接

无论这张图最终存在 catbox、缤纷云 S3 还是 B 站图床，我给出去的永远是：

https://你的域名/i/7uwgtuir

访问它时，服务端现场决定 302 跳到哪个真实直链

仓库地址

https://github.com/clover1420/lstc