VSCode不支持真正跨行正则搜索，search.resultLimit限制匹配条数而非行数，实际多行匹配受search.maxFileSize、search.useIgnoreFiles及引擎限制共同影响。
search.resultLimit 控制的是“已进入搜索流程”的结果条数，不是行数
VSCode 没有“多行搜索的最大行数”这个配置项——它不按「匹配内容跨几行」来限制，而是按「匹配行的数量」统计。比如 foo\nbar 在单个文件中被正则 foo.*bar 匹配到，算作 1 条结果（哪怕实际跨度 2 行），计入 search.resultLimit 总数。
真正影响你能看到多少“多行匹配”的，是以下三点共同作用：
-
search.resultLimit：设太小（如默认 2000）会直接截断后续匹配行，不管是否属于同一多行上下文 -
search.maxFileSize：超大文件（默认 >12800 字节）内容被跳过，多行匹配根本不会发生 -
search.useIgnoreFiles：若目标文件被.gitignore排除，连读都不读，更别说跨行匹配了
多行正则搜索本身受限于 VSCode 的引擎能力
VSCode 内置搜索用的是基于行的文本扫描器，不支持真正意义上的跨行正则捕获（例如 (?s)foo.*bar 中的 (?s) flag 会被忽略）。它只对单行内容做 RegExp.exec()，然后靠前后行手动拼接上下文显示。
这意味着：
- 你写
^error.*\n.*stack这类带换行符的模式，实际不会命中——VSCode 把每行当独立字符串处理 - 要查堆栈、日志块等多行结构，必须用
rg或grep -A 2 "error"这类原生命令 - 即使
search.resultLimit设为 0，也无法绕过这个引擎限制；它只是让你看到更多“单行匹配”，而非更多“跨行片段”
想查真正的多行内容？别硬扛 VSCode 搜索面板
搜索面板 UI 本身就有渲染上限：后端返回 5000 条匹配，前端通常只展开前几百条，其余折叠成「… and N more」。这不是配置能调的，是性能妥协。
实操建议：
- 终端执行：
rg -n -A 3 "error"（显示匹配行 + 后 3 行），或rg -n -B 1 -A 2 "timeout"精确控制上下文行数 - 把日志重定向到文件：
python app.py > log.out 2>&1，再用 VSCode 打开log.out，配合 Ctrl+F 手动滚动查块 - 对固定格式日志，用
lnav或less +G更可靠；VSCode 不是日志分析工具
容易被忽略的关键点
很多人调了 search.resultLimit 就以为万事大吉，但真正卡住多行场景的，往往是 search.useIgnoreFiles 和 search.maxFileSize 这两个静默拦截器——它们让文件压根不进搜索流程，连“单行匹配”都不会产生，更别说多行了。而且，VSCode 永远不会告诉你“这文件太大/被忽略了”，只会安静地少显示结果。
