必须用 Web Worker 处理文件索引，因主线程同步操作会阻塞渲染；主线程负责文件选择与数据预处理，Worker 专注纯数据索引构建，通过 structuredClone 传递结构化数据并流式反馈进度与结果。
直接在主线程读取并索引大量文件，必然卡死页面——浏览器单线程模型下，同步解析、递归遍历、字符串匹配等操作会阻塞渲染与交互。真正可行的方案是：用 Web Worker 承担全部索引构建工作，主线程只负责文件选择、数据传递与结果呈现。
为什么必须用 Worker 处理文件索引
浏览器禁止 Worker 直接读取本地文件系统（如 FileReader 无法在 Worker 内使用），但这不等于 Worker 不能参与索引。关键在于分工：
- 主线程用
<input type="file" webkitdirectory>或拖放 API 获取FileList，再通过File.prototype.arrayBuffer()或text()提前读取内容（或仅提取元数据） - 将结构化数据（如文件路径、大小、文本摘要、JSON 树）序列化后传入 Worker ——
structuredClone()支持深层对象、Date、ArrayBuffer等，比 JSON.stringify 更可靠 - Worker 接收纯数据，不碰 DOM、不调 File API，专注递归遍历、分词、建倒排索引或 Trigram 表，完成后逐条
postMessage匹配结果
构建可递归的安全文件树结构
Worker 无法访问真实目录树，所以主线程需先构造“虚拟文件系统”数据：
- 对用户选中的文件夹，用
webkitdirectory获取所有子文件，按路径生成嵌套对象：{name: "src", type: "dir", children: [{name: "index.js", type: "file", contentHash: "a1b2c3..."}]} - 避免循环引用、
undefined、函数、RegExp—— 这些无法跨线程传递，会静默丢弃 - 若文件超 1 万项，不要一股脑传入单个 Worker；改用分片策略：按路径前缀（如
/docs/、/api/）拆成多个任务，启动多个 Worker 并行处理
Worker 内实现高效索引逻辑
索引不是简单 includes()，而是要兼顾速度、内存与模糊能力：
立即学习“前端免费学习笔记（深入）”；
- 对文本字段做轻量分词（空格 + 标点切分），建立倒排索引：
{"worker": [102, 305], "thread": [44, 102]} - 支持模糊搜索？用 Bitap 算法或预生成 Trigram（每三字符一组），查时拆输入为 trigram 后求交集，比正则快一个数量级
- 防栈溢出：递归深度超 2000 层时，自动切换为显式栈（
const stack = [{node, path}]; while(stack.length) {...}） - 索引建好后保留在 Worker 全局变量中，后续查询复用，避免重复解析
主线程协同与用户体验优化
索引过程要让用户感知可控、可中断、有反馈：
- 用
progress事件模拟进度：Worker 每处理完 100 个文件就postMessage({type: 'progress', done: 120, total: 5000}) - 提供“暂停/恢复”按钮：主线程发
{type: 'pause'}指令，Worker 在循环中检查self.paused标志位 - 搜索结果流式渲染：Worker 每匹配一项就发一次消息，主线程用
document.createElement动态追加，避免等待全部完成 - 加
scroll-margin-top: 80px到锚点元素，点击索引跳转时标题不被顶部导航栏遮挡
