laoyang
06e6e3798a
名册加内存缓存 + 编辑框自己拉一份 (#92)
用户 2026-11-05：「速度比较慢。刚点开的时候显示的是『成员 #1、成员 #3』
这样的样式，是不是因为没读到人的信息？」
是。占位项（`成员 #id`）就是 roster 还没到位时的兜底。
**慢的真因**：`FbPersonRepo.list()` 是**全表查询**
（800 人 + JOIN person_roster + 标签 GROUP_CONCAT 子查询），
而每个用到选人的组件都在首次打开时各自调一次 ——
首页、任务面板、观影、旅程、资源、账本…逐个来一遍，
同一份数据反复查、反复解析。
① FbPersonRepo 加内存缓存（5 分钟）
· 缓存**只对整表查询**有意义；带关键词时在内存里过滤（同一份 `matches` 口径，
行为与"查库再过滤"完全一致，且更快）。
· 缓存的是**同一份数组引用**：调用方都只读不改（现有代码符合），
不做深拷贝（拷 800 个对象本身就不便宜）。
· 新增 `FbPersonRepo.invalidate()`。
② 同步完成后失效
`FbSyncAll` 收尾时，只要这次不是"全部跳过"，就 `FbPersonRepo.invalidate()`。
⚠️ 不清的话：用户改了头像/名字、同步完再点开还是旧的那份，要等 5 分钟过期。
⚠️ 只在 "skipped < total" 时清：全部跳过说明服务端没变，缓存本身有效。
③ 编辑框自己也在 aboutToAppear 里要一份
父页面（首页）的 `dayRoster` 是异步加载的，点开那一瞬可能还是空。
⇒ 组件自己调 `list()`（有缓存时是**瞬时返回**），
查找时"先查自己那份、再查父页面传的"。
这样占位项一闪而过甚至看不到。
⚠️ 两份合并而不是只认一份：父页面可能后到（`@Param` 变化会重画），
组件自己拉的也可能失败（那就靠父页面的）。
编译通过，已装真机。
2026-11-05 21:01:28 +08:00
..
2026-11-05 21:01:28 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00