根本原因是pcre引擎回溯爆炸、跨行匹配未收敛及高亮预览拖慢响应；应先关闭highlight matches和auto expand selection，再通过ctrl+f验证查找逻辑、分段处理而非全量替换。
Sublime Text 对大文件（>5MB）做正则替换容易卡死、假死或漏匹配，根本原因不是正则写得不够强，而是引擎回溯爆炸、跨行匹配未收敛、高亮预览拖慢响应——直接上 .* 或 (a+)+ 类表达式，十有八九会无响应。
为什么大文件里正则一用就卡住？
Sublime 的 Boost regex 引擎对长文本的贪婪匹配极其敏感，尤其遇到嵌套量词、未限定范围的 .* 或跨行 . matches newline 时，回溯次数呈指数级增长。不是你电脑慢，是它在后台穷举所有可能路径。
- 现象：点击
Replace All后界面冻结 10 秒以上，状态栏显示“Searching...”但无进度 - 真实瓶颈：高亮预览（Highlight matches）和自动展开选择（Auto expand selection）在后台同步扫描全文件
- 更隐蔽的问题：UTF-8 无 BOM 的中文文件被误判为 GBK，导致正则匹配失败，但界面不报错，只显示“0 occurrences”
- 解决方案优先级：先关高亮 → 缩小作用域 → 拆解正则 → 最后才开跨行
如何安全地在大文件中执行正则替换？
别指望一次 Replace All 解决全部问题。真正可行的流程是“定位 → 验证 → 分段 → 替换”，把大文件当多个逻辑块来处理。
- 先用
Ctrl+F单独测试查找逻辑，确认命中数合理（比如 Ctrl+H - 关闭菜单 →
Find→ 取消勾选Highlight matches和Auto expand selection - 避免
.*开头：改用否定字符集，例如匹配双引号内容，用"([^"]*)"而非".*?" - 跨行操作必须加
(?s)前缀，且立刻跟上锚点，如(?s)function\s+\w+\s*{[^}]*?}，禁用.*?无限制匹配 - 替换前手动选中一段典型区域（比如 100 行），按
Ctrl+H→ 勾选In Selection，验证效果后再扩到全文
Where 字段填什么才能避开大文件陷阱？
全局替换（Ctrl+Shift+F）时，Where 不只是路径，更是性能开关。填错一个符号，可能让 Sublime 扫描整个 node_modules 里的压缩包。
- 想只处理大 JS 文件？填
./src/**/*.js，双星号**才递归，单星号*只匹配当前层 - 明确排除巨型文件：写
., -dist/, -build/, -*.min.js, -*.log，减号-必须紧挨逗号，不能有空格 - Windows 下路径仍用正斜杠
/，填C:\my\project会失效；大小写敏感，Src≠src - 留空
Where不等于全项目，它等价于“仅当前已打开的标签页”，极易漏文件
替换后文件没保存，不是 Bug 是设计
Sublime 从不自动保存被正则修改过的文件——所有改动都停留在内存标签页里。关掉未保存的标签页，修改直接丢弃。这不是疏忽，是防止误操作扩散的强制检查点。
- 执行
Replace All后，右下角状态栏不会提示“已保存”，只会显示文件名后多一个* - 批量替换完必须手动按
Ctrl+K→Ctrl+B（Save All），或逐个Ctrl+S - 更稳妥的做法：替换前先
git add -N .或至少git status确认工作区干净；替换后立刻git diff扫一眼变更是否符合预期 - 特别注意：
$1在替换框里必须写成$1，写成\1或${1}会原样输出字面量，大文件里这种错误很难肉眼发现
真正麻烦的从来不是怎么写正则，而是 Sublime 对回溯深度、编码识别、作用域边界的隐式约束——每次操作前花 10 秒验证 Find 是否命中，比事后调试快十倍。
