ctrl+shift+f搜索慢或卡住主因是sublime默认全量扫描node_modules等目录，需用where输入框实时排除（如., -/node_modules/, -/dist/），folder_exclude_patterns仅影响索引不控制搜索，binary_file_patterns可能误判文本文件导致漏搜。
Ctrl+Shift+F 为什么在大型项目里搜得慢甚至卡住
不是插件问题，是 Sublime 默认用内置引擎扫文件——它不跳过 node_modules、.git、二进制文件，也不做并发或增量索引。10 万行代码 + 5000 个文件时，UI 就会明显卡顿，甚至无响应。
实操建议：
- 立刻检查
Preferences → Settings – User中是否设置了"file_exclude_patterns"和"binary_file_patterns"，至少加上"node_modules/**", ".git/**", "*.log", "*.zip" - Where 框里别写
./，改用./src/**或./app/**/*.ts显式限定范围 - 禁用
Use Regular Expressions（除非真需要），正则匹配比字符串查找慢 3–5 倍 - 超大项目（>5 万文件）直接放弃 GUI，用命令行：
rg -n "search_term" --glob="*.py" | xargs -I {} subl "{}"
SearchInProject 插件怎么绕过 Sublime 内置搜索的短板
它不自己扫描，而是调用系统级工具（如 rg、ag、git grep），速度提升 10 倍以上，且天然支持跳过目录、按扩展名过滤、高亮上下文。
关键配置点：
- 安装后，在
Preferences → Package Settings → SearchInProject → Settings里设"search_engine": "rg"（推荐ripgrep，速度快、默认忽略 .gitignore） - 加
"search_args": ["--max-count", "1000"]防止结果爆炸卡死 UI - 若项目用 Git，可设
"search_engine": "git"+"search_args": ["grep", "-n", "--no-color"]，精准且稳定 - 插件默认把结果输出到新标签页，但大项目建议勾选
"output_to_panel": true，避免新建几十个标签拖垮编辑器
Find in Files 的 Where 栏到底该怎么写路径
不是 shell 路径，也不是 glob 全语法，是 Sublime 自己的轻量过滤规则，写错就等于没过滤。
常见写法与陷阱：
-
./src/**.js：只搜src下所有.js文件（注意双星号**表示递归） -
!./tests/**, !./dist/**：排除测试和构建目录（!开头表示排除，逗号分隔） -
./packages/*/src/**.ts：Monorepo 场景下匹配各包的 src 目录（单星号*只匹配一级目录） - 别写
~/project/src或绝对路径——Sublime 只认相对项目根目录的路径 - 路径里含空格？用引号包裹整个 Where 字符串：
"./my app/**.py"
批量替换前必须确认的三件事
Sublime 不提供“预览全部替换后效果”的界面，Replace All in Files 是原子操作，一旦执行无法跨文件撤回。
安全做法：
- 先点
Find All，看底部面板列出的匹配数是否合理（比如搜console.log却出来 2000+ 条，大概率要加Whole Word或限定文件类型） - 右键侧边栏中选中的几个文件 →
Find in Selected Files，小范围试替再放大 - 打开 Git 面板（
Ctrl+Shift+P→Git: Status），确保工作区干净；替换前 commit 一次，出错直接git checkout .
真正麻烦的不是找不到，是找得太多又替错了——尤其当正则里用了 .* 或 $1 却没验证捕获组边界时。
