Windows Search 更快更准，因其依赖预建索引和内置IFilter插件解析.docx、PDF等格式内容，而非实时扫描或纯文本读取；需启用磁盘索引、引用Microsoft.Search.Interop.dll，注意平台为x64。
递归遍历文件夹时，为什么容易栈溢出或卡死
因为 AddFileNamesToList 这类纯递归实现没做深度限制，遇到符号链接（比如 NTFS junction 或 symbolic link）、损坏的重分析点（reparse point），或者超深嵌套目录（如自动生成的日志目录），会无限递归下去。Windows 默认线程栈只有 1MB，几十层嵌套就可能触发 StackOverflowException，且无法 catch。
实操建议：
- 用
Directory.EnumerateFiles(sourceDir, "*", SearchOption.AllDirectories)替代手写递归——它内部已处理重分析点跳过、异常捕获和迭代式遍历，更稳 - 若必须手动递归，加深度计数器，比如传入
int maxDepth = 10，每进一层减一，到 0 就 return - 务必包裹
try/catch (UnauthorizedAccessException)，权限不足的文件夹（如C:WindowsSystem32）会直接中断整个遍历
非递归方式怎么避免内存爆炸
用栈（Stack<string>）或队列（Queue<string>）模拟遍历逻辑，看起来“不递归”了，但若一次性把所有子目录全压入，内存占用反而比递归还高——尤其当某层有上千个子文件夹时。
实操建议：
- 用
Directory.EnumerateDirectories按需获取下级目录，别用GetDirectories一次性拉全 - 对每个目录，先处理文件（
EnumerateFiles），再把子目录推入栈/队列——减少中间集合对象数量 - 加
yield return实现延迟枚举，比如封装成IEnumerable<string> GetFilesRecursively(string root)，调用方按需取，不囤积
搜文件内容时，File.ReadAllText 为什么经常报错
它默认用 UTF-8 解码，但很多文件是 ANSI、UTF-16、甚至带 BOM 的混合编码；二进制文件（.exe、.pdf、.docx）读出来就是乱码，Contains 必然失效，还可能抛 IOException 或 DecoderFallbackException。
实操建议：
- 文本文件优先用
File.ReadLines(fileName)逐行读，内存友好，且可配合Encoding.Default或Encoding.UTF8显式指定 - 想支持 Word/PDF 等格式，别自己解析——走 Windows Search 的
ISearchQueryHelper或调用CIM_SearchFilterCOM 接口，依赖系统索引服务 - 临时方案：用
try { var s = File.ReadAllText(f, Encoding.UTF8); ... } catch { /* 跳过该文件 */ }，但记得记录跳过数，否则漏搜不自知
为什么用 Windows Search API 反而更快更准
因为 Windows Search 后台有预建索引，不是实时扫磁盘；它内置 Office、PDF、OpenXML 等格式的 IFilter 插件，能真正解包 .docx 里的文字、PDF 里的 Unicode 字符流，而不是把 ZIP 容器当纯文本读。
实操要点：
- 确保目标卷已开启索引（右键磁盘 → 属性 → “允许索引此驱动器…” 已勾选）
- C# 中调用需引用
Microsoft.Search.Interop.dll（来自 Windows SDK），核心是ISearchCatalogManager和ISearchQueryHelper - 查询语句写成
"scope:='file://D:\' contents:'keyword'"，注意单引号转义和路径格式 - 32 位进程查不了 64 位索引服务，编译目标平台必须设为
x64或Any CPU + Prefer 32-bit=false
实际项目里，纯代码遍历适合小范围、纯文本、结构可控的场景；一旦涉及多格式、大目录、用户不可控路径，绕不开 Windows Search——它不是“高级技巧”，而是 Windows 平台的事实标准。
