sublime text全局搜索where框仅支持shell glob通配符（如、、?、[abc]），不支持正则；仅匹配当前目录，才递归；多路径须用英文逗号加空格分隔；排除路径需写-/node_modules/；单文件模式下where无效；index_files设为false可提升性能。
Sublime Text全局搜索的Where框支持通配符，但不支持正则
是的，Ctrl+Shift+F（Windows/Linux）或 Cmd+Shift+F（macOS）打开的全局搜索面板中，Where 输入框明确支持 Shell glob 风格的通配符，比如 *、**、? 和 [abc]。但它**完全不识别正则语法**——写 api.*\.js 或 src/.+\.ts 会当字面字符串处理，基本搜不到东西。
常见误操作是把文件名搜索（Ctrl+P）和内容搜索（Ctrl+Shift+F）的规则混用：前者支持 main.* 匹配 main.js 和 main.py，后者也支持类似写法，但路径层级逻辑更严格。
-
*只匹配当前目录下的一级文件/文件夹，src/*.js不会命中src/utils/api.js -
**是递归通配，src/**/*.js才能覆盖所有子目录（Sublime Text 4+ 原生支持；ST3 需开启use_regex并配合正则模拟，不推荐） - 多路径用英文逗号分隔，且**逗号后必须跟一个空格**：
src/**/*.js, tests/**/*.py✅；src/**/*.js,tests/**/*.py❌（后者整个被忽略） - 排除路径必须加
-前缀 + 正斜杠结尾：-/node_modules/, -/dist/；写成-node_modules或-/node_modules（缺/）都无效
通配符在文件名搜索（Ctrl+P）和内容搜索（Where）中的行为差异
Ctrl+P 的模糊路径匹配走的是前缀匹配 + 通配符扩展，而 Where 框走的是 glob 路径解析引擎，二者底层不共享逻辑。这意味着：
-
Ctrl+P输入util/会优先显示util/目录下的入口文件（如util/index.js），这是 UI 层优化，Where框里写util/就真的只搜这个文件夹 -
Ctrl+P支持api*test*.py，Where也支持，但Where中api.*test.*\.py会被当普通字符串，因为点号.在 glob 里不是通配符，只是字面点 -
Ctrl+P不区分大小写（默认），Where框大小写敏感（Linux/macOS 下Node_modules≠node_modules）
为什么写了通配符却搜不到预期文件？几个关键卡点
最常被忽略的不是语法写错，而是环境前提没满足：
- 必须已通过
File → Open Folder加载项目根目录；单文件模式下Where框即使填了./src/**/*.js也无效，Replace All按钮直接灰掉 -
folder_exclude_patterns对Where搜索**完全无影响**——它只控制索引和侧边栏显示，别指望改这里能“让 node_modules 参与搜索” - 想搜被排除的目录（如
node_modules），不能靠删配置，得在Where里显式写node_modules/或./node_modules/（末尾加/更安全，避免匹配同名文件） - 路径开头的
.表示项目根目录，但./src和src效果一样；而src/和src有区别：src/强制匹配文件夹，src可能匹配到src.txt
通配符性能隐患：什么时候该关索引
通配符本身不慢，慢的是 Sublime 默认为每个文件建索引（"index_files": true）。一旦 Where 写成 * 或漏掉排除项，它就会硬扫 node_modules 里几十万文件——CPU 占满、搜索延迟秒级起步。
- 日常开发建议在
Preferences → Settings里设"index_files": false，尤其项目含大依赖时 - 清缓存可解临时卡顿：
~/.config/sublime-text-3/Index/（Linux/macOS）或%LOCALAPPDATA%\Sublime Text 3\Index\（Windows） - 真正要兼顾速度与精度，靠
Where显式限定比依赖索引更可靠：例如src/**.ts, types/**.d.ts，比*后手动过滤快得多
Replace All 前，花三秒确认 Where 框里没出现 node_modules，.* 图标是蓝色，以及 Find All 预览列表第一行是不是你真想改的地方。
