sublime中.不匹配换行符是pcre标准行为，需用[\s\s]*?或(?m)模式实现跨行匹配，^/$默认不按行生效，替换框输\n需用快捷键插入真实换行符。
为什么.*匹配不到换行符
Sublime 默认的 PCRE 正则引擎中，. 不匹配 \n，这是标准行为，不是 Bug。你写 start.*end，它永远停在第一行末尾，根本不会跨行——哪怕肉眼看到目标文本横跨两行。
常见错误现象：function.*{ 只高亮到 { 所在行的开头；^import.*$ 查不到第二行的 import；全局搜 \n 却没反应。
- 必须显式写出换行：查
\n（LF）或\r\n（CRLF），不能靠.碰运气 - 更稳写法是用
[\s\S]*?代替.*?：它明确表示“任意空白或非空白字符”，天然跨行，兼容所有平台 -
(?s)模式（即. matches newline）虽可用，但在某些 Sublime 版本里不稳定，[\s\S]更可靠
^ 和 $ 不按行生效，怎么修
默认状态下，^ 只匹配整个文本开头，$ 只匹配整个文本结尾。你在第 5 行写的 ^# 根本不会被匹配——除非启用多行模式。
Windows 下还有个隐藏坑：$ 在 CRLF 文件里会停在 \r 前，导致替换后残留 ^M 或错位。
- 启用多行模式：点替换面板右下角 ⇩ 图标（或按
Alt+M），或在正则前加(?m)，例如(?m)^# - 跨平台安全写法：用
\R替代$（仅用于查找），它等价于\r\n|\r|\n，不依赖当前文件换行格式 - 别混用
R和\n：R是 Sublime 内置符号，只支持在查找框，不能写进替换框；\n在替换框里只生效于正则开启状态
替换框输 \n 却变成字面 \n 字符
这是最常被误判为“正则失效”的现象：你在替换框敲 \n，执行后文本里真出现了反斜杠加字母 n，尤其在 JSON 或代码字符串里直接引发语法错误。
根本原因：Sublime 的替换字段默认不解析转义序列，\n 只有在正则模式开启 + 上下文允许时才被识别为换行符；否则就是两个普通字符。
- 正确做法：用快捷键插入真实换行符——Windows/Linux 是
Ctrl+Shift+Enter，macOS 是Control+Command+Enter - 确认正则已开：替换面板右下角
.*必须是蓝色高亮状态；否则快捷键也无效 - 想插多个换行？连按快捷键，不是输
\n\n；输错一次就得手动删掉那两个字符再重来
删空行、加空行、合并换行，三类操作别混在一起
试图用一条正则同时“删空行 + 在非空行间插一个空行”，比如搜 ^\s*$\n 替成 \n\n，结果要么漏掉带空格的空行，要么把缩进吞掉，甚至让整个文件结构塌陷。
根本问题在于：\n 在正则中既是内容又是锚点，混用极易失控；且不同换行格式（CRLF/LF）会让 $ 和 \n 锚定位置偏移。
- 删空行（含纯空白行）：查
^\s*$\R，替为空；再补查\R$，替为空，确保文件以单个换行结尾 - 每行后加一个空行：查
$，替为快捷键换行（不是\n），且务必关闭. matches newline（即不勾选 ↩） - 合并连续换行为单个 LF：先统一换行格式（View → Line Endings → Unix (LF)），再查
\n{2,}，替为\n
所有涉及 ^、$、\R 的操作，都得先看一眼右下角状态栏：line ending 是什么、编码是不是 UTF-8、.* 和 ⇩ 是否处于预期状态——差一个，结果就全偏。
