sublime text 中后行断言（lookbehind）受限于定长模式要求，部分版本不支持变长 pattern，甚至报错“invalid look-behind pattern”，故推荐用 \k 替代：它丢弃此前匹配内容，只保留 \k 后部分，更可靠兼容。
Sublime Text 里根本不能用 lookbehind 断言？
对，(? 和 <code>(? 在 Sublime Text 的正则引擎（PCRE 8.32 左右版本）中**不被支持**，哪怕写进去也不会报错，但匹配行为完全不可靠——它可能看似生效，实则跳过、漏匹配，甚至干扰后续分组。这不是配置问题，是底层引擎限制。
常见错误现象：(? 想匹配美元符号后的数字，结果要么全不匹配，要么在某些行匹配到不该匹配的位置；用 <code>Find All 时高亮错乱。
- Sublime 使用的是较老的 PCRE 版本，且禁用了部分 Unicode 和断言特性
- 所有
(? / <code>(? 表达式会被静默忽略或降级为普通分组 -
(?=...)和(?!...)（前瞻断言）基本可用，但需注意贪婪性影响
用 \K 替代后瞻断言的实操写法
\K 是 Sublime 唯一可靠替代后瞻的方式：它会“丢弃此前所有已匹配的内容”，只保留 \K 之后的部分作为最终匹配结果。这能模拟 (? 的效果，但语法和逻辑完全不同。
比如想提取 JSON 中 "name": "xxx" 的值（不含引号），别写 (?（无效），改用：
"name": "\K\w+
说明：
-
"name": "必须完整匹配并消耗掉，\K把这部分从最终匹配结果中剔除 -
\w+才是真正被选中的内容，Find All或Replace都只作用于它 -
\K不能出现在交替分支开头（如(\Ka|b)会报错），也不能在字符类中使用
替换场景下如何安全处理多行与边界
当用 \K 做替换（例如批量清理日志前缀），容易因换行或空格导致匹配断裂。Sublime 默认不跨行匹配，且 . 不匹配换行符。
典型问题：想删掉每行开头的 [DEBUG] ，但有些行是 [DEBUG]\t 或带空格缩进。
- 启用
. matches newline（Alt+R→ 勾选.按钮），让.覆盖换行符（慎用，易过度匹配） - 更稳的写法是显式处理空白：
^\[DEBUG\][ \t]+\K.*$，配合^/$锚点 - 如果目标文本含中文或 Unicode 字符，避免用
\w，改用[^\s"]+等明确字符集 - 替换时若要保留换行结构，
Replace输入框里不要加\n，除非你确认原始匹配包含它
为什么不用插件或外部工具？
确实有插件（如 RegReplace）或调用 Python 正则，但它们绕过了 Sublime 原生查找面板，无法实时高亮、无法用 Ctrl+D 逐个选中、不能和 Ctrl+Shift+P 命令链联动。对日常编辑来说，原生 \K + 前瞻 + 显式锚点组合，已经覆盖 90% 的「伪断言」需求。
真正卡住的点往往是：忘了 \K 前必须有确定长度的匹配（不能是 * 或 ? 开头），或者把 \K 当成零宽断言去套用旧习惯——它不是断言，是重置匹配起点的操作符。
