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），否则一律关掉匹配整个单词 - 需要兼顾精确与模糊？改用正则：
buserb，比开关更可控 区分大小写和匹配正则表达式默认关闭，开了却没写对语法（比如.*跨行失效），结果就是零匹配
大文件+多文件混合场景下，标记所有匹配项 是性能杀手
在几十个几百 MB 的日志或导出文件里搜 ERROR，如果勾选「标记所有匹配项」，Notepad++ 会为每个位置生成渲染标记对象。几万处匹配，UI 线程直接拖垮，滚动延迟、点击无响应，全是它惹的祸。
- 正确做法：用
搜索 → 查找 → 勾选“标记行” → “查找全部”，匹配行自动加书签，不占主编辑区资源 - 之后用
搜索 → 书签 → 复制书签行导出关键片段，干净利落 - 如果必须局部高亮，先
Ctrl+G跳到某段（如第 50000 行），再在该视图内搜索并标记，避开全局加载
超 50MB 文件参与搜索？别让它全文加载
Notepad++ 不是流式加载器。一旦某个被扫文件 >50MB，且你没做限制，它就会尝试全文解析——语法高亮建 token 表、行号实时计算、自动换行强制折行缓存，三项叠加直接让 Scintilla 引擎反复回溯、CPU 暴涨。
- 提前禁用：
设置 → 首选项 → 编辑器 → 取消勾选“启用语法高亮”、显示行号、自动换行 - 搜索前，把大文件移到纯英文短路径（如
C:tmp），避免中文路径、波浪号（~）导致静默丢弃 - 真要处理 >200MB 的单文件？Notepad++ 已不适合，该换 VS Code（开
large file optimizations）或命令行grep，硬扛只会浪费时间
真正卡住的点，往往不在“怎么搜”，而在“它到底在干什么”。关掉那些你以为有用、实则吃资源的默认功能，比调优正则更重要。
