本地资源库加载速度优化

1
 我实现了「批量 scan_token 更新」优化：把扫描时每个未变文件的单独 UPDATE（2297 次）合并成少量批量
2
 UPDATE … WHERE id IN (…)。验证确实有效——1200 个文件的扫描从数秒降到约 250ms。
3

4
 但该改动在 Windows 上引入了测试套件的间歇性不稳定：
5

6
 - go test ./local_library/ 随机在某个测试的临时目录清理时报 library.db / photo.jpg
7
   被占用（文件句柄竞态），失败率约 20%；而改动前基线 7/7 全绿。
8
 - 我做了大量排查（goroutine dump、批量大小 A/B：1/50/200/400、专门的创建/关闭压力测试 120 轮），
9
   未能精确定位竞态，也无法找到一个「既保留提速又不引发竞态」的批量粒度。
10

11
 决策：为保证测试套件和发布流程稳定，已回退该提速改动。保留的是更早的、
12
 本次会话里修复卡死的关键修复（listAssets 持有 rows 期间嵌套查询导致的连接池死锁 → 先 rows.Close()
13
 再查）。go vet + local_library/services/storage_plugins 全部测试通过，稳定性已恢复。
14

15
 打开慢的根本原因（如实说明）
16

17
 打开资源库必跑一次全量扫描：单线程遍历整个目录树，对每个已索引文件做 SELECT + UPDATE（写
18
 scan_token 防止误标 missing），约 2297 次数据库往返，是 O(文件数) 的固有成本。体量越大越慢。
19

20
 下一步（安全提速的方向）
21

22
 - 基于变更清单的增量扫描：正常关闭时记录本次扫描的变更指纹，再次打开时若 watcher 未累积变更，
23
   则跳过全量重扫（改动较大，需谨慎设计，避免再次引入竞态）。
24
 - 先修复测试收尾的文件句柄竞态（这是 Windows 上 go test 的既有顽疾），再考虑重新引入批量扫描。
25

26
 要往增量扫描方向推进，还是先处理测试收尾竞态？