立刻恢复响应：按Ctrl+Shift+P输入Set Syntax: Plain Text回车终止语法扫描，再输Toggle Word Wrap关闭自动换行；若无响应则终端执行subl --safe-mode强制轻量加载。

Sublime Text 打开 GB 级文件卡顿，不是它撑不住，而是你没让它“别当这是个要编辑的文件”——关掉语法解析、索引、行号这三类默认开启的重型功能，再配合只读加载和外部预处理，1.2GB 日志 8 秒内可滚动。

怎么立刻让已卡住的 Sublime 恢复响应（5 秒内）

别等加载完成，直接干预正在运行的实例：

• 按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Set Syntax: Plain Text 回车——立刻终止语法高亮引擎的全量扫描
• 再输 Toggle Word Wrap 关闭自动换行，防止超长日志行反复计算软换行位置
• 右键状态栏语言名（如显示 JSON 或 Log），选 Open all with current extension as… → Plain Text，避免下次同后缀文件重蹈覆辙
• 如果 Ctrl+Shift+P 已无响应，终端执行 subl --safe-mode your_file.log：跳过所有插件和用户设置，实测 1.2GB 日志 8 秒内可滚动

哪些配置项必须改，且不能全局一刀切

在 Preferences → Settings – User 中添加以下内容，但注意：这些不是“越狠越好”，而是按需启用：

• "large_file_size_limit": 100：单位是 MB，设为 100 后，超过 100MB 的文件会主动跳过语法分析和索引；不要设为 0 或负数，Sublime 会忽略
• "index_files": false：禁用后台全文符号索引，否则 GitGutter、SublimeLinter 等插件仍会偷偷启动子进程扫全文
• "detect_indentation": false：对无缩进的日志毫无意义，却要从头扫到尾猜缩进，纯属耗时耗内存
• "viewport_size": 5000：默认值是 100000（10 万字符），改成 5000 可省 95% 渲染内存，但必须配合 "word_wrap": false，否则超长行仍拖垮渲染器

⚠️ 不要全局设 "line_numbers": false——日常写 Python 时仍需行号定位；只应在大日志场景下通过 syntax-specific 设置覆盖。

为什么按语法类型单独配比全局设置更可靠

你不需要对所有文件都关掉高亮，但打开 access.log 或 dump.json 时就得静默加载。Sublime 支持按语法名精准覆盖，比全局开关更安全。

• 打开一个大日志文件，确认右下角显示语法为 Plain Text 或 Log
• 执行 Preferences → Settings – Syntax Specific，生成对应语法的配置文件（如 Plain Text.sublime-settings）
• 在里面写入：

  {
    "line_numbers": false,
    "gutter": false,
    "highlight_line": false,
    "syntax": "Packages/Text/Plain text.tmLanguage"
  }

• 语法名不确定？控制台运行 view.settings().get('syntax') 查实际值

真正容易被忽略的点：别硬扛，该换工具时就换

Sublime 再怎么调，本质仍是面向编辑的 GUI 编辑器。超过 2GB 或需要高频正则替换上百万次时，它的内存模型和事件循环就不是设计目标了。

• 纯查看：用 less（Linux/macOS）或 more（Windows Terminal），支持 /pattern 搜索、g 到开头、G 到结尾，零内存占用
• 筛选/切片：先用 grep -n "OutOfMemoryError" app.log | head -10 拿行号，再贴进 Sublime 用 Ctrl+G 跳转；或用 sed -n '100000,100100p' app.log > chunk.log 提取区间
• 真要编辑：确认是否必须图形界面？vim -u NONE +1000000 huge.log 启动后直接定位，比 Sublime 加载还快

最常被跳过的一步是系统级只读：右键文件 → 属性 → 勾选“只读”，Sublime 会自动降级为查看模式，禁用撤销栈和缓存写入——这个动作本身就能绕过大量内部校验逻辑。