零宽断言在sublime中可用但需手动启用正则模式且禁用“. matches newline”，否则会干扰^/$锚点；中文边界应使用(?
零宽断言在Sublime里能用，但必须手动开.*且禁用“. matches newline”
Sublime 支持 (?=)、(?!)、(?、<code>(? 四种零宽断言，但不是“写上就生效”。它依赖两个前提：查找面板右下角的 <code>.* 图标已点亮（即正则模式启用），且不能勾选「. matches newline」——因为零宽断言本身不消耗字符，而开启该选项会干扰引擎对位置锚定的判断，尤其在跨行场景下容易导致 ^ 或 $ 锚点失效。
常见错误现象：^(? 查不到独立单词 <code>user，实际是因为 . matches newline 被误开，导致引擎把换行符也纳入上下文判断范围，破坏了 ^ 和 $ 的行边界行为。
- 安全做法：先关闭「. matches newline」，再用
(?m)显式启用多行模式，如(?m)^(? - 中文混排时，
\w无效，改用(? 更稳 (? 和 <code>(? 在 Sublime 中只支持**固定长度**的前缀匹配，不支持 <code>.*或\w+这类变长表达式；若需模糊前置，得改用^.*?user+ 手动筛选
匹配“非引号内”的关键词，零宽断言不如手动选区+Find All
想替换所有 log，但跳过 "console.log()" 或 'log error' 里的 log？别硬套 (? —— Sublime 的负向后行断言 <code>(? 对引号位置不敏感，且无法处理嵌套或转义引号（如 <code>"he said \"log\""）。
真正可行的路径是：先用 Ctrl+Click 或 Ctrl+D 选中所有代码区域（避开字符串高亮块），或执行 Ctrl+Shift+P → “Select Code”（需安装对应插件），再打开替换面板、点亮 .*，输入 \blog\b 并替换。这样既避开了语法解析盲区，又不会误触注释或模板字面量。
- 如果必须用正则限定范围，优先用
^[^"']*log[^"']*$匹配整行不含双引号的log，再人工复查 - JSON 或 JSX 文件中，引号类型混杂，建议直接用 Find in Files + Where 填
src/**/*.js,src/**/*.ts，缩小作用域 - 零宽断言在此类场景下容易“看起来对、实际漏”，每次替换前务必点
Find All看高亮是否全部落在预期上下文中
用 (? 和 <code>(?!\S) 替代 \b 处理中文/混合词边界
\b 在 Sublime 中对中文完全失效，且把下划线 _ 和数字都当单词字符，所以 \buser_name\b 会拆成 user 和 name 两段匹配。真正可控的边界是空白符锚定：(? 表示“前面不是非空白字符”（即前面是空格、换行或开头），<code>(?!\S) 表示“后面不是非空白字符”（即后面是空格、换行或结尾）。
例如把 user_name 改成 userName，查找填 (?，替换填 <code>$1，就能精准命中单词开头的下划线，避开 __init__ 或 user_name_ 尾部下划线。
- 注意
(? 不等价于 <code>^|，它还能匹配行首和制表符前，兼容性更强 - 如果目标词前后可能是全角空格（U+3000），得扩展为
(?，但更简单的是先统一清理空白符 - 这种写法在函数名重构中特别有用，比如
get_user_info→getUserInfo，可分两步：先(? → <code>$1，再(? → <code>$1 $2（加空格后手动删空格）
零宽断言配合 $1 替换时，捕获组必须在外层，不能藏在断言里
这是最隐蔽的坑：(? 看似能提取中间内容并用 <code>$1 替换，但在 Sublime 中，$1 只能引用**主匹配中的捕获组**，而断言内部的括号不参与编号。也就是说，上面这个表达式里 $1 是空的，因为 (\w+) 虽然被捕获，但它被包裹在正向先行断言中，Sublime 不将其计入全局捕获序号。
正确写法是把捕获组放到断言之外：prefix(\w+)suffix，再用 newprefix$1newsuffix 替换。如果 prefix/suffix 本身不该出现在结果里，就用非贪婪+显式排除：prefix([\s\S]*?)suffix → newprefix$1newsuffix，前提是 prefix/suffix 唯一且无嵌套。
- Sublime 不支持
(?:)非捕获组，所有()都占编号位，写错位置会导致$2指向错误内容 - 复杂结构如
/* comment */ function foo() { ... }，别试图用断言提取foo，应先用function\s+(\w+)\s*\(\)定位，再人工确认是否在注释外 - 真正难的从来不是写出断言，而是验证它是否在所有边界 case 下都只命中一次——比如行尾、空行、连续标点后，都要点开几个匹配项看上下文
