用 java.nio.file 遍历文件时，为什么跳过符号链接和隐藏文件？
默认情况下，Files.walk() 会进入符号链接指向的目标，也可能扫到 .git、~$ 临时文件这类干扰项，导致索引变慢或结果污染。
- 用
SimpleFileVisitor自定义遍历逻辑，重写preVisitDirectory()，对path.toFile().isHidden()或Files.isSymbolicLink(path)做拦截 - 别依赖
Files.walk(path, Integer.MAX_VALUE)无脑拉取——深度过大可能触发FileSystemLoopException，尤其遇到循环软链 - Windows 下注意
Files.isHidden()对以.开头的文件不一定生效（NTFS 无隐藏属性概念），建议额外检查path.getFileName().toString().startsWith(".")
用 HashMap 还是 ConcurrentHashMap 存倒排索引？
单线程构建索引时用 HashMap 足够；但若边扫描边索引（比如多线程分目录处理），必须用 ConcurrentHashMap，否则 put() 并发调用会丢数据或抛 ConcurrentModificationException。
-
ConcurrentHashMap的computeIfAbsent()是安全的聚合入口，比手动get() + put()更可靠 - 键建议用小写归一化的词干（如
word.toLowerCase().trim()），避免"Java"和"java"被当成两个词 - 值不存完整文本，只存
Set<path></path>或轻量级封装类（含路径 + 行号列表），否则内存暴涨
搜索阶段用 String.indexOf() 还是正则？
纯子串匹配场景下，String.indexOf() 比 Pattern.compile().matcher().find() 快 3–5 倍，且无编译开销。正则只在需要模糊匹配（如通配符、大小写无关）时启用。
Lucene是apache软件基金会4 jakarta项目组的一个子项目，是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。 Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。Lucene提供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。在Java开发环境里Lucene是一个成熟的免
- 用户输入带
*或?再转正则：把*替成.*，?替成.，并用Pattern.quote()保护其他特殊字符 - 避免每次搜索都
Pattern.compile()——缓存最近 10 个正则对象（用LinkedHashMap实现 LRU），超限就淘汰最久未用的 - 全文扫描时别用
line.matches(regex)，它隐式重新编译；改用预编译好的pattern.matcher(line).find()
为什么搜索结果里总出现二进制文件里的乱码匹配？
直接读 Files.readAllLines(path, StandardCharsets.UTF_8) 遇到 .jpg、.jar 会抛 MalformedInputException，而忽略异常继续读，会导致字节被错误解码成无效字符，再被索引进去。
立即学习“Java免费学习笔记（深入）”；
- 先用
Files.probeContentType(path)判断 MIME 类型，只处理text/*、application/json、application/xml等明确文本类型 - 更稳妥的做法是读前 1024 字节，用
java.nio.charset.StandardCharsets.UTF_8.newDecoder().onMalformedInput(CodingErrorAction.REPORT)尝试解码，失败即跳过 - 不要信任文件扩展名——
report.txt.bak可能是 zip，data.bin可能是 UTF-8 日志
真正难的不是写完能跑，而是让索引既快又准：跳过不该扫的、分清文本和二进制、并发安全、内存可控——这些点漏掉一个，工具就会在真实项目里卡住或返回垃圾结果。
