Ctrl+Shift+F 搜索结果不显示上下文，是因为误用了 Ctrl+F（单文件搜索）而非多文件搜索模式；需确认快捷键正确、Where 输入框非空且为“.”，并配置 search_context_lines 控制预览上下文行数。
为什么 Ctrl+Shift+F 搜索结果没显示上下文？
默认情况下，Sublime 的 Ctrl+Shift+F（Find in Files）确实会显示上下文，但前提是：你必须用这个功能本身——单文件内 Ctrl+F 永远只显示匹配行，不带上下文。很多人误以为“开了搜索就该有”，结果点开面板只看到孤零零一行，其实是用错了入口。
常见错误现象：Ctrl+F 里输完词按回车，结果只有光标跳转，没树状列表、没上下文、没文件路径——这压根不是上下文问题，是根本没进多文件搜索模式。
- 确认快捷键是
Ctrl+Shift+F（Windows/Linux）或Cmd+Shift+F（macOS），不是Ctrl+F - 面板底部必须出现 “Where:” 输入框，且默认值通常是
.（当前项目）；如果这里空着或填了单个文件名，上下文可能被压制 - 搜索执行后，结果以折叠树形展示，每条匹配项默认带 1–2 行上下文；若完全没看到，大概率是配置缺失或搜索范围太窄（比如填了
./src/index.js而非.）
如何控制上下文显示几行？
Sublime 不提供界面开关，上下文行数由两个独立配置项控制，且作用范围不同——搞混就会调了也没反应。
search_context_lines 控制「每个匹配行上方和下方各显示几行」，只影响 Ctrl+Shift+F 面板里的结果预览；find_results_file_context_lines 则决定点击某条结果跳转到文件时，编辑器顶部是否展开上下文行（即打开文件后高亮匹配行并自动滚动显示周边内容）。
- 两者都需手动加到用户设置（
Preferences → Settings – User）中，重启搜索面板才生效 - 例如设
"search_context_lines": 2，每条结果占 5 行（上2 + 当前行 + 下2）；设"find_results_file_context_lines": 3，则双击结果跳转后，编辑器会把匹配行居中，并显示上下各 3 行 - 负数会被忽略，0 表示关闭上下文；超过 5 容易卡顿，尤其大项目里
- 这两个配置不支持 per-project，改了就是全局生效
正则跨行匹配为什么总失败？
因为 Sublime 默认的 . 不匹配换行符，^ 和 $ 也只锚定单行首尾——想搜“if (x) {\n return y;”这种跨行结构，不加修饰符永远匹配不到。
必须显式启用单行模式（(?s)），让 . 吃掉换行符；同时用 \n 或 \r?\n 显式写换行，比依赖 . 更可靠。
- 正确写法：
(?s)if\s*\([^)]*\)\s*{\s*return\s+[a-zA-Z_]\+;，开头(?s)是关键 - 更稳的做法：用
\r?\n替代.匹配换行，例如console\.log\(.*\)\r?\n\s*//表示 log 调用后紧跟注释行 - 别信“勾选 Regular Expression 就能跨行”——没
(?s)或显式换行符，正则引擎照样按行切片处理 - 测试时先点
Find看高亮：如果只亮了一小段，说明正则没跨过去；全亮了再点Find All或Replace
上下文里误匹配怎么办？
上下文本身不参与匹配逻辑，它只是“展示层”——真正决定哪几行被搜中的，还是你的正则或关键词本身。所以常出现“上下文看着对，但点进去发现匹配的是注释或字符串里的一段”。
这不是上下文的问题，是匹配精度不够。Sublime 没有语义分析，console.log 在 JS 代码里和 JSON 字符串里对它来说毫无区别。
- 限定上下文位置：用
^\s*console\.log\(.*\);?\s*$锚定整行，避免命中字符串内的子串 - 排除干扰区域：正则里加负向先行断言，如
(? 排除双引号前的匹配（注意 Sublime 正则引擎支持有限，复杂断言可能不生效） - 最简方案：先用
Ctrl+Shift+F搜出所有结果，扫一眼上下文，手动过滤掉明显不对的（比如上下文含"或/*），再针对性二次搜索 - 永远不要跳过
Find高亮预览——90% 的误匹配，都是在没看清高亮范围的情况下直接点了Replace
上下文行数调得再细，也救不了模糊的正则；而再精准的正则，没配上 (?s) 或显式换行符，也跨不过那一道 \n。
