.*? 并非绝对安全，需配合锚点、转义和作用域控制；无明确边界时仍会跨行吞内容、漏匹配或卡死。
Sublime 的 .*? 不是“加个问号就安全”，它只在特定边界内起效；没锚定、没转义、没控制作用域，照样跨行吞内容、漏匹配、卡死界面。
为什么 .*? 有时比 .* 更危险
非贪婪只是让 .*? 尽量少吃字符，但“少吃多少”完全取决于你给它的退出条件。没有明确的右边界，它就会一直吃到文件末尾——尤其在跨行场景下，. matches newline 一开，foo.*?bar 可能从第一行吃到最后一行。
- 常见错误：用
console.log((.*?))提取参数，结果匹配到console.log(a); console.log(b)中的a); console.log(b - 真正安全的写法是
console.log(([^)]*))：用[^)]*明确排除右括号，不依赖“最小匹配”逻辑 - HTML 标签内提取文本时，
<p>(.*?)</p>在换行存在时会失效（.默认不跨行），得配合[sS]*?或启用. matches newline - 匹配引号内容别用
"(.*?)"，遇到"a"b"会断在转义引号前；应改用"((?:[^"\]|\.)*?)
.*? 必须搭配的三个锚点
单独写 .*? 没意义，它必须被收束在可预测的左右边界之间，否则就是定时炸弹。
- 左边界用
、^、s或字面量（如fetch(）锁定起始位置 - 右边界优先用否定字符集：
[^"]*比.*?更稳；[^)]*比.*?更准；[^ ]*控制单行范围 - 跨行结构必须显式声明换行符：用
R（Sublime 内置通用换行符）替代$，或用[sS]*?替代.*?
全局替换时 .*? 的作用域陷阱
在 Ctrl+Shift+F 跨文件搜索中，.*? 行为和当前文件面板不一致：它不继承 . matches newline 设置，也不支持 $1 引用，所有捕获组在 Replace in Files 中都会被忽略。
- 想批量处理多文件中的非贪婪结构？先限定
Where路径（如src/**/*.js），再逐个文件打开用Ctrl+H替换 - 误在全局替换框里写
$1，结果所有匹配被替换成字面量$1——这不是 bug，是 Sublime 明确不支持 - 如果必须跨文件提取（比如拉出所有图片链接），用
Find in Files+)，然后手动复制结果，再进新文件用Ctrl+V粘贴整理
性能卡顿往往来自隐式跨行
大文件里一个没加限制的 .*? 就可能让 Sublime 停顿数秒——不是正则引擎慢，是它在反复回溯尝试所有可能的“最小长度”。
- 删空行别用
^s*?$（?对*无意义），直接用^s*$；s*本身已足够高效 - 清理 import 列表时，避免
^import.*?，改用^import[^ ]*：用[^ ]锁定单行，杜绝回溯 - 开启
. matches newline后，start.*?end在 10MB 日志里可能卡死；换成start[sS]*?end并确保前后有明确字面量锚点，能显著提速
非贪婪匹配真正的难点不在语法，而在你是否清楚“这个 ? 到底在让谁退一步”。每次写完 .*?，先问自己：右边最近的那个终止符，是不是一定能被它看到？如果不是，那就该换否定字符集或加锚点了。
