Sublime Text跨行查找默认失败是因为PCRE引擎默认关闭dotall模式，.不匹配换行符，必须在正则开头加(?s)显式启用；勾选“. matches newline”会破坏^/$行为，[\s\S]虽可行但不如(?s)简洁规范。
Sublime Text跨行查找为什么默认失败
因为 PCRE 引擎默认关闭 dotall 模式，. 不匹配换行符 \n，所以 a.*b 遇到 a\nb 就完全不匹配。这不是 bug，是标准行为，但新手常以为“开了 .* 就能跨行”——其实必须显式启用。
必须在正则开头加 (?s)，这是唯一跨版本、跨平台兼容的写法；(?m) 没用，它只影响 ^ 和 $，对 . 无效；[\s\S] 虽然也能跨行，但不如 (?s) 简洁且语义明确。
常见错误：
- 忘记加
(?s)，却勾选了. matches newline—— 这会让^和$失效，导致行边界错乱 - 把
(?s)写在中间或末尾，比如start(?s).*end—— 位置错误，无效 - 误用
\n字面量：Windows 是\r\n，Linux 是\n，直接写易漏匹配；应优先用\R（Sublime 原生支持）
怎么写一个安全的跨行匹配表达式
核心原则：限定范围 + 非贪婪 + 显式换行处理。别依赖 .*，尤其不能让它出现在开头。
例如匹配 Python docstring：(?s)"""[^"]*?"""
-
(?s)启用 dotall，让[^"]可跨行 -
[^"]*?比.*?更稳：避免吞掉中间的"""，防止匹配过长 - 如果 docstring 内含转义引号（如
\"""），这个写法会失效，需改用更复杂逻辑，但 95% 场景够用
匹配 HTML 块（非嵌套）：(?s)<div>]*>[\s\S]*?</div>
-
[^>]*防止<div class="a">... 中的 <code>>被.*?吞掉，导致误匹配到下一个标签 - 不用
.*?，改用[\s\S]*?更可控（和(?s)效果一致，但更直白） - 嵌套
<div>？Sublime 正则不支持递归，得手动分段或放弃<h3>贪婪 vs 非贪婪：什么时候必须用 <code>*?几乎所有跨行场景都该用非贪婪，除非你真想一口气吃到文件末尾。
典型踩坑：
-
(?s)start.*end→ 在大文件中可能匹配从第一个start到最后一个end，中间所有内容全被吞掉 -
(?s)<!--.*-->→ 如果文档里有多个注释，它会从第一个<!--一直吃到**最后一个**-->，中间所有 HTML 全变注释 - 正确写法：
(?s)<!--.*?-->或(?s)<!--[\s\S]*?-->
性能提示：非贪婪在超长文本中仍可能慢，若知道大致长度，可用
[\s\S]{1,2000}?限长，避免回溯爆炸。捕获组跨行提取时，
$1总是原样输出？根本原因不是正则写错了，而是正则模式根本没启用：状态栏没显示
Regex，.*图标没变蓝，或快捷键没按对（Windows/Linux 是Alt+R）。必须同时满足三点：
-
.*图标为蓝色（点击它或按Alt+R） - 状态栏右下角显示
Regex - 替换框里写
$1，不是\1或${1}（后者 Sublime 不识别）
验证是否生效的小技巧：先用
\d+测试——能高亮数字，说明正则已工作；再把光标悬停在匹配块上，看虚线是否标出分组边界，确认$1真对应你要的内容。真正麻烦的从来不是语法，而是每次替换前没花 10 秒点一下
Find All看预览——匹配错了，后面全是白忙活。 -
