根源是index_files扫描和buffer_size不足；需禁用index_files、设large_file_threshold为10MB触发轻量模式，并避免误配无效的buffer_size。
大文件卡顿的根源在 buffer 和 index_files
Sublime Text 默认为小文件优化，打开 10MB+ 日志或 JSON 时卡顿，往往不是 CPU 或内存不足，而是编辑器在后台持续做两件事：index_files 扫描项目符号、buffer_size 不足导致频繁磁盘换页。macOS 上 index_files 尤其致命，它会监听整个文件夹变更，FSEvents 在大目录下极易阻塞主线程。
实操建议：
- 立即禁用：
"index_files": false—— 加到用户设置（Preferences → Settings）右侧面板，保存后重启 - 确认是否生效：Help → Debug，看控制台输出是否有
indexing files disabled - 若必须保留索引（如需 Goto Symbol），改用
"index_files_exclude_patterns": ["*.log", "*.json", "node_modules/"]精准排除
buffer_size 设置不生效？注意单位和位置
buffer_size 控制单个文件加载进内存的最大字节数，但它的值不是数字而是字符串，且只在 SublimeJ 或部分定制版中被识别；原生 ST4/ST3 不读这个字段。直接写 "buffer_size": 268435456 或 "buffer_size": "256MB" 都无效。
真正起效的方式只有两种：
- 对纯文本大文件（如日志）：用
subl --no-index --disable-plugin "Index Files" /path/to/big.log命令行启动，绕过索引系统 - 对 JS/TS 大文件：安装
SublimeJ插件，再在其专属配置Packages/SublimeJ/Settings.json中写"buffer_size": "256MB" - 通用兜底：在用户设置加
"large_file_threshold": 10485760（单位字节，即 10MB），超过该值自动禁用语法高亮和折叠，显著减轻渲染压力
GPU 渲染在大文件滚动时反而更卡？关掉 gpu_window_buffer
启用 "gpu_rendering": true 后，如果滚动大文件时出现撕裂、闪烁或光标延迟，问题大概率出在 gpu_window_buffer。它在 macOS（尤其 M 系列芯片 + 外接显示器）和 Windows 11 高缩放下极易与合成器冲突。
别只关 gpu_rendering——那是退回到 CPU 渲染，更慢。正确做法是保留 GPU 渲染文本，仅关闭窗口缓冲层：
- 在用户设置中明确添加：
"gpu_window_buffer": false - 同时确保
"gpu_rendering": true已开启（ST4 默认开启，ST3 不支持） - Windows 用户额外检查：右键
sublime_text.exe→ 属性 → 兼容性 → 勾选“替代高 DPI 缩放行为”，选“应用程序”
插件是隐藏的性能杀手，尤其是 Python 插件超时
大文件场景下，一个未适配的插件（比如旧版 SublimeLinter 或自定义 snippet 插件）可能因反复尝试解析整文件而卡住主线程。ST4 的 plugin_host 默认超时是 3 秒，但对大文件来说太长。
快速止血配置：
- 设短超时：
"plugin_timeout": 0.5（单位秒，0.5 秒后强制终止插件调用） - 防抖重载：
"plugin_reload_delay": 0.1（避免插件反复热重载干扰） - 临时禁用可疑插件：Preferences → Package Control → Disable Package，逐个排查
- 确认插件路径无中文或空格——
~/Library/Application Support/Sublime Text 4/Packages/User/循环.snippet这类路径在 ST4 中会被静默跳过
最常被忽略的是 index_files 和 large_file_threshold 的组合效果：前者关掉后台扫描，后者让编辑器主动“装瞎”，两者一起用，100MB 的日志文件也能保持光标响应。别调 buffer_size，它在原生 ST 里根本不起作用。
