Sublime打开大JSON文件卡顿的根源是默认按可编辑模块解析，关语法高亮、自动换行、行号和后台索引四功能可解决90%问题；已卡死时用命令面板切Plain Text、关Word Wrap和Line Numbers，或safe-mode启动；须在Settings–User中配置index_files、detect_indentation、line_numbers等项，并用syntax-specific为.json文件设纯文本轻量模式。
Sublime 打开大 JSON 文件卡顿，不是文件太大，而是它正试图把 dump.json 当成可编辑的模块来解析——语法高亮逐行匹配括号、自动检测缩进、后台建索引、渲染百万级嵌套结构的行号和空格……关掉这四样，90% 卡顿当场消失。
怎么立刻让已打开的 JSON 文件恢复滚动
别等加载完，也别重启：按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入以下命令并回车：
-
Set Syntax: Plain Text—— 立刻终止所有语法解析和符号树构建 -
Toggle Word Wrap—— 防止超长单行 JSON（如 minified）反复计算软换行位置 -
Toggle Line Numbers—— 行号区重绘是卡顿常见源头，尤其光标悬停触发折叠按钮时
如果命令面板已无响应，终端执行：subl --safe-mode dump.json，跳过插件和用户设置，实测 1.2GB JSON 8 秒内可滚动。
为什么 large_file_size_limit 设了还是卡
这个配置只影响“新打开”的文件，且不改变 Sublime 的底层行为逻辑：
- 默认值是
10（单位 MB），设为100后，超过 100MB 的文件才启用轻量模式 - 但若
index_files仍为true（默认），它会在后台默默扫描全文建倒排索引，CPU 拉满 - 若
detect_indentation为true，它会从头读到尾猜缩进——对 JSON 来说毫无意义，却耗时耗内存 - 该配置不作用于已打开文件，所以改完要关掉再重开
必须加进 Preferences → Settings – User 的硬核配置
这不是“可选优化”，而是针对 JSON 类大文件的只读降级组合：
-
"index_files": false—— 关后台全文索引，否则SublimeLinter、GitGutter仍会偷偷 fork 子进程扫全文 -
"detect_indentation": false—— 避免从第一行开始扫描整份文件推断缩进 -
"line_numbers": false和"gutter": false—— 行号区 DOM 节点生成是渲染瓶颈，尤其在折叠/展开嵌套结构时 -
"draw_white_space": "none"—— 跳过空格/制表符可视化，避免大量字符串切片开销 -
"scroll_past_end": false—— 防止滚动到底部时额外分配缓冲区
注意："word_wrap": false 必须和 "viewport_size": 5000 配合使用才生效；单独设 viewport_size 对超长行无效。
用 syntax-specific 设置精准控制 JSON 文件行为
你不需要对所有文件都关行号，日常写 Python 时仍需定位；但打开 dump.json 就该静默加载：
- 打开一个大 JSON 文件，确认右下角显示语法为
JSON - 执行
Preferences → Settings – Syntax Specific，生成JSON.sublime-settings - 在里面写入：
{
"line_numbers": false,
"gutter": false,
"highlight_line": false,
"syntax": "Packages/Text/Plain text.tmLanguage"
}
这样下次打开任意 .json 文件都会自动走这套轻量配置，而不会影响其他语法类型。别漏掉最后一行——它强制跳过所有 .sublime-syntax 解析，连括号匹配都省了。
真正容易被忽略的是：Sublime 的设计目标是编辑，不是查看。如果你只是查字段、找错误、比对结构，jq、less -S 或 VS Code 的“大纲视图”往往比硬开 500MB JSON 更快更准。
