本文最后修改于 132 天前，部分内容可能已经过时！

合久必分，分久必合，螺旋式上升，ALL IN和单点之争同样如此，当单个应用功能单一时，人们就想在一个超级应用里完成所有的事情，直到它不满足，这个时候才会另外新创单点应用，如此反复

希望仅仅使用一款工具，就可以满足我所有的知识管理需要
追求一款ALL IN ONE的工具
这本质上是一种懒惰，寄希望于毕其功于一役，总是显得有些心急，然而正是这样的一种懒惰，在一定程度上推动了科技的进步和发展

其实就像
功利性导向没有问题，就像，有些东西就是需要好用的高质量产品，而有些只需要满足我最简单的需求求便宜即可
也不是非得每一个都精心的去分类
偶尔的错误也都并不是什么大过错

对于安全感不够的我来说，我无法信任无法离线运行的笔记软件，也无法信任完全存在云端的软件，并且不信任私有化的格式
一旦平台或服务商倒闭或要进行搬迁数据，对于其影响特别的大
对于我来说，我不信任无法脱机运作的笔记软件，也不信任无法导出通用文档格式的笔记软件，并且，响应速度也是考虑的重点

通用的文件格式
可导出（至少是付费后可导出）

部署在虚拟机 又担心电脑没开着没联网 无法在手机端连接进行处理
部署在网络上 又担心没网的时候无法进行处理

我到底是要多端的同步呢 多端的同步一定是会有隐私泄露的风险存在的
还是要它仅仅在单机上可用呢 也会有，但概率更加的小
这个问题一直纠结着我

在云端服务器和自建NAS之间也有存在几个问题

云端服务器基本可以做到99.99%的在线，在隐私安全方面有所保证（基于规则的被执行），可以24小时在线
而自建NAS却无法保证电力的持续供应，如突发断电等原因就变得不可用，但隐私性最强

所以我确实是需要一个服务器的

自己开发的优势是什么
使用别人的劣势是什么

如果该收支属于一个特别的事件，那么就将其加入这个事件对应的单独文件，例如#2019-07-Europe-Trip。
如果该收支是一个周期项目，但跟某个银行账户无关，则加入按类别划分的文件，例如水电费、房租、工资。
如果该收支跟某个银行账户紧密相关，则加入该账户对应的文化，例如银行手续费、信用卡还款、返现。
不属于以上情况，则加入按日期划分的文件。
以上就是我目前对账本管理的一些经验之谈，这些方法只是为了达成我前面提到的三个目的：减少错误的可能，降低维护成本，节约注意力资源。如果之后我发现了更好的划分方式，我会对账本重构，到时候再来更新这篇文章。

https://forum-zh.obsidian.md/t/topic/20383/4

有人问，半夜饿了，要不要吃东西
饿了就去吃，就这么简单
很多人会拿出来 延迟满足这个来说明人的发展
可能以前的我也会