今天也在 GitHub 搜 Koishi，搜到了这个，看起来也不是官方发的，但是感觉好好玩，就转载过来了。
然后我感觉这篇文章里讲的东西有很多其实是不合理或者难以实现的，所以只是图一乐。
前言
如果你在 Koishi 开发群内看到群友激烈争论某些问题持续时间长达数个小时，请不要担心，这是 Koishi 群的风俗。观战的人们将此类行为总结为《Koishi 人》，这当然不是什么赞扬——
事实上，对于刚入群的新人，几乎难以理解这些人们在谈论什么。这是因为 Koishi 的开发者们自己对于插件开发有着一套独特的黑话哲学。而这其中的几乎每一条都是难以实现的。大家也不知道为什么要追求这些。
不过总之，让我们看看到底有哪些 Koishi 哲学吧。
目录
- 可逆的 Koishi
- 正交的 Koishi
- 零状态的 Koishi
- 零占用的 Koishi
- 0dt 的 Koishi
- ？？的 Koishi
- ？？的 Koishi
- ？？的 Koishi
目前暂定每层介绍一个，未来可能也会单独发帖以扩充内容。
（打问号的先不写了，希望未来有机会介绍吧。）
3 个赞
支持传播 Koishi 的制度自信
4 个赞
一、定义
0dt 即 zero downtime，具体指 一个 Koishi 实例在持续运行的过程中发生可控的重启，重启期间 Koishi 可以保持工作。这里仅针对持续运行的 Koishi 展开讨论，不考虑云服务等情况（可前往「零状态」章节查看）。
其中「可控的重启」包括：
- 定时重启
- shutdown 指令调用
- 全局配置重载
- 滚动更新
- 发生足以破坏掉进程的严重故障
「Koishi 保持工作」包括：
- 不会错过任何请求
- 不会丢失任何插件的运行状态
二、设计动机
三、生态现状
四、实现原理
五、对比
5.1 0dt 与可逆
可逆并未实现 0dt，但热更新最大限度地减少了用户在生产环境下的重启次数，客观上增加了 SLA。
5.2 0dt 与零状态
零状态的 Koishi 自然实现了 0dt 所要求的「不会丢失任何插件的运行状态」。但后者也可以通过其他方式实现。
5.3 0dt 与零占用
由于两个 Koishi 实例的生命周期存在重合，因此 0dt 本身也会对零占用有所需求。
3 个赞