根本原因是Sublime默认全量扫描项目所有子目录（含node_modules等），即使Where限定src/；必须关闭index_files并彻底重启，且Where需准确填写如src/或。
Why Ctrl+Shift+F 在大仓库里卡死或搜不到结果
根本原因不是磁盘慢，而是 Sublime 默认对整个项目（含 node_modules、.git、dist）做全量路径扫描和内容读取。哪怕你只在 Where 里写了 src/，它仍会先索引所有子目录——尤其当 index_files 开着时，后台进程已把几万文件塞进内存，搜索面板自然无响应。
常见现象包括：Find in Files 面板空白、进度条不动、点击 Find All 后右下角数字一直显示 0、双击结果打不开文件（路径解析失败）。
- 确认是否已添加项目：左下角状态栏必须显示类似
~/my-monorepo/的路径；单文件打开或拖拽未加项目的文件夹，Where填.也无效 - 检查
Where写法：不能写./src或src\；正确写法是src/（递归）或src/**/*.ts（显式通配） - 排除项必须用逗号分隔且带减号：
., -node_modules/, -dist/, -build/，斜杠统一用/
必须关掉 index_files，且要彻底重启
index_files 是性能瓶颈的根因。它不看 folder_exclude_patterns，也不管你有没有点开某个文件夹——只要该目录被加进项目，就强制扫描。关掉后 Ctrl+R（跳转符号）失效，但 Ctrl+Shift+F 和 Ctrl+P 完全不受影响，这才是大仓库下的合理取舍。
操作步骤：
- 打开
Preferences → Settings – User - 加入：
"index_files": false - 必须完全退出 Sublime（不只是关闭窗口），再重新启动——旧索引驻留在内存中，重载设置无效
- 验证是否生效：打开控制台（
Ctrl+`），输入sublime.active_window().folders()，若返回空列表，说明项目未加载；若返回路径但搜索变快，说明已生效
Where 输入框怎么写才既准又快
Where 不是“可填可不填”，它是全局搜索的执行范围开关。留空 ≈ 只搜当前已打开的标签页；填错 ≈ 搜不到任何东西。它的路径解析逻辑独立于 shell，也不补全，必须手写准确。
- 搜整个项目：填
.（仅一个英文点），不是./或./. - 限定 TypeScript 文件：
**/*.ts, !**/node_modules/**, !**/dist/**（注意双星号递归） - 用
<project></project>最稳：前提是已保存.sublime-project文件，它自动读取folders和file_exclude_patterns - Windows 绝对路径写法：
C:/myproject/src/（正斜杠），别用反斜杠；macOS/Linux 写/Users/name/project/ - 避免粘贴 Finder/资源管理器路径：含空格时没加引号会截断；复制前先手动加双引号包裹
替换前不看预览 = 主动制造回滚事故
Sublime 的 Replace All in Files 不校验语法上下文，只做纯文本替换。一个 user_id 可能出现在变量名、字符串值、注释、JSON key、甚至 package.json 的 scripts 字段里——它全不管你。
- 每次点
Replace All前，必须先点Find All，看右侧边栏列出的每一项：文件路径、行号、上下文三行预览 - 发现匹配在
"user_id": "123"里？立刻停手，改用正则"(? 排除引号内 - 看到匹配在
/* user_id deprecated */？说明Where太宽，应缩为src/api/**/*.js - 替换后立刻用原字符串反向搜索验证：
Ctrl+Shift+F→ 输入原词 → 看是否真无残留；别信“已替换 42 处”就收工
真正容易被忽略的是：Where 里写的路径是否和当前项目实际加载路径一致；index_files 关了但没重启；以及预览里那行看似无关的匹配，往往就是下次上线报错的源头。
