search_context_lines 控制每条匹配结果的上下文行数而非总结果数，设为0仅显示匹配行，建议设1或0以提升响应速度；file_search_max_results才是限制总匹配条数的配置，默认10000，推荐设500–1000；find_in_files_max_bytes控制是否跳过超大文件，默认约10MB，设2147483647可覆盖多数场景；folder_exclude_patterns需写在.sublime-project的folders路径对象内才生效，改后须刷新文件夹。
search_context_lines 控制每条结果的上下文行数，不是总结果数
很多人误以为 search_context_lines 能限制“总共搜出几条”，其实它只管「每条匹配结果前后各显示几行」。设为 2，每条就占 5 行（上2 + 当前行 + 下2）；设为 0 就只显示匹配行本身，视觉更紧凑，扫视更快。
这个值对大项目搜索速度影响间接但真实：上下文越多，渲染开销越大，尤其结果密集时面板容易卡顿。建议设为 1 或 0，别贪多——你真正需要的是定位，不是整段代码。
-
search_context_lines必须写在Preferences → Settings – User的右侧面板里，写错位置（比如 Syntax Specific 配置）不生效 - 改完必须关闭所有已打开的搜索结果标签页，再按
Ctrl+Shift+F重新触发，否则旧结果不会刷新 - 负数或非整数会被忽略，配置无效；超过
10明显拖慢响应，尤其搭配高 DPI 屏幕时
find_in_files_max_bytes 决定是否跳过超大文件
默认情况下，Sublime 会跳过超过一定大小的文件（通常约 10MB），导致你在大项目里搜不到某些日志或数据文件。这不是“搜得慢”，而是直接被过滤掉了。
真正起作用的是 find_in_files_max_bytes，单位是字节。设为 2147483647（即 2GB）可覆盖绝大多数场景；设为 0 表示不限制，但可能引发内存压力。
- 该配置只影响
Ctrl+Shift+F全局搜索，不影响当前文件内Ctrl+F - 如果项目里有几十 GB 的日志目录，光调这个没用——得配合
folder_exclude_patterns排除整个路径，否则索引和扫描仍会拖慢 - 修改后无需重启 Sublime，但已有搜索面板需关闭重开才生效
file_search_max_results 是唯一真正限制总条数的配置
file_search_max_results 才是控制“最多返回多少条匹配”的开关。默认值通常是 10000，搜到第 10001 条就截断并提示“结果过多”。这对大项目很关键：避免一次搜出几万条把 UI 堵死。
设为 500 或 1000 更实用——先看前几百条，确认模式没问题，再缩小范围精搜。别设太小（如 10），否则容易漏掉真正要找的内容。
- 该值仅限制「显示条数」，不影响底层扫描逻辑；Sublime 仍会遍历所有文件，只是不展示超出部分
- 它和
find_in_files_max_bytes是两套机制：一个管“输出上限”，一个管“输入豁免” - 如果搜完发现结果少于预期，先检查是否被
file_exclude_patterns或binary_file_patterns过滤了文件类型
项目级排除比全局设置更安全有效
在大项目中，靠配置限制结果数量只是治标。真正提速要从源头减少扫描量——folder_exclude_patterns 必须写在 .sublime-project 文件里，且嵌套在 folders 数组的每个 path 对象下，写在用户设置里完全无效。
例如，想跳过 node_modules 和 dist，就得这样写：
{
"folders": [
{
"path": ".",
"folder_exclude_patterns": ["node_modules", "dist", "build"]
}
]
}
注意：folder_exclude_patterns 是跳过整个文件夹（不扫描目录结构），而 file_exclude_patterns 只跳过匹配的文件名（目录仍被索引）。两者别混用，也别指望单靠一个解决全部问题。
改完记得执行 Project → Refresh Folder，否则排除规则不会立刻生效。很多人大呼“怎么还不快”，其实是忘了这一步。
