sublime搜索大日志卡住主因是堆内存爆满而非cpu慢，需禁用index_files、auto_complete_size_limit和find_in_files_exclude三项配置，并配合viewport_size:5000与large_file_size_limit:100协同控制内存，超2gb应改用less/grep等专用工具。
为什么搜索大日志时卡住，不是CPU慢而是堆内存爆了
Sublime Text 4 默认用全内存加载 + 正则预编译做查找，1.2GB 日志里搜 ERROR，它会把整个文件读进堆、对每行跑一次 re.compile()，瞬间吃光 2GB 内存然后冻结。这不是“慢”，是 JVM 式的 OOM 前兆——你看到的卡顿，其实是 GC 频繁触发或主线程被阻塞。
必须关掉的三项搜索相关配置
这些不是可选项，是防止搜索阶段触发内存雪崩的硬开关：
-
"index_files": false：关掉后Ctrl+Shift+F全局搜索不会预建全文索引，改用流式逐块扫描；但注意，Ctrl+F当前文件内搜索仍可用，只是不支持“匹配所有”跨文件跳转 -
"auto_complete_size_limit": 0：设为0禁用自动补全对大文件的试探性扫描，否则搜到一半它偷偷启动补全引擎，又拉起一个re.findall()实例 -
"find_in_files_exclude"配合"folder_exclude_patterns"：在项目设置里加"find_in_files_exclude": ["*.log", "*.dump"]，避免Ctrl+Shift+F误扫日志目录——哪怕你没打开那个文件，它也会在后台 mmap 扫描
搜索时怎么避免“点开就卡”，而要“点即查”
直接用 Ctrl+F 搜大日志，90% 场景下会卡在“正在准备高亮”阶段。真正快的方式是绕过 UI 渲染链：
- 先确保语法是
Plain Text（右下角点击 →Open all with current extension as… → Plain Text），否则正则引擎会尝试匹配语法 scope 规则 - 按
Ctrl+H打开替换面板，输入搜索词后，**不要点“Find All”**——它会把全部匹配行载入内存生成结果列表；改用Find（单次查找）+F3（向下跳转），走的是偏移索引，毫秒级响应 - 需要批量提取？终端里用
grep -n "ERROR" huge.log | head -50，再把行号粘回 Sublime 的Ctrl+P输入:123456直跳——比 UI 搜索快一个数量级
堆内存限制在哪调，以及为什么别乱动
Sublime Text 4 没有公开的 JVM 参数或 -Xmx 设置项。它的内存分配由 OS mmap 控制，所谓“堆限制”实际是 viewport_size 和 large_file_size_limit 协同作用的结果：
-
"viewport_size": 5000是关键：它限制每次渲染缓冲区长度，设太小（如1000）会导致滚动时频繁重分配 buffer；设太大（如默认100000）则搜ERROR时会把 10 万字符块全 load 进内存做正则匹配 -
"large_file_size_limit": 100单位是 MB，设为100后，超过该大小的文件在打开时自动跳过语法解析和符号索引，但搜索行为仍受 viewport 影响——所以必须两者共存 - 别碰
"enable_memory_mapping": true：这是默认开启的，手动加反而可能干扰 mmap 行为；实测关闭它会导致 800MB 文件加载失败
超 2GB 日志别硬扛搜索，less +/ERROR huge.log 或 awk '/ERROR/{print NR ": " $0}' huge.log 更稳——Sublime 的设计目标是编辑，不是 grep 替代品。
