Sublime Text正则匹配需注意：^/$默认不跨行，须启用“.”匹配换行；捕获组编号按左括号顺序；\w不匹配中文，需用[\u4e00-\u9fa5]；不支持动态替换如行号递增。
匹配跨行的多行字符串时，^ 和 $ 不起作用
Sublime Text 默认正则引擎（PCRE）在单行模式下，^ 和 $ 只匹配整段文本的开头和结尾，而非每行——这导致你写 ^def.*?end$ 无法捕获换行中间的内容。必须启用「dotall」模式（即让 . 匹配换行符），同时配合 ^/$ 的多行语义。
实操建议：
- 在查找框中勾选 「. matches newline」（或快捷键
Alt+R切换）——这是启用 dotall 的唯一方式，没有(?s)这类内联标志支持 - 若需按行锚定（比如只匹配以
class开头、后跟换行和缩进的块），改用^class.*?^\}$并确保也勾选 「Matches newline」，此时^才能匹配每行开头 - 不勾选时，哪怕文本里有换行，
^也只命中第一行最前，$只命中最后一行末尾，极易漏匹配
\1、\2 捕获组编号错乱，替换结果为空或错位
Sublime 的捕获组编号严格按左括号 ( 出现顺序从 1 开始计数，嵌套或非捕获组 (?:...) 不占编号，但很多人误以为“外层括号是 \1，内层是 \2”，实际取决于括号书写顺序。
常见错误现象：写 (foo)(bar(baz)?)，以为 \3 是 baz，其实它是 \3；但如果写成 (foo)((bar)(baz)?)，baz 就变成 \4。
实操建议：
- 在查找框中使用
\1～\9引用捕获组，不支持$1或\g - 不确定编号时，先用简单测试：查找
(a)(b(c)?)(d)，替换为\1|\2|\3|\4，看输出确认顺序 - 避免深层嵌套；优先用非捕获组
(?:...)收敛逻辑，减少无意义编号干扰
中文、emoji 或宽字符被截断，替换后出现乱码或丢失
Sublime 默认以 UTF-8 解析文件，但正则引擎对 Unicode 字符的边界处理较弱——尤其当正则中混用 \w、\b 或固定长度量词（如 .{4}）时，一个中文字符或 emoji（如 ??）可能被当成多个字节切开，导致匹配偏移或替换错位。
实操建议：
-
\w在 Sublime 中**不匹配中文**，它只等价于[a-zA-Z0-9_]；要匹配中文，请显式写[\u4e00-\u9fa5]或[\p{Han}]（注意：\p{Han}在 Sublime 中不支持，只能用 Unicode 范围） - 避免用
.{n}截取含中文的字段；改用惰性匹配 + 边界，例如【([^】]*)】替代【.{10}】 - 替换前确认文件编码为 UTF-8（右下角状态栏显示），否则粘贴进来的正则本身可能已损坏
批量替换含动态计算的值（如行号、递增 ID）做不到原生支持
Sublime 的正则替换是纯静态的，\1 只能回填捕获内容，不支持类似 JavaScript 的 replace(/x/g, (_, i) => i) 那种基于位置的动态生成。想给每行加序号、把 item 替换成 item_1、item_2…这类需求，Sublime 本身无法完成。
实操建议：
- 接受限制：这不是 bug，是设计如此；别浪费时间试
\${i++}或$(count++)，这些语法 Sublime 完全不识别 - 替代路径一：用 Python 插件（如
sublime-text-regex-replace）扩展功能，但需额外安装和配置 - 替代路径二：复制内容到支持函数式替换的环境（VS Code 的
${matchIndex}、或命令行perl -pe），处理完再粘回
真正卡住的地方往往不是语法写不对，而是默认假设 Sublime 能做动态替换——它不能，这点比任何正则技巧都重要。
