痛点：被老版本折腾得实在受不了了
老版本的Inari我已经不想再打开了。它自从上次我急急忙忙为了应付一个临时的需求，硬塞进去一个“快速索引”功能之后，整个系统就彻底成了个半瘫痪状态。大家也知道，我这个Inari主要是用来帮我整理那些东一个西一个的个人学习资料和记录的，但它现在是真慢。慢到什么程度？
只要我往那个特定的资料文件夹里扔进去超过五十个新文件，它就得给我卡顿半分钟，然后，还不是一次就成功。经常是我看着它界面上的进度条慢慢爬，爬到一半，啪，直接给我报个错，说内存不够。我一个本地同步和分类的小工具，居然能把我的16G内存给吃光？这简直是折磨。我本来是想省事儿，结果每次用它，我都要花更多的时间去善后，收拾它留下的那一堆烂摊子。
所以这回我是真下定决心了，必须把这个核心的索引逻辑给彻底砸烂重来。不然我以后每做一次季度整理，就得提前喝三杯咖啡，做好跟它大战三百回合的准备。
决定动手：从砸烂重来到搭积木
我坐下来，盯着那几千行我几个月前写的屎山代码，思考了一个晚上。我发现问题的根源不在于我处理文件时用什么算法，而在于我处理文件的方式太“老实”了。它每次都像个老学究一样，非要等前面的文件全部处理完，拿到最终结果了，才开始看下一个。这在文件少的时候没事，一旦文件多起来，它就得死等。
这回我学乖了，我决定把索引这活儿，拆成两个完全独立的模块来干。一个模块，就负责在后台偷偷摸摸地盯着文件夹，只要有文件进来，它就赶紧记个小本本，记录下来“有新东西了，但还没处理”。另一个模块，才是负责处理那些文件。
具体来说，我把以前那个一步到位的大函数，拆成了三个小服务：
- 监控服务（Watcher）：专门用一个轻量级的东西去“监听”目录变化，只记录路径和时间戳。这玩意儿跑起来跟蚊子一样，几乎不占资源。
- 队列服务（Queue）：把Watcher发现的新变化，按顺序排队，哪怕同时进来一万个文件，也只是往队列里扔一万个小小的指令。
- 执行服务（Worker）：这才是真正干活的，它从队列里一个一个取任务出来，提取元数据，做分类，写数据库。而且我限制它一次只能同时处理五个任务。如果其中一个失败了，也不影响其他的继续跑。
这样一来，就算我一口气扔进去一千个G的文件，界面也不会卡死了，因为所有的重活累活都扔到后台去了。这中间，我光是为了搞定那个跨平台的文件夹监控组件，就折腾了快四天。主要是Mac和Windows对文件事件的处理逻辑完全不一样，我必须得让它在两个系统上都跑得稳当。
实践记录：这回更新到底折腾了哪些地方
我把所有实现过程都记录了下来，主要做了以下几个大的调整：
是狠狠地优化了数据库写入。以前我用的是默认的同步写入模式，每存一个文件信息，数据库都要锁一下，导致并发写入时效率低得吓人。我直接把写入模式改成了异步批量写入。啥意思？就是我先在内存里攒够一百条记录，然后“嘭”一下，一次性写进数据库。这个改动直接让我的索引速度提高了将近八倍。
把UI的反馈机制彻底改了。老版本在索引时，UI是跟着主线程一起锁死的，假装自己很努力。新版本里，我让后台Worker每完成一个任务，就发一个小信号给前端，前端只负责根据这个小信号，更新一下那个小小的进度条数字。用户体验直接拉满，看着进度条一点点前进，心里踏实多了。
我花了一整天时间，把配置文件和数据库的路径管理给理顺了。以前每次换电脑或者重装系统，我都要手动去改几个配置文件，不然Inari就找不到它的老家了。这回我统一用了一个相对路径加系统环境变量的方式去定位，只要你告诉我你在哪个盘，它自己就能找到所有需要的东西。这个过程虽然无聊，但是为我未来跨设备使用省下了大麻烦。
为了测试新架构的稳定性，我找了以前那批能把老版本弄崩溃的文件，一股脑全扔了进去。我设置了一个压力测试，让它连续跑了五个小时，不停地添加、删除、修改文件。
结果：跑起来一看，值了！
五个小时后，我回来一看，系统稳稳当当的，内存占用基本稳定在几百兆，CPU也只是偶尔跳一下。那个以前让我头疼的索引任务，现在扔进去一堆新文件，不到十秒钟，它们就被后台 Worker 接走了，界面全程流畅，一点卡顿的感觉都没有。
我不得不说，虽然这回更新日志只是薄薄的一篇，但这背后是整整两周每天熬到凌晨一点的成果。砸烂重来是痛苦的，但看着它高效稳定地跑起来，那感觉比什么都强。这下好了，我的个人资料库终于又回到了那个自动、流畅、不用我操心维护的状态了。下次再更新，我可能会考虑给它加一个简单的网页管理端，但那又是另外一个故事了。先让我享受几天这个稳定版本！