sublime text正则替换只支持$1、$2等位置捕获组，不支持命名组和\1；需启用.图标正则模式，括号须成对且按左括号顺序编号，非捕获组(?:...)不占位；避免回溯爆炸应少用.改用.*?或具体字符集。
Sublime 的正则替换怎么写捕获组
Sublime Text 的正则替换用的是 PCRE 风格，但不支持命名捕获组（如 (?<name>\w+)</name>），只认位置编号：$1、$2……对应括号从左到右的顺序。写错编号或嵌套括号没数清，就直接替换出空内容或乱码。
常见错误现象：$0 被误当第一组（实际是整个匹配）、反斜杠没转义导致 \1 不生效、用了 \g 这种 Python 风格语法（Sublime 不认）。
- 必须用
$1、$2，不能用\1（除非在「查找」框里且未勾选「正则」？不，Sublime 统一用$n） - 括号要成对，嵌套时按左括号出现顺序编号：
(a(b)c)中，$1是整个abc，$2是b - 非捕获组
(?:...)不占编号，可用来分组但不干扰 $ 序号
Sublime 替换里怎么避免 $1 变成字面量
如果替换结果里出现了字面量 $1 而不是实际内容，说明 Sublime 没识别出捕获组——大概率是「查找」框里没启用正则模式，或者括号被当成了普通字符。
使用场景：批量重命名变量、提取日志字段、格式化 JSON 键名等，都依赖正确捕获。
- 务必勾选查找面板右下角的
.*图标（即启用正则）；没点它，(\w+)就是纯文本匹配 - 如果原文有括号想字面匹配，得写成
\(和\)，否则会被当捕获组解析 - 替换框里写
$1时，前面加反斜杠可转义：\$1→ 输出字面$1，但极少需要
Sublime 正则替换性能差？这些写法会卡死
Sublime 对长文本 + 复杂正则响应慢，不是 bug，是回溯爆炸。比如 (.*)* 或 .*\d.* 在几千行日志里可能卡住 UI，甚至假死。
性能影响明显的情况：文件 > 5MB、正则含贪婪量词 + 多层嵌套、用 ^/$ 配合 .* 跨行匹配（Sublime 默认不跨行，但误开「. matches newline」后极易拖慢）。
- 优先用非贪婪：
.*?比.*更安全；但注意 Sublime 的?必须跟在量词后，单独?是「0 或 1 次」 - 避免
.*开头的模式，改用锚点或具体字符集，例如用[^\n]+代替.*匹配单行 - 大文件先 Ctrl+Shift+P →
Split into Lines或手动分块处理，别硬刚
为什么 Sublime 的 \b 或 \s 替换总不生效
\b（单词边界）和 \s（空白符）在 Sublime 里完全可用，但容易因编码、不可见字符或正则模式理解偏差失效。
兼容性影响：Windows 换行符 \r\n、Mac 的 \r、UTF-8 BOM 都可能让 ^ 或 \s 行为异常；另外 Sublime 默认不把 \s 当作匹配 \r，得显式写 [\s\r\n] 才稳。
-
\b只认 ASCII 单词字符（[a-zA-Z0-9_]），中文、emoji、破折号都不算「词」，所以\b测试\b匹配不到 -
\s在 Sublime 中默认匹配空格、\t、\n，但不保证含\r；保险写法是[ \t\n\r\f\v] - 查不可见字符？用 Ctrl+Shift+P →
Set Syntax: Plain Text再打开「显示不可见字符」（View → Show Whitespaces）
