Notepad++ 大代码库检索慢的根源是默认配置过度消耗资源；关闭语法高亮、行号、自动换行，用 Ctrl+Shift+F 设置目录（如.）、文件过滤器（如.cpp;.h）和搜索子文件夹，可使10万行项目秒出结果。
Notepad++ 在大代码库中检索慢，不是它不行，而是默认配置在“拼命干活”——关掉语法高亮、行号、自动换行，再用 Ctrl+Shift+F 正确设范围，10 万行级项目搜索能从卡顿降到秒出结果。
为什么 Ctrl+F 永远搜不到多文件？入口就错了
很多人反复按 Ctrl+F 输关键词、换目录、调选项，结果底部面板空空如也。这不是搜索失败，是压根没进对入口。Ctrl+F 只作用于当前打开的单个文件；跨文件、跨文件夹搜索必须用 Ctrl+Shift+F（或菜单栏「搜索 → 在文件中查找」）。这个对话框里才有真正控制范围的三要素：目录、文件过滤器、搜索子文件夹。缺一个，搜索就不可控。
-
目录填.最稳——表示当前已打开文件所在路径，避免中文路径、全角空格导致静默失败 -
文件过滤器别留空，写具体后缀，比如*.cpp;*.h;*.py，否则会扫到.log、.tmp等干扰项 -
搜索子文件夹不勾只搜当前层；勾了才递归，但项目层级深时明显变慢，可先不勾，确认命中后再开
匹配整个单词 一开就漏匹配，关掉才是常态
这个选项看着“严谨”，实际是大代码库检索里最常踩的坑。比如搜 user，但目标变量是 username、api_user_id 或 is_user，只要勾了它，全部过滤掉。这不是 bug，是设计如此：它只匹配独立单词边界。
- 除非你明确只想找文档中单独出现的
error（而非enderror），否则一律关掉匹配整个单词 - 需要兼顾精确与模糊？改用正则：
\buser\b，比开关更可控 -
区分大小写和匹配正则表达式默认关闭，开了却没写对语法（比如.*跨行失效），结果就是零匹配
大文件+多文件混合场景下，标记所有匹配项 是性能杀手
在几十个几百 MB 的日志或导出文件里搜 ERROR，如果勾选「标记所有匹配项」，Notepad++ 会为每个位置生成渲染标记对象。几万处匹配，UI 线程直接拖垮，滚动延迟、点击无响应全是它惹的祸。
- 正确做法：用
搜索 → 查找 → 勾选“标记行” → “查找全部”，匹配行自动加书签，不占主编辑区资源 - 之后用
搜索 → 书签 → 复制书签行导出关键片段，干净利落 - 如果必须局部高亮，先
Ctrl+G跳到某段（如第 50000 行），再在该视图内搜索并标记，避开全局加载
超 50MB 文件参与搜索？别让它全文加载
Notepad++ 不是流式加载器。一旦某个被扫文件 >50MB，且你没做限制，它就会尝试全文解析——语法高亮建 token 表、行号实时计算、自动换行强制折行缓存，三项叠加直接让 Scintilla 引擎反复回溯、CPU 暴涨。
- 提前禁用：
设置 → 首选项 → 编辑器 → 取消勾选“启用语法高亮”、显示行号、自动换行 - 搜索前，把大文件移到纯英文短路径（如
C:\tmp\），避免中文路径、波浪号（~）导致静默丢弃 - 真要处理 >200MB 的单文件？Notepad++ 已不适合，该换 VS Code（开
large file optimizations）或命令行grep，硬扛只会浪费时间
真正卡住的点，往往不在“怎么搜”，而在“它到底在干什么”。关掉那些你以为有用、实则吃资源的默认功能，比调优正则更重要。
