在Notepad++查找窗口勾选“正则表达式”，输入模式后点击“查找下一个”或“全部标记”即可实时高亮匹配结果；默认使用较旧PCRE引擎（如v8.32前为PCRE 7.9），不支持(?
Notepad++ 的「查找」窗口里怎么实时看正则匹配效果
直接在 查找 对话框勾选 正则表达式，输入模式后点 查找下一个 或 全部标记，就能立刻看到高亮结果——这是最轻量、最常用的调试方式。
注意：Notepad++ 默认用的是 PCRE（Perl 兼容）引擎，但版本较老（v8.32 之前是 PCRE 7.9），不支持 (? 这类可变长度的后行断言，也不支持 <code>\K。如果写完没匹配上，先怀疑是不是用了新版 PCRE 才有的语法。
常见错误现象：查找下一个 没反应，或只标中第一处——大概率是正则里有未转义的 .、*、+，或者忘了勾选 正则表达式 模式（它默认是普通文本匹配）。
- 确保勾选了
匹配大小写和正则表达式，二者独立开关 -
全部标记会把所有匹配加黄色背景，比反复点查找下一个更直观 - 如果想测试替换效果，直接切到
替换标签页，填好查找目标和替换为，再点全部替换前先用替换看单步效果
为什么 \d+ 能匹配数字，但 \bword\b 有时不生效
Notepad++ 的 \b 是基于 ASCII 字符边界的单词边界，它把下划线 _ 当作“单词字符”，所以 \bword\b 在 my_word 中不会匹配 word——因为 _ 和 w 之间不算边界。
实际使用中更稳的方式是显式写边界：
- 想匹配独立单词
if？用(?<=^|[^a-zA-Z0-9_])if(?=[^a-zA-Z0-9_]|$) - 想匹配纯数字？
\d+没问题，但若要排除123abc中的123，得加负向断言：(?<![0-9])\d+(?![0-9]) - Notepad++ 不支持
\R（通用换行符），统一用\r\n|\r|\n替代
替换时怎么引用捕获组？$1 还是 \1
Notepad++ 只认 $1、$2……这种美元符号写法，\1 在替换栏里会被当成字面量反斜杠+1，不是引用。
示例：要把 name: "Alice" 改成 Alice (name)，查找用 name:\s*"([^"]*)"，替换填 $1 (name) 就行。
容易踩的坑：
- 如果正则里用了非捕获组
(?:...)，它不产生编号，别指望能用$1引用它里面的内容 -
$0表示整个匹配，不是第零个捕获组；$1对应第一个(...)，哪怕它嵌套在别的括号里 - 替换内容里要输出字面量
$，得写成$$，否则会被误认为变量引用
大文件里正则卡死或漏匹配，是引擎限制还是写法问题
Notepad++ 的正则引擎对回溯深度有限制，尤其遇到 .* + 后缀组合（比如 start.*end）在长段落里极易触发回溯爆炸，表现就是界面假死、CPU 占满、最终无响应或只匹配前几处。
这不是你电脑慢，是 PCRE 7.x 的固有限制。解决方案不是升级 Notepad++（新版也没换引擎），而是改写正则：
- 把贪婪
.*换成惰性.*?，但注意 Notepad++ 实际只支持.*?，不支持.+?这种写法 - 避免嵌套量词，比如
(a+)+，改用a+直接匹配 - 超大文件（>50MB）建议先导出部分文本到新标签页再试，别硬刚全文档
真正难搞的，往往是那些看起来简单、但边界模糊的模式——比如匹配引号内内容，"[^"]*" 看似稳妥，一旦遇到转义引号 "he\"llo" 就崩，而 Notepad++ 又不支持递归或条件匹配，这时候就得接受“手动分段处理”是更现实的选择。
