ctrl+p比vs code quick open快一个数量级，因其不依赖后台索引进程，直接读取项目目录树实时模糊匹配；vs code默认启用文件监视和索引服务，首次加载大项目会卡顿。
Ctrl+P 为什么比 VS Code 的 Quick Open 快一个数量级
因为 Ctrl+P 不依赖后台索引进程，它直接读取当前项目目录树，用模糊匹配算法实时扫描文件名——没有预热、不占内存、不卡顿。VS Code 的 Quick Open 默认启用文件监视和索引服务，首次加载大项目时右下角会卡住几秒，尤其在禁用 search.followSymlinks 或挂载网络盘路径下更慢。
实测含 2800 个文件的 Vue 项目：Ctrl+P 输入 main 瞬间列出 main.js、MainLayout.vue、webpack.config.js；VS Code 同样操作得等索引进度条走完。
-
folder_exclude_patterns在 Sublime 中真正过滤索引范围（如["node_modules", "dist", ".git"]），而 VS Code 的files.exclude只影响侧边栏，不影响搜索性能 - Sublime 首次打开项目时构建内存索引，后续所有
Ctrl+P操作都在内存中完成，响应稳定在 100ms 内 - 输
dfmtjs或u/da/fd能命中src/utils/date/formatDate.js——这是子序列匹配，不是字符串包含
@ 符号跨文件跳转为什么需要 SublimeLSP
原生 @ 支持仅限当前文件内符号（Ctrl+R）或简单文件名+函数名组合（如 utils.js@formatDate）。但若 utils.js 里 formatDate 是导出函数、ES6 class 方法、或 TypeScript 类型定义，原生解析会失败——因为 Sublime 默认不解析 JS 语法结构，只靠文件名和正则粗筛。
这时候 SublimeLSP 插件就成为刚需：它把语言服务器协议接入编辑器，让 @ 真正理解作用域、导出方式、重载签名。没装它时输 api.ts@fetchUser 可能完全无响应，装了之后能精准跳转到 export function fetchUser() 定义处。
- 右下角语法标识必须是
JavaScript或TypeScript，不能是Plain Text，否则@功能直接失效 -
.env类文件搜不到？检查folder_exclude_patterns是否误写了[".*"]——这个正则会排除所有点开头文件 - CSS 中
@.container和 HTML 中@#header是原生支持的，不需要插件
# 关键词搜索为什么比 Ctrl+F 更适合上下文定位
# 是文件内全局内容搜索，但它不依赖光标位置、不打开替换面板、不打断当前编辑流——输入 main.js#error 直接弹出所有含 error 的行，点击即跳，且结果自带行号前缀。而 Ctrl+F 是局部查找，需手动滚动、翻页、切换匹配项，对快速扫读错误日志或配置项毫无优势。
-
config.json#api_url打开文件并高亮所有匹配行，比先打开再Ctrl+F快 3 秒以上 - 大小写不敏感，但字符串必须完整（
#err不会匹配error） - 组合使用更高效：
index.html:120定位行，index.html:120#submit进一步筛选该行附近含submit的上下文
为什么“搜不到”八成不是功能问题而是索引问题
Sublime 的 Goto Anything 不是“搜不到”，而是“没索引到”。常见原因就三个：index_files 被关了、项目没添加进侧边栏、或者 folder_exclude_patterns 过滤太狠。它不像 IDE 那样自动监听文件增删，索引只在项目加载时做一次快照。
- 确认是否已通过
Project → Add Folder to Project…添加根目录，单纯打开单个文件不会触发项目索引 - 检查设置里
"index_files": true是否被覆盖（某些插件或用户配置会设为false） - 隐藏文件（如
.gitignore）默认不索引，需手动加"file_exclude_patterns": []并清空排除列表 - 首次打开大型项目时
Ctrl+P卡顿是正常现象——索引正在构建，等右下角状态栏消失即可
真正的复杂点不在功能多寡，而在索引边界：它快，是因为不做多余事；它准，是因为你得告诉它哪些路径值得看。一旦路径和语法识别对了，Ctrl+P 就永远是那个按下去就到的入口。
