本地文件搜索的平均等待时间是4.7秒——足够你刷两条短视频。一个用Python写的原型工具，想把这4.7秒砍到0.3秒。
没有索引，靠缓存+多进程硬刚，作者放话要让本地搜索"像网页搜索一样快"
这事听起来像开倒车。Elasticsearch（一种分布式搜索和分析引擎）早就把索引玩明白了，谁还做无索引搜索？但开发者@programmer_dude的GitHub仓库FileSearch Prototype，3天内星标破千，评论区挤满"终于有人做这个"的哀嚎。
痛点很具体：现有工具要么像Windows搜索那样慢，要么像DocFetcher（一款开源桌面文件搜索工具）那样丑。用户要的是现代UI+即时响应，不是一份需要编译的说明书。
原型长什么样
PySide6（一种Python图形界面框架）写的界面，支持PDF、Word、Excel等格式。核心逻辑粗暴：第一次搜索慢，结果进缓存；第二次直接读内存。多进程并行处理文件，CPU核心数拉满。
作者承认这是"fast prototype"，没做索引。换句话说，它用空间换时间，用内存堆出速度。对SSD用户友好，机械硬盘可能吃瘪。
GitHub Issues区已经吵起来了。有人要正则表达式支持，有人要排除特定文件夹，还有人问能不能搜图片里的文字（OCR）。最热门的请求是：加索引。
作者回复很克制："先验证无索引方案的上限，再决定要不要加。"
为什么有人需要这个
企业用户的场景很扎心。某条高赞评论："公司电脑装不了任何云同步工具，10年项目文档散落在37个文件夹，Windows搜索能找到算我输。"
律师、医生、研究员是另一类刚需群体。他们的文件敏感，不能上云；数量庞大，人工整理不现实。现有方案要么太贵（如dtSearch），要么太老（如DocFetcher最后更新在2022年）。
FileSearch的定位卡在这里：比系统搜索快，比商业工具轻，比旧开源工具新。它不做企业级功能，但把"搜得到、搜得快、界面能看"三件事做到位。
技术选型也有意思。Python+PySide6意味着跨平台，但打包体积大、启动慢。作者回应：先用Python验证需求，性能瓶颈真出现了再考虑Rust或C++重写。
社区在吵什么
争议焦点是"要不要索引"。反对派认为无索引注定 scalability（可扩展性）差，10万文件必崩。支持派反驳：90%用户文件不到5万，缓存够用了，索引反而增加复杂度。
作者的态度是数据驱动。他在README里列了测试环境：AMD Ryzen 7 5800X，32GB内存，NVMe SSD，10万PDF首次搜索8秒，第二次0.4秒。这个数字够不够好？他扔给社区判断。
另一个火药桶是格式支持。有人要EPUB，有人要Markdown，还有人要代码文件的语义搜索（比如找"用了某个函数的所有Python文件"）。作者的开源策略是：先合并高频需求，边缘功能等PR（Pull Request，代码合并请求）。
评论区有个细节很真实。用户@archivist_42说："我试了7个本地搜索工具，这是第一个我老婆能自己装上的。"易用性在开发者眼里常是伪需求，但对真实用户是生死线。
FileSearch的安装流程是：下载、解压、双击。没有Python环境检测，没有pip install，没有配置文件要改。
这事的后续
作者正在征集两类反馈：功能优先级排序，以及"你现在的搜索 workflow（工作流程）是什么"。后者显然是在挖竞品替代的真实场景。
GitHub Star的增长曲线已经放缓，从首日600掉到第三天200。这是好事——说明早期猎奇用户筛完了，留下来的是真需求。
一个有趣的对比：同样做本地搜索的AnyTXT Searcher，闭源免费，更新频繁，但社区活跃度远不如这个三天原型。开源的透明度和参与感，在工具类产品里仍是稀缺资源。
作者最后一条更新是6小时前：修复了PDF含图片时的内存泄漏，发布了Windows安装包。没写"里程碑"，没发Twitter庆祝，commit message（代码提交说明）就一行："fix: reduce memory usage on scanned PDFs"。
你会为了0.3秒的搜索速度，放弃索引带来的确定性吗？或者说，你的本地文件混乱到什么程度，才需要一个专门工具来拯救？
热门跟贴