某一天你打开自己的博客，发现所有的随机配图变成了一个个刺眼的裂图图标——欸，那你就知道网站出问题了。但排查半天，你发现网站本身好好的，但是图源挂了或者限流了，于是所有使用的图片集体失效，最终只能换一个或者老实等待恢复。

（好吧说的就是我自己）

在先后换了一些随机图片API后（其实是懒得换默认API结果被背刺了不得不换），我选择自己搭一套随机图片 API。

这套 API 就是 MoeRNG，我自己的实例跑在 https://images.grabrun.top/ 上。它一开始只是为了解决博客配图和背景图轮换的问题，后来慢慢长成了一个相对完整的自托管随机图服务。这篇文章就聊聊 MoeRNG 的巴拉巴拉。

简单介绍

（啊哈哈广告来喽）

随机图片的底层逻辑其实很简单：从一组图片中随机挑一张，返回。既然这么简单，那肯定自建啊（bushi）。

然后……就是……写着写着，各种想法开始冒出来，什么限流啊、 json / 302 重定向 双模式啊、对象存储啊，统统实现！

（终究还是走上其他 API 的路了吗？）

于是截至文章发布， MoeRNG 变成了：

• 真随机取图。 数据库级 ORDER BY RAND()，每次请求独立取图，不做缓存、不排队，避免“随机”变成“按顺序轮播”。这一点对背景图和特色图轮换很重要（应该没人用随机API想每次刷新都看到同一张图把）。
• 多级分类。 分类可以无限嵌套，指定父分类时子分类也会参与随机。意味着可以按页面类型分开取图：文章头图一个分类，侧边栏一个分类，全站背景又是一个分类，而不是所有图片混在一起随机，当然你也可以当作一个简单的图片分类。
• 双模式返回。 既支持 JSON 结构化返回，也支持直接 302 重定向到图片。302 模式简化前端开发，后端变更对页面完全兼容。我的博客里大量地方就是直接拿 https://images.grabrun.top/ 当图片地址用的。
• 速率限制。 用令牌桶算法限流，剩余额度通过响应头返回，避免接口被刷爆。虽然是自建服务，但其实已经开放在公网上了（欢迎大家合理使用！），也要考虑被滥用的可能。
• 多存储实例。 本地存储和多家对象存储官方 SDK 接入，支持签名直链和 CDN 加速。图片不一定非要放在博客服务器上，对象存储加 CDN 的组合对小服务器更友好。
• 轻量核心。 零重型框架，API 平均响应时间低。对于随机图片这种高频小请求，API 响应时间尤为重要。

对我来说，MoeRNG 最大的价值不是“随机”本身，而是把图片来源的控制权收回到自己手里。图片裂开时，我不需要对着第三方接口的 404 束手无策；想换一批图，只需要往存储里丢新文件；想给不同页面配不同风格的随机图，加一层分类或参数就能做到。

为什么我最后选了自建API

回过头看，自建 MoeRNG 这件事的核心价值，不仅仅是“随机”这个效果本身，而是把图片来源的控制权收回到自己手里。图片裂开时，你不再需要对着第三方接口的 404 / 429 束手无策；想换一批图，也只需要往存储里丢新文件；想给不同页面配不同风格的随机图，加一层分类或参数就能做到。

如果你只是想解决裂图和随机配图问题，不必一上来就把 MoeRNG 的所有功能都用满。先把实例跑起来，让裂图位置和背景图指向 https://images.grabrun.top/ 这样的固定地址，确认页面稳定不裂；等需求长出来了，再慢慢叠加分类、限流和对象存储。随机是手段，可控才是目的。 而 MoeRNG，只是恰好把这两件事同时实现了而已。