suzmii
e98066ee7e
驱逐后不再补扫：删掉那条会把可见卡反复重读的自激回路，并如实标注超时预算
- 删掉 publishPreview 里"驱逐后立刻补一次可见性扫描"（原 useProjectResourceCardPreviews.ts 的 `if (evictedCount > 0) sweepVisiblePreviews()`）。它原先的注释宣称"递归深度恒为 1、不自激"，该不变量是假的，判据有三条：(1) 触发条件是"本轮驱逐了任意条目"，而第一轮只淘汰视口外条目，那种情况下根本没有可见卡丢状态，补扫却照样把空闲且可见的卡重新入队；(2) 真正驱逐到可见卡时（全表都在视口内且仍超预算，第二轮全表 LRU 回退）补扫把刚被驱逐的卡重新入队 → 读回来又超预算 → 再驱逐 → 再补扫，每个周期跨一次异步读取，是不收敛的回路；(3) 那种回读换不来稳定结果，读回的卡立刻被下一轮 LRU 淘汰（第二轮回退是全表 LRU，刚读回的卡恰好最新），只在可见集合里轮转。因此正确反应是接受这次有界淘汰（由「全可见且超预算时仍必须淘汰」钉住），而不是反复重读；代码注释按这三条重写，不留误导后人的陈述。
- 顺带删掉只为那段补扫存在的 `evictedCount`（否则是死变量）。
- 断言：新增 useProjectResourceCardPreviews.test.ts「settles instead of re-reading evicted visible cards forever」——全部登记且都在视口内（第一轮无从下手），断言读取次数在观察窗口内不再增长、且缓存稳定在上限。
- 变异验证（提交前已跑）：把补扫加回去 → 该用例**不是断言变红而是 worker 被撑爆**（`ERR_WORKER_OUT_OF_MEMORY`，约 74 秒后终止），即回路真的不收敛；还原后复跑 32 passed，该用例 2.1s 通过。
- 超时预算改为"标注并给出实测依据"，不再用放宽时间门吸收负载代价：`releases Blob URLs while continuously browsing beyond the cache limit` 的 `}, 30000)` 保留，并在用例前写明理由 —— 它逐个 waitFor 等 79 张卡串行读完，轮数由条目上限 48→72 机械地从 55 涨到 79（+44%），实测 6120 ms，已超 vitest 默认 5s，属结构性必需。同一提交里的 `waitFor({ timeout: 30000 })`（由 20000 顺手放大）按实测**回到 20000** 并写明依据（该用例实测 124 ms，约 160 倍余量）。
- 门禁：useProjectResourceCardPreviews 32 passed。
2026-09-11 22:02:31 +08:00
..
2026-09-05 19:48:27 +08:00
2026-09-11 22:02:31 +08:00
2026-09-01 17:00:44 +08:00
2026-09-01 17:00:44 +08:00
2026-08-22 13:17:26 +08:00