关掉语法高亮和行号渲染可立解卡顿：右下角选Plain Text临时切换，或在Syntax Specific设置中添加{"line_numbers": false, "gutter": false, "highlight_line": false}；同时必须设"word_wrap": false防超长行重算。
Sublime Text 打开大文件或编辑 Java 项目时卡顿，不是配置“少了”，而是默认开了太多它本不该在大文件里干的事。核心解决思路是：关掉语法解析、禁掉渲染负担、切断插件扫描、限制内存滥用。
怎么关掉语法高亮和行号渲染
这两项是打开 10MB+ 文件时最直接的卡点。语法高亮会逐行解析规则，行号区（gutter）要为每行计算坐标并绘制数字——百万行就是百万次渲染。
- 临时操作：打开文件后，右下角点击当前语法名 → Open all with current extension as… → 选
Plain Text - 永久生效：在
Preferences → Settings – Syntax Specific中，针对Plain Text或Log语法添加：{"line_numbers": false, "gutter": false, "highlight_line": false, "syntax": "Packages/Text/Plain text.tmLanguage"} - 别信
large_file_threshold自动降级——它只在首次加载时触发，且不覆盖已缓存文件的行为
为什么 word_wrap 开着会导致超长行卡死
日志、JSON dump、base64 编码块常出现单行数万字符。开启 word_wrap 后，Sublime 会在每次滚动、光标移动时反复重算软换行位置，CPU 占用瞬间拉满。
- 必须设为
"word_wrap": false（不是"true"或"auto"） - 顺带加
"wrap_width": 0，防止某些插件绕过word_wrap设置强行换行 - 如果只是查看，再加
"draw_white_space": "none"和"draw_indent_guides": false，进一步减负
Java 插件卡顿怎么调 JVM 参数
不是 Sublime 本身慢，而是你用的 Java 构建系统（比如 JavaC.sublime-build）调起的 javac 或 java 进程堆内存不足，频繁 GC 导致界面冻结。
- 找到对应构建系统文件（路径类似
Packages/User/JavaC.sublime-build） - 在
"cmd"数组中修改 java 命令，插入参数：-Xms512m -Xmx1024m - 示例片段：
"cmd": ["java", "-Xms512m", "-Xmx1024m", "-jar", "myapp.jar"]
- 别改 Sublime 主进程的 JVM——它不跑 Java，改了无效
插件才是隐藏的性能杀手
很多插件（SublimeLinter、GitGutter、BracketHighlighter）根本不识别“这是个大文件”，一加载就全量扫描、正则匹配、调外部命令，界面直接无响应。
- 诊断第一步：用
subl --safe-mode /path/to/bigfile.log启动，如果秒开，说明问题出在插件 - 全局禁用索引：
"index_files": false（写进用户设置），否则插件可能借道索引扫描整个项目 - 对非必要插件，直接加进
"ignored_packages"列表，例如："ignored_packages": ["Vintage", "SublimeLinter", "GitGutter"]
- 别依赖
folder_exclude_patterns拦插件——它只影响侧边栏显示，LSP 类插件照扫不误
真正难处理的不是“怎么配”，而是得记住：Sublime 的轻量是相对的。它没做 GB 级文件的流式加载，所有优化都是在“让它少干点事”。一旦文件超过 200MB，就得接受它只是个“能看能搜”的查看器，而不是编辑器——这时候 less、tail -f 或专用日志工具才是正解。
