search.maxFileSize是控制内容搜索是否跳过文件的关键阈值，VSCode默认跳过>12.5KB文件（如bundle.js、大日志），静默不读取其内容；该限制仅影响文本内容匹配，不影响文件名搜索。
search.maxFileSize 是控制“内容搜索是否跳过文件”的关键阈值
VSCode 默认不搜索大于 12800 字节（约 12.5KB）的文件内容，这不是卡顿表现，而是静默跳过——你搜不到 dist/bundle.js 或大日志里的关键词，根本原因是它压根没读那文件。这个限制只影响「文本内容匹配」，不影响文件名搜索（点搜索框左上角 ^ 切换即可验证）。
调高它最直接：打开设置（Ctrl + ,），搜 search.maxFileSize，改成 5242880（5MB）或 0（不限制）。设为 0 要谨慎，尤其在机械硬盘或内存 ≤8GB 的机器上，首次全量搜索可能卡住几秒甚至无响应。
为什么改了 maxFileSize 还是卡？检查 search.useIgnoreFiles 是否真关掉了
很多人只调了 search.maxFileSize，却漏掉更常见的拦截项：search.useIgnoreFiles 默认为 true，它会按 .gitignore 规则直接过滤掉整批目录（比如 node_modules/、dist/），这些文件连大小判断环节都进不去——不是被“限大”，是被“拒之门外”。
- 临时验证：按
Ctrl+Shift+P→ 输入Search: Toggle Search Exclude Rules，禁用后重搜，若结果暴增，就坐实了这个问题 - 彻底关闭：编辑
.vscode/settings.json，确保包含这两行："search.useIgnoreFiles": false"search.useGlobalIgnoreFiles": false - 注意：关掉后
node_modules等目录会参与搜索，首次响应变慢是正常现象，不是配置失败
search.exclude 和 files.exclude 必须同时配，否则卡顿照旧
只设 search.exclude 不够——VSCode 仍会为被排除的目录建立文件监视器（watcher），导致 inotify 句柄耗尽、CPU 持续飙高；反之，只设 files.exclude，搜索时照样扫那些“看不见”的目录。
正确做法是在项目根目录的 .vscode/settings.json 中统一写：
{
"files.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/build": true,
"**/.git": true
},
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/build": true,
"**/*.log": true
}
}
注意：**/ 不能省略，写成 node_modules 或 node_modules/ 都无效；修改后必须重启窗口或删掉 .vscode/.search 文件夹，否则旧索引缓存继续生效。
真正卡住的点往往不在文件大小，而在你让 VSCode 干了不适合的事
VSCode 的搜索本质是本地倒排索引 + 内存加载，它不适合处理 GB 级日志或超长行 minified 文件。即使你把 search.maxFileSize 设到 0、关掉所有 ignore、清空缓存，面对一个 2GB 的 app.log，它依然会卡死或只返回前几十条。
此时更有效的路径是：
- 终端里跑：
rg -n "ERROR" app.log | head -20（需装ripgrep），速度比 Ctrl+Shift+F 快一个数量级 - 用
less +G app.log实时追加查看，或lnav做结构化分析 - 真要编辑：先用
split -l 50000 bigfile.log part-拆分，处理完再cat part-* > bigfile.log
别指望靠调一个参数解决所有卡顿——search.maxFileSize 只是其中一环，而最常被忽略的，是没意识到 VSCode 本就不是为“海量纯文本扫描”设计的工具。
