vscode中文搜索慢的根源是未排除node_modules、dist等目录，导致大量中文文件被重复解码；必须正确配置search.exclude为"/node_modules/"等glob规则，并同步设置files.watcherexclude，修改后需重载窗口生效。
VSCode 中文搜索本身不慢，慢的是它在 node_modules、dist、.git 这些目录里逐个打开并解码 UTF-8 或 GBK 文件——尤其是含中文的 .log、.md、.js 文件，解码开销会翻倍。真正该配的不是“中文支持”，而是让 VSCode 别去碰那些根本不用搜的路径。
search.exclude 配错路径，中文搜得更慢
很多人加了 "node_modules" 或 "node_modules/**"，结果没生效，VSCode 还是照扫不误。原因就一个：glob 模式写法不对。
-
"**/node_modules/**"✅ 正确：匹配任意层级下的node_modules目录及其全部子内容 -
"node_modules"❌ 无效：不带通配符前缀，VSCode 当作字面路径处理，找不到 -
"**/node_modules"⚠️ 半生效：能跳过目录本身，但里面node_modules/foo/index.js还可能被读（尤其遇到符号链接或缓存残留） - 中文文件若在未排除目录中，且编码非标准 UTF-8（如 GBK），单文件解析可能卡 200ms+，叠加成千上万文件，延迟直接上秒级
files.watcherExclude 不配，搜索前就卡住
search.exclude 只管“搜的时候不读”，不管“启动时监不监听”。而 files.watcherExclude 才是让 VSCode 彻底放弃注册这些路径的监听器——否则 CPU 一直 20%+，搜索面板还没点开，后台已经在狂扫 node_modules 了。
- 必须和
search.exclude写一致："**/node_modules/**"、"**/dist/**"、"**/.git/**" - 特别注意
.next、target、out这类构建目录，它们常含大量 JSON/JS 文件，watcher 负载比node_modules还高 - 大日志文件也要防：
"**/*.log"是基础，但若存在app.log.20260531.gz，还得加"**/*.gz"，否则 watcher 会尝试解压探测
中文项目要额外排除的文件类型
中文命名的文件、含中文注释的代码、Markdown 文档，本身没问题；但一旦混在未排除目录里，就会放大 I/O 和解码压力。尤其要注意：
-
"**/*.md"：很多团队把中文文档放根目录或docs/，但若没排除，每次搜索都扫一遍几百 KB 的文档 -
"**/CHANGELOG*.zh-CN.*"或"**/README*.zh.*"：这类文件名带语言标记，容易漏配，建议统一用"**/README*"+"**/CHANGELOG*" -
"**/locales/**"：i18n 资源目录，JSON 文件多、重复键多，不排的话搜索关键词常命中几十个无意义的翻译项 - 避免用
"**/zh-cn/**"这种写法——大小写敏感，Windows 下可能失效；优先用"**/locales/**"这类稳定路径
改完配置不重载，等于没配
VSCode 不会热重载 search.exclude 或 files.watcherExclude 的变更。你保存了 .vscode/settings.json，但没动作，旧索引和 watcher 实例还在跑。
- 必须执行 Developer: Reload Window（快捷键
Ctrl+Shift+P→ 输入并回车），不能只关再开窗口 - 如果仍搜到
node_modules里的结果，打开开发者工具（Ctrl+Shift+I），在 Console 里运行：console.log(require('vscode').workspace.getConfiguration('search').exclude)，确认实际生效的规则是不是你写的 - 工作区配置（
.vscode/settings.json）优先级高于用户设置，团队项目务必放这里，别指望每人手动配
最常被忽略的一点：排除规则不是“加得越多越好”。过度使用 **/*.log 这类宽泛模式，反而会让 glob 匹配引擎变慢；真正要砍的是明确知道不需要参与搜索的路径，比如 node_modules，而不是靠模糊匹配赌运气。
