^和$在SQL迁移中不按行匹配，因默认正则模式下^仅匹配整个文件开头、$仅匹配结尾；需启用多行模式（Alt+M）、避免.匹配换行符，并注意Windows下用\R替代$更可靠。
为什么^和$在SQL迁移中不按行匹配
因为默认正则模式下^只认整个文件开头、$只认结尾，不是每行。比如想删掉所有INSERT语句开头的注释行--.*，写^--.*$却只命中第一行——根本没开多行模式。
必须手动启用：点击替换面板右下角的↩图标（或按Alt+M），让状态栏显示Regex且带m标识；Windows下$还容易停在\r前，直接用\R更稳。
- 关掉
.matches newline（即右下角不能有\n图标），否则^/$会退化 - 中文SQL文件若状态栏显示
GBK或Western，先File → Save with Encoding → UTF-8 with BOM - 测试时先点
Find All，看高亮是否覆盖所有目标行，再点Replace All
INSERT INTO转UPDATE时如何安全捕获字段与值
把INSERT INTO `t` (`a`, `b`, `c`) VALUES('1', '2', '3');转成UPDATE t SET a = '1', b = '2' WHERE c = '3';，难点不在正则本身，而在字段名和值的错位风险。
错误写法：INSERT INTO.*?\((.*?)\).*?VALUES\((.*?)\);——括号嵌套、引号内逗号、空格不一致都会导致$1和$2列数不对应。
- 先用
Ctrl+Shift+L把字段列表和VALUES两段分别转竖排，确保一一对应 - 字段行用
^`([^`]*)`提取，值行用^'([^']*)'提取（避免跨行，提前用Trim Trailing White Space） - 替换时用
$1 = $2拼接，但WHERE条件必须人工核对最后一项是否真该作条件——别全信位置 - 含函数的值如
CONCAT('a', 'b')，得先用正则(\w+\([^)]*\))临时标记，再处理其余部分
$1被当字面量输出的三个硬性前提
写(\w+)查到user_id，替换框填new_$1却输出new_$1而不是new_user_id，不是正则写错，是三个开关没同时打开：
- 查找框左下角
.*图标必须点亮（按Alt+R最可靠） - 右下角状态栏必须显示
Regex（不是Plain Text或Literal） - 替换框里只能写
$1，不能写\1或${1}（后者部分版本支持但不稳定）
编号严格按(从左到右顺序：比如((\w+))中$1是整个双括号内容，$2才是内层\w+；Sublime 不支持(?:)非捕获组，所有(都占位。
大文件卡死时怎么分步做正则迁移
超50MB的SQL迁移脚本，一开. matches newline就假死，不是配置问题，是Sublime内存映射限制。强行操作只会崩溃或漏改。
- 先关闭所有插件，尤其
GitGutter、BracketHighlighter（Preferences → Package Control → Disable Package） - 用
Ctrl+Shift+F跨文件搜索定位范围，比如搜INSERT INTO `orders`，限定只处理这个表 - 把匹配块复制到新tab，再开正则；拆分逻辑：先提字段名，再提值，最后拼UPDATE——别一步到位
- 每步操作前必点
Find All，确认命中数合理（比如字段数=值数）；替换后立刻Ctrl+Z回退检查几处
真正危险的不是正则写错，而是批量操作时没校验上下文——比如WHERE条件里也有user_id = '123'，和字段名同名，靠位置对齐或简单AS替换会误伤。
