VSCode全局搜索结果无默认展开层级设置，文件节点默认全部展开，所谓“折叠”实为前端性能限制或手动点击收起的临时状态，与editor.foldLevel等配置无关。
VSCode 搜索结果没有“默认展开层级”设置
VSCode 的全局搜索（Ctrl+Shift+F）结果面板本身不提供类似 search.resultExpandLevel 这样的配置项，也没有“只展开匹配行、不展开文件”的层级开关。它只按文件 → 匹配行两级结构渲染，且默认**全部展开文件节点**——你看到的“折叠”其实是 UI 为性能做的被动裁剪，不是可配置的行为。
为什么搜索结果里有些文件是折叠状态？
这不是设置控制的，而是以下两种情况导致的视觉“折叠”：
- 后端实际返回了大量匹配，但前端渲染做了限制：即使搜出 5000 行，UI 只展开前几百条，其余显示为
… and N more—— 这是硬编码的性能保护，无法通过 settings 关闭 - 你手动点击了文件名左侧的三角箭头收起过，VSCode 会记住这个**单次交互状态**，但不会持久化、也不会影响下次搜索
注意：editor.foldLevel 或 workbench.tree.expandMode 对搜索结果面板完全无效，它们只作用于资源管理器（Explorer）和编辑器内的代码折叠。
真正能控制“看到多少内容”的实操手段
既然不能限制“展开层级”，就转而控制“让哪些内容进入结果”或“怎么高效提取全部”：
- 用
search.include白名单限定目录，比如只搜"${workspaceFolder}/src/**"，从源头减少文件数量，避免结果被撑爆 - 在搜索框里加
file:*.ts或type:javascript语法过滤文件类型，比靠 UI 展开/折叠更直接 - 点击搜索面板右上角
⋯→Copy All Results，能拿到全部匹配行（含路径+行号），绕过 UI 渲染上限 - 对超大项目，终端跑
rg -n "关键词"更可靠；VSCode 搜索本质是封装 ripgrep，但加了额外过滤和 UI 层，反而多一层不确定性
容易被忽略的关键点
很多人反复调 search.resultLimit 却发现结果还是卡在 20 条，其实是因为 search.useIgnoreFiles 默认开启，.gitignore 里写的 node_modules/ 直接让整个目录不参与搜索——不是结果被折叠了，是压根没算进去。检查右下角显示的「x files searched」数字，如果远小于预期，优先关掉 ignore 规则，而不是折腾展开逻辑。
