search.maxFileSize是控制单文件内容搜索的开关，VSCode默认跳过大于12800字节（约12.5KB）的文件内容，静默跳过不提示；它只影响内容搜索，不影响文件名搜索；设为5242880（5MB）可覆盖多数打包产物，设为0表示不限制但可能卡顿；与files.maxMemoryForLargeFilesMB无关，后者控制大文件打开行为而非搜索。
search.maxFileSize 是控制单文件内容搜索的开关
VSCode 默认跳过大于 12800 字节（约 12.5KB）的文件内容搜索，这不是警告或提示，而是静默跳过——哪怕文件路径没被 search.exclude 拦住，内容也根本不会参与匹配。你搜 bundle.js 或大日志时“明明有却找不到”，大概率卡在这儿。
它只影响「内容搜索」，不影响「文件名搜索」（点击搜索框左上角 ^ 图标可切换）。修改后必须重新触发搜索，缓存不自动刷新。
- 设为
5242880（5MB）可覆盖绝大多数打包产物 - 设为
0表示不限制，但可能卡顿，尤其在机械硬盘或内存 ≤8GB 的机器上 - 别设太高（比如 50MB+）：VSCode 是单进程 Electron 应用，无内存隔离，OOM 风险陡增
为什么关了 search.useIgnoreFiles 还搜不到大文件里的内容？
即使 search.useIgnoreFiles 设为 false，search.maxFileSize 仍独立生效。二者是并列过滤层：前者决定“哪些文件进队列”，后者决定“进队列的文件里哪些读内容”。常见误判是以为关掉 ignore 就万事大吉，结果大文件仍被截断。
验证方式很简单：打开一个已知含关键词的 20KB 文本文件（如手动创建的 test-big.txt），搜索关键词。若搜不到，且该文件不在任何 exclude 规则中，基本就是 maxFileSize 在起作用。
- 检查当前值：
Ctrl + ,→ 搜索search.maxFileSize - 临时调高后，务必按
Ctrl + Shift + F重输关键词再搜，不能只点放大镜图标 - 注意：某些插件（如 Log Viewer）会接管文件类型，导致 VSCode 不走默认搜索流程，此时该设置无效
和 files.maxMemoryForLargeFilesMB 完全不是一回事
files.maxMemoryForLargeFilesMB 控制的是「编辑器打开大文件时是否启用只读轻量模式」，和搜索无关。它生效标志是状态栏显示 Large file mode (read-only)；而 search.maxFileSize 纯属后台扫描逻辑，不改变 UI 渲染，也不影响能否打开文件。
混淆这两者会导致改错地方：比如你把 files.maxMemoryForLargeFilesMB 调到 4096，结果搜索还是找不到 dist/app.js 里的字符串——因为那文件压根没被读内容。
-
files.maxMemoryForLargeFilesMB：影响“打开”行为，单位 MB，值太大会拖慢启动 -
search.maxFileSize：影响“搜索”行为，单位字节，值太大会拖慢单次搜索响应 - 二者可共存，但职责分明，不能互相替代
真正卡住的点，常是你在用编辑器干查看器的活
VSCode 的搜索设计目标是辅助代码导航，不是全文检索引擎。当你要从 GB 级日志里捞几条记录，硬调高 search.maxFileSize 并非最优解——它会强制读取整份内容进内存，UI 卡顿、内存飙升、甚至触发系统 OOM Killer。
更实际的做法是分层处理：
- 先用终端跑
rg -n "关键词" --max-file-size 10M *.log（需装ripgrep），速度快、结果准、无 UI 压力 - 或用
head -n 10000 huge.log | grep "关键词"预筛后再开 - 如果必须在编辑器内操作，把大文件移到单独文件夹，用
Ctrl+Shift+F搜索时在右下角「Files to exclude」临时填!./target-folder/**反向限定范围
记住：限制不是为了阉割功能，而是让工具在合理边界内保持响应。盲目调高阈值，往往换来的是更难诊断的卡顿和崩溃。
