Struct OcrQueue 

pub struct OcrQueue { /* private fields */ }

OCR 队列：图片的 (path,mtime,size) 待处理表 + 已处理结果缓存，随索引目录持久化 在 <index_dir>-ocr-queue.json（跟 meta.rs 的 <index_dir>-meta.json 同一个 “索引目录旁的兄弟文件“套路，不塞进 tantivy 自己管理的索引目录里）。

进程内按 index_dir 单例复用（见 for_index_dir）：rebuild_index、reconcile、 增量更新（IndexUpdater::apply）、OCR worker 池，这四处调用方全部共享同一份 内存状态。如果各自独立开一份再各自落盘，后写的会把先写的进度覆盖掉—— 队列持久化的意义就没了。

Implementations

impl OcrQueue

pub fn for_index_dir(index_dir: &Path) -> Arc<OcrQueue>

取（或首次创建）某个索引目录对应的进程内单例。第一次调用时从磁盘加载已持久化 的状态；磁盘上没有（旧索引、或者这是第一次跑 M4 之后的代码）就是空队列，不算错误。

不变量：单例注册表按规范化后的路径（剥掉 \\?\/\\?\UNC\ 扩展长度 前缀，见 crate::display_path）去重。同一个索引目录可能被不同调用方 用不同的路径语法传进来——比如 E:\index 和 Path::canonicalize() 在 Windows 上天生带前缀的 \\?\E:\index，两者指向磁盘上同一个目录。如果 key 原样比较，会各建出一份独立的 OcrQueue，谁后 save() 就把谁的 进度覆盖掉。只有 map 的 key 做规范化；存进单例本体、参与文件 IO 的 index_dir 字段仍然是第一次创建它的调用方传入的原始路径——长路径场景 要靠 \\?\ 前缀绕开 Win32 MAX_PATH，不能剥。

pub fn pending_len(&self) -> usize

待处理项数，给 CLI 的 drain_ocr_queue 判断“清空了没“用。

pub fn save(&self) -> Result<()>

落盘。rebuild_index/reconcile 批量入队后各调一次；IndexUpdater::apply 在 一批增量里确实碰到过图片时也调一次；worker 每处理完一张图也调一次—— 一次 JSON 序列化的代价远小于一次 OCR 识别（百毫秒级），可以接受。

pub fn compact(&self, roots: &[PathBuf])

按当前扫描根裁剪队列：不落在 roots 任一根之下、或者对应文件已经不在 磁盘上的 pending/processed 条目一律丢弃。

这个队列是进程级单例（见 Self::for_index_dir），rebuild_index 每次 全量重建时会把内存里已有的历史条目原样存回——如果目标目录换过、或者 有文件在两次重建之间被删掉，这些条目没有任何清理路径，只增不减、永久 堆积。rebuild_index 在最终落盘前调用这个方法压实一次。