是的，\r、\n 等 反斜杠字母 在正则表达式里都属于 元字符（转义序列），用来匹配 不可见控制字符，而不是匹配字面量的反斜杠和字母。
只要正则引擎支持 PCRE / 扩展正则（大多数现代语言/工具都支持），就可以直接用
在 PCRE / Perl / Java / .NET / JavaScript 这类“扩展正则”中，\r、\n 才被当作 元字符 去匹配回车、换行。
以 Perl 的 print "Hello\n"; 为例：

代码解析阶段：
Perl 解释器识别 \n 转义序列
将其替换为二进制值 0x0A（ASCII 10）

执行阶段：

实际发送到标准输出的字节序列

48 65 6C 6C 6F 0A # H e l l o <LF>
终端接收阶段：
终端程序（如 bash/cmd）检测到 0x0A
根据操作系统规则移动光标：
Unix/Linux：直接换行（LF = Newline）
Windows：需配合 0x0D（CR）实现 \r\n

正则表达式里的 \n（或 \r）
只有当正则引擎解析 正则字面量 时，才把 \n 当成“匹配换行符”的元字符。
它同样最终对应那个 0x0A 字节，但语义是“匹配”，而不是“输出”。

把 Notepad++ 的三种“查找模式”当成三条互不相干的规则说明书就容易理解了：
普通
把输入框里的字符原样当作待查字符串，任何 \ 都只是普通反斜杠。
扩展（\n, \r, \t, \0, \x…）
只支持极少量的转义字符：
\n → LF（0x0A）
\r → CR（0x0D）
\t → TAB（0x09）
\0 → NUL（0x00）
\xHH → 任意十六进制字节
除此之外所有正则元字符（. * + ? ^ $ …）都失去特殊含义，按字面量匹配。
换句话说，它只是一个“带简单转义的纯文本”模式，不是正则。
正则表达式
切换到完整的 Boost/PCRE 正则引擎，. * + ? ^ $ | 等都恢复正则语义；
同时 \n、\r、\t、\xHH 这些控制字符转义照样可用，因为它们本来就属于 PCRE 语法。
因此会出现“\n 在扩展里能用，在正则里也能用”的现象——它们是两个独立开关，各自维护一套规则，只是恰好都认识 \n 等少数转义。

\n 会“换行”的根本原因是：
操作系统把字节 0x0A（LF，Line Feed）当成「行结束标记」，
终端 / 编辑器 / 打印机 等输出设备收到这个字节后，会把游标/打印头移到下一行的开头。
这个动作由 终端驱动、控制台、文本渲染引擎 完成，跟正则、Notepad++、语言本身都无关。

分角色再捋一遍：
ASCII 层面
\n 只是「转义写法」，最终就是 一个字节 0x0A。

语言层面（C/Perl/Shell…）
解释器把字符串里的 \n 翻译成 0x0A，然后把它写进文件或送到终端。

终端 / 操作系统层面
在 Unix/Linux/macOS：收到 0x0A → 光标下移一行（LF 即可换行）。
在 Windows：C 运行库把 \n 自动转成 CR+LF（0x0D 0x0A） 两个字符，终端收到 CR 回到行首、LF 下移一行，于是肉眼看到换行。
在 老式打印机：LF 是“滚筒下移一行”，CR 是“打印头回到最左”，二者配合才换行。

编辑器 / Notepad++
打开文件时按当前换行符设置（LF/CRLF/CR）把 0x0A 渲染成新的一行；
查找窗口里的「扩展模式」只是把用户输入的 \n 转成 0x0A，再交给搜索引擎去匹配字节——不会触发任何光标动作，只是“匹配”或“插入”这个字节而已。

一句话总结
\n 会换行，是因为 操作系统/终端把字节 0x0A 定义为“行结束”；
编程语言、编辑器、正则都只是把 \n 翻译成 0x0A 并交给下层系统去处理。