sublime text 的零宽断言需满足定长限制，(?≤4字)有效而 (?
Sublime Text 的正则查找替换支持完整的 PCRE 风格零宽断言，但默认开启的「. matches newline」选项和不显式启用 re.DOTALL 等行为，会让新手误以为 (? 或 <code>(?!...) 失效——其实多数时候是位置没对、引擎限制或边界没锁死。
Sublime 中负向后行断言 (? 为什么常不生效
Sublime 使用的是基于 PCRE 的正则引擎（具体为 Oniguruma），它支持 (?，但有硬性限制：后行断言中的 <code>pattern 必须是**定长**（fixed-width）。也就是说，(? 合法，而 <code>(? 会直接报错「Invalid regular expression」。
- 错误写法：
(? → 因 <code>http（4 字符）和https（5 字符）长度不等，引擎拒绝解析 - 正确写法：
(? 或 <code>(?，确保所有分支长度一致 - 若必须匹配变长前缀，得换思路：用
^(?!.*pattern).*$先行断言做行级过滤，再配合普通匹配 - 注意 Sublime 的「Find in Files」对话框里，勾选「Regular expression」后，
(? 才真正启用；未勾选时所有 <code>?都被当字面量处理
用 (?!pattern) 安全提取非注释行中的关键词
比如想批量把代码中非注释行里的 print 替成 logging.info，但跳过 # print... 或 // print... 这类行。关键不是“避开整行”，而是“避开注释符号之后的位置”。
- 可行正则：
^(?!(?:\s*#|\s*//)).*(\bprint\b)，先用先行断言否定以注释开头的行，再捕获print - 更精准写法（推荐）：
(?，但需确认 Sublime 当前文件编码无 BOM 干扰，且空格数严格匹配 - 实际替换时，
$1捕获组比\1更稳定；Sublime 的 Replace 框支持$1、$2，不支持\g - 性能提示：在大文件中慎用
^.*$类贪婪匹配 + 断言组合，容易触发回溯膨胀；优先用[^\n]*代替.*
零宽断言在 Sublime 多行替换中的边界陷阱
Sublime 默认关闭「. matches newline」，所以 (? 在单行文本里能正常提取价格，但若金额跨了两行（如 <code>$\n19.99），就会失败——因为 \n 不被 . 匹配，断言位置自然断开。
- 解决方法一：勾选「. matches newline」，再用
(?（<code>[\s\S]显式覆盖换行） - 解决方法二：不用后行断言，改用
\$\s*(\d+\.\d{2})，把$当普通前缀捕获，替换时用$$1表示字面$+ 数值 - 特别注意：Sublime 的「Replace All」对多行匹配结果是逐块处理的，不会跨 Replace 操作维护上下文，因此
(? 这类依赖行首的断言，在多行模式下可能意外命中中间行 - 验证技巧：先用「Find All」看高亮是否符合预期，再点 Replace —— 很多“替错了”其实是 Find 阶段就没圈对范围
真正难的不是写出一个能跑的断言，而是判断它在哪种文件结构、哪种勾选项组合、哪种换行符（\r\n 还是 \n）下依然稳定。Sublime 不报错，只静默跳过不匹配项，这点最容易让人误以为逻辑没问题。
