Sublime里根本不能用(?=...)这类断言
Sublime Text 的正则引擎（v4+ 默认 Oniguruma）不支持正向先行断言 (?=...)、负向先行断言 (?!...)，也不支持后行断言 (? 或 <code>(?。你复制粘贴网上“高级正则教程”里的断言写法，99% 会匹配失败——不是语法错，是引擎压根不认。
常见错误现象：输入 foo(?=bar) 搜不到任何内容，甚至面板报错或静默忽略；想用 (? 提取等号后的数字，结果全空。
- 替代方案只有锚点 + 显式捕获：比如要匹配“后面紧跟 bar 的 foo”，改写成
foo(bar)，然后替换时只用$1引用 bar，或保留整个匹配再加工 - 想“只改后面部分不碰前面”，例如把
class="btn"改成class="btn primary"，不能靠(?，得写 <code>class="(btn)"→ 替换为class="$1 primary" - 跨行场景更危险：断言在 Sublime 中一旦启用
(?s)，行为更不可控，建议直接放弃，改用分步匹配
^ 和 $ 是行级锚点，不是文档级
^ 和 $ 在 Sublime 中默认绑定到每行的开头和结尾，不是整个文件的起始/终止位置。这意味着 ^abc$ 只能匹配单独成行的 abc，不会匹配 xyz
abc
123 中的 abc 行——这点没问题；但问题常出在 Windows 换行符
上：$ 实际停在
前，导致看似“没匹配到行尾”。
- 安全写法：用
^s*abcs*$而非^abc$，显式吃掉可能的空白 - 跨平台兼容：结尾强制声明边界，如
^#.*(?= ? |$)，避免 - 真要锚定全文？用
A和Z（v4+ 支持），但仅限单文件、小文本；全局替换（Ctrl+Shift+F）中无效
为什么 单词边界经常失灵
在 Sublime 中按 Unicode 字符边界判断，但对中文、emoji、下划线连接符（如 user_name）识别不稳定。比如搜 name，可能匹配不到 user_name 中的 name，因为下划线被视作单词字符；也可能误匹配 username 中的 name，因缺乏明确分隔。
- 比
更稳的是显式界定：用(? —— 但注意，这个写法本身含断言，Sublime 不支持，所以只能退化为 <code>[^a-zA-Z0-9_]name[^a-zA-Z0-9_]，再手动处理首尾边界 - 纯英文变量名场景：优先用
WnameW（W匹配非单词字符），但需确认前后是否允许空格或括号 - 中文文本中完全弃用
：直接用(^|[^\u4e00-\u9fa5a-zA-Z0-9_])name([^\u4e00-\u9fa5a-zA-Z0-9_]|$)，并确保启用了 Unicode 支持（默认已开）
真正能用的“伪断言”技巧：用捕获组 + 替换控制范围
Sublime 虽不支持断言，但可通过捕获组设计，让“匹配内容”和“操作目标”分离，实现类似效果。核心逻辑是：把你想保留的上下文包进 ()，把要修改的部分也包进另一组，替换时只动后者。
- 删掉注释前的空格但不动代码：原内容
// comment，想变// comment。查找：^(s*)(//.*)$，替换：$2——$1是空格组，$2是注释行，丢弃前者 - 给所有未加引号的 key 补双引号：如
name: value→"name": value。查找：^(s*)([a-zA-Z][a-zA-Z0-9]*)(s*:)，替换：$1"$2"$3 - 提取 JSON key 后插入字段：匹配
"id": 123并在后面加,"status":"ok"。查找：("id":s*d+)，替换：$1,"status":"ok"
这种写法没有魔法，但可靠——它不依赖引擎特性，只靠 Sublime 最基础的捕获组和 $n 引用，哪怕在最老版本里也成立。
