fix.尝试修复内存溢出问题

[wuyu8512]

暂时怀疑是计算时间引起的，去掉观察一阵子先

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	de8cc7c
Status:	✅  Deploy successful!
Preview URL:	https://6c38f181.web-9q6.pages.dev
Branch Preview URL:	https://fix-memory.web-9q6.pages.dev

View logs

[Inori-Lover]

问题描述：

1. 进书架列表页之后随意切换数个分页，然后任意分页下停留，打开 chrome 的性能监控，内存快照一次
2. 爱干嘛干嘛，10分钟后回来
3. 可看见当前内存占用对比10分钟之前显著上涨（可翻3到5倍不等，约20M->100M的幅度）
4. 再次快照，shallow size倒叙，可看到大量C开头的变量hold住了指向pr中被注释的代码（vue中某个压缩后命名为C的class，看起来像是什么effect之类的东西），更具体是deps下hold住

怀疑：

1. 闭包持续被computed持有且因为某些原因没有被销毁
2. luxon大量创建后销毁，造成GC压力

[Inori-Lover]

close #187

[Inori-Lover]

最简单的解释是：一个reactive类对象（包括不限于ref/computed/watch等），会独立于组件生命周期产生/消亡时，vue就没法在其它reactive对象的dep里移除它，导致不断产生新的computed对象又不断塞进其它对象的dep数组里，且再也无法从外部清除：它只存在于其它对象的dep里。

经验：

1. compose api（包括抽象出来的各种hook，vue叫compose）应该静态或在setup顶层创建、调用
2. 优先考虑使用 shallowRef，形如ref(dayjs())/ref(fetchInstance())的代码会让ref浪费许多时间去给对象挂上监听器同时还可能让该对象被修改导致无法使用（比如three.js进ref就会死掉）
3. 遇到需要入参拿响应值的场景，优先使用getter，有效避免强制用户调用函数时创建ref（也就变相鼓励用户动态创建ref了

[Inori-Lover]

虽然还是觉得compose api不能compose这个就很搞笑就是了，我怎么知道别人在composeFn里用没用ref…