search.include 仅对当前工作区生效，必须配置在项目级 .vscode/settings.json 中；全局 settings.json 无效，且值必须为 true（非字符串），路径需用 ${workspaceFolder}。
search.include 只对当前工作区生效，别往全局 settings.json 里写
想让某个项目只搜 src 和 include 目录？必须把配置放在那个项目的 .vscode/settings.json 里。写进用户级的 settings.json（比如 %APPDATA%\Code\User\settings.json）完全无效——search.include 不支持全局覆盖，它只响应工作区设置。
常见错误现象：改完全局配置，Ctrl+Shift+F 还是扫完整目录，甚至报错 Invalid configuration for "search.include"。
-
search.include的键必须是 glob 路径，值只能是true（不能写"true"字符串） - 路径里用
${workspaceFolder}，别硬编码绝对路径（如D:/Projects/MyApp/src/**），否则换机器就失效 - 如果同时设了
search.exclude和search.include，前者优先级更高——排除规则会先执行，再从剩余范围里按 include 筛选
search.exclude 和 files.exclude 的作用完全不同，别混用
search.exclude 只影响 Ctrl+Shift+F 的全局搜索；files.exclude 控制资源管理器里“看不见哪些文件”，也间接影响搜索（因为被隐藏的文件根本不会被索引）。两者都用 glob，但生效场景不同。
容易踩的坑：
- 只配
files.exclude却没配search.exclude：资源管理器里看不到node_modules，但 Ctrl+Shift+F 还是会扫它（尤其当你没关search.useIgnoreFiles时） - 误把
**/dist写成/dist：后者只排除根目录下的dist，而前者才匹配所有层级 -
search.exclude里加"**/*.log": true有效，但"*.log": true只匹配当前目录下的 log 文件，深层日志仍会被搜到
多根工作区下，每个文件夹要单独配 .vscode/settings.json
VS Code 打开多根工作区（多个文件夹并列）时，每个子文件夹的搜索行为是独立的。你不能指望在最外层建一个 .vscode/settings.json 统管全部——它只对“最外层工作区”本身生效，子文件夹默认继承全局设置。
正确做法：
- 进入每个子文件夹（比如
frontend/、backend/），分别创建自己的.vscode/settings.json - 在
frontend/里配"search.include": {"${workspaceFolder}/src/**": true} - 在
backend/里配"search.include": {"${workspaceFolder}/app/**": true, "${workspaceFolder}/lib/**": true} - 别偷懒用
${workspaceFolder:frontend}这种变量——它只在终端terminal.integrated.cwd里有效，search.include不认
正则和大小写开关实际影响搜索性能，不是可有可无的选项
search.usePCRE2 开启后，VS Code 会启用更重的正则引擎；search.caseSensitive 设为 always 会让索引逻辑绕过小写归一化步骤。这两项看似只是“匹配更准”，实则直接改变底层扫描方式。
实测影响（中型 C++ 项目，约 1.2 万文件）：
- 关闭
search.usePCRE2，搜getData耗时 0.8s；开启后搜get\w+Data耗时 2.3s -
search.caseSensitive: "always"比"auto"快约 15%，因为跳过了大小写转换开销 - 真正卡顿的根源常是
search.exclude没配好——比如漏掉了"**/build/**"，导致每次搜索都硬扫几万个编译中间文件
复杂点在于：这些配置项之间存在隐式依赖。比如 search.useIgnoreFiles（是否读取 .gitignore）开着，但 search.exclude 里又手动写了 "**/node_modules"，结果就是重复过滤，徒增解析负担。该关就关，别叠 buff。
