必须关闭语法高亮和行号：设 syntax 为 plain text，同时禁用 line_numbers 和 gutter；禁用 index_files、detect_indentation、highlight_line、draw_white_space、ask_before_opening_large_files；large_file_size_limit 设为 100；插件如 sublimelinter 和 brackethighlighter 需针对性禁用。
关掉语法高亮和行号，不是“可选”，是必须
语法高亮对巨型代码文件（比如 200MB 的 minified JS 或生成的 protobuf JSON）是性能黑洞：Sublime 会为每一行运行整套正则匹配、作用域堆栈、颜色映射，CPU 占用瞬间拉满；行号和 gutter 区则强制重绘每行 DOM 节点，滚动时直接卡成幻灯片。这不是“慢一点”，而是加载后根本无法响应鼠标和键盘。
-
syntax设为"Packages/Text/Plain text.tmLanguage"或直接在右下角点击语言名 → Open all with current extension as… → Plain Text - 必须同时关掉
line_numbers和gutter：只关一个没用，两者耦合渲染 - 别信“我只看一眼”，
Plain Text设置会按后缀继承，下次再开同类型文件就自动轻量加载
禁用五项后台扫描行为，否则“点了 Yes 还是卡”
很多人设了 large_file_size_limit 就以为万事大吉，结果打开仍卡死——因为 Sublime 默认仍会偷偷执行索引、缩进检测、空格绘制等操作。这些功能对代码文件有用，对巨型日志或打包产物毫无意义，却耗尽 CPU。
-
index_files: false —— 防止构建全文符号数据库，否则打开瞬间 CPU 100% -
detect_indentation: false —— 避免从头扫到尾猜缩进，巨型文件根本没结构可猜 -
highlight_line: false —— 当前行高亮纯属渲染负担，查问题不需要 -
draw_white_space: "none" —— 空格/制表符可视化在百万行文件里是灾难 -
ask_before_opening_large_files: false —— 否则弹窗只是幌子，后台进程照常启动
阈值设置要合理，单位错或设太小反而坏事
large_file_size_limit 单位是 MB，不是字节；设成 0 或负数会被 Sublime 忽略并回退默认逻辑（10MB）。设太小（如 50）会让日常 .json 或 .ts 文件也被误判降级；设太大（如 1000）又可能错过真正需要优化的文件。
- 推荐值：
"large_file_size_limit": 100—— 平衡点，覆盖绝大多数日志、dump、minified 产物 - 不要混用
large_file_size和huge_file_size：前者是轻量模式开关，后者仅影响警告提示，已过时且不生效 - 这个配置只对**新打开**的文件生效，已卡住的文件需手动关高亮+行号才能恢复
插件才是隐藏卡顿源，尤其 SublimeLinter 和 BracketHighlighter
即使你关掉了所有 UI 渲染和后台分析，某些插件仍会在文件加载完成后的几秒内触发全文件扫描：SublimeLinter 会调外部 linter，BracketHighlighter 会遍历所有括号对——它们不识别“大文件”概念，照常跑正则，导致界面冻结。
- 临时验证：命令行启动
subl --safe-mode /path/to/huge.js，如果流畅，说明是插件问题 - 精准禁用：在插件配置中加
"bracket_highlighter.ignore_syntaxes": ["Plain text"] - 最稳妥做法：只在真正需要编辑的小文件项目里启用 Linter 类插件，查看巨型文件时保持
--safe-mode或全局禁用
bundle.js 当成 main.py 在认真解析。关什么，比开什么重要得多。
