Search搜不到修改的代码是因为默认不搜索未保存文件、.gitignore排除路径及二进制文件；需检查Files to include/exclude、search.exclude设置，并用Ctrl+P确认文件是否被索引。
为什么 Search 选项卡搜不到你改过的代码
因为默认不搜索未保存的文件、被 .gitignore 排除的路径，以及二进制文件（比如 node_modules 下的 .js 文件实际是构建产物，vs code 默认跳过）。你改了但没保存，或者文件在 search.exclude 里，search 就当它不存在。
- 按
Ctrl+Shift+F（Windows/Linux）或Cmd+Shift+F（macOS）打开搜索面板后，先看右上角是否显示Files to include或Files to exclude—— 这些字段不是摆设，填了就生效 - 想搜整个工作区，确保
Files to include是空的；如果填了src/**，那tests/下的匹配项直接被忽略 - 检查设置里的
search.exclude和files.exclude，常见坑是误把**/*.js加进去了，结果连你手写的index.js都搜不到 - 遇到“搜不到但明明有”，先试
Ctrl+P→ 输入文件名确认它是否被 VS Code 索引到了；搜不到文件，自然搜不到内容
search.usePCRE2 开关决定正则能不能写 \K 或 (?
VS Code 默认用的是 ripgrep，支持 PCRE2 子集，但部分高级断言（如可变长度的先行断言）需要显式开启 search.usePCRE2。不开，(? 这种想提取函数名的正则会报错 <code>invalid regex: look-behind assertion is not supported。
- 在设置中搜
usePCRE2，勾选它；或者直接在settings.json加一行："search.usePCRE2": true - 开启后支持
\K（重置匹配起点）、(? 和 <code>(?（但注意：PCRE2 的 <code>(? 仍要求固定长度，<code>(? 会失败） - 性能有代价：PCRE2 比 ripgrep 原生引擎慢，尤其全库搜大项目时，建议只在真需要复杂断言时开，平时关着
- 别混淆
search.useRipgrep—— 关掉它会退化到 Node.js 自带搜索，巨慢且不支持大部分正则特性
跨文件搜索时，files.associations 影响语法识别和高亮，但不影响搜索本身
files.associations 只控制编辑器如何解析文件（比如把 .conf 当成 nginx 语法高亮），对 Search 选项卡的文本匹配完全无感。搜不到内容，不是因为关联错了，而是因为文件根本没被纳入扫描范围，或内容被编码/压缩了。
- 如果你在搜一个自定义后缀（比如
.tpl）里的字符串，要确保它没被search.exclude或files.exclude屏蔽 - 确认文件是纯文本：用
file my-file.tpl（Linux/macOS）或Get-Content my-file.tpl -Encoding UTF8（PowerShell）验证是否可读；二进制或 BOM 异常会导致 ripgrep 跳过整文件 - VS Code 搜索不依赖语法树，只做字节流匹配，所以哪怕
.env文件没关联任何语言，只要没被排除，照样能搜API_KEY=
大项目搜得慢？优先调 search.followSymlinks 和 search.globalFindClipboard
真正拖慢搜索的，往往不是正则多复杂，而是 VS Code 在遍历符号链接或反复读剪贴板。尤其当你工作区里有 node_modules 软链到全局缓存，或习惯复制后立刻按 Ctrl+Shift+F，这两个开关就是瓶颈。
-
search.followSymlinks默认为true，意味着它会钻进每个软链接指向的目录——而pnpm或yarn的node_modules软链可能指向几百个包，搜一次等于扫千级目录 - 把它设为
false，再配合"search.exclude": {"**/node_modules": true}，速度立竿见影 -
search.globalFindClipboard默认开启，每次打开搜索面板就自动把剪贴板内容填进查找框——如果你刚复制了一段长 JSON，它会触发全文本预匹配，卡顿明显；关掉它，手动粘贴更可控 - 不用动
search.quickOpen或search.smartCase，它们对性能几乎无影响
search.exclude 默默过滤掉——这两点比所有正则技巧都关键。 
