Sublime Text在Mac芯片架构下的原生性能调优方案

先说一个核心判断：Sublime Text 4 在 Apple Silicon（M1/M2/M3）上跑原生模式，启动快、内存低、滚动顺——但前提是配置没踩坑。开箱即用不等于开箱即优，很多卡顿和闪烁问题，其实都源于默认设置与 ARM64 渲染路径之间那些隐性冲突。

确认是否真正在 ARM64 下运行

别只看“已安装 ST4”就完事了，你得验证它是不是真走原生路径。Rosetta 2 转译下性能打折很明显，尤其在高分屏缩放或频繁切换标签时，差距一拉就出来。

• 打开 Help → Debug，检查控制台输出中是否有 arch: arm64；如果显示 x86_64，说明正被 Rosetta 2 强制转译
• 再确认 gpu_rendering: true 是否生效——ARM64 + Metal 后端必须同时满足才发挥全部优势
• 如果仍是 x86_64，去访达右键 Sublime Text.app → “显示简介”，勾选“使用 Rosetta”并取消勾选，然后彻底退出重开

GPU 渲染开启但屏幕闪烁？关掉 gpu_window_buffer

部分 M1/M2 Mac（尤其是外接显示器或 macOS 14+）启用 gpu_rendering 后反而出现窗口撕裂、状态栏闪烁或滚动残影，根本原因是 gpu_window_buffer 与 Metal 合成器存在帧同步竞争。

• 在用户设置中显式关闭："gpu_window_buffer": false
• 保留 "gpu_rendering": true 不变——它控制的是文本视图渲染，而 gpu_window_buffer 控制的是整个窗口合成层
• 该组合在 M 系列芯片上实测更稳：滚动帧率维持 60fps，且避免了窗口最小化/还原时的白屏卡顿

Snippet 不触发、Tab 键失灵？不是插件问题，是作用域匹配变了

ST4 重写了自动补全调度逻辑，默认优先让 LSP 插件响应 Tab，导致你写 for 后按 Tab 没反应，控制台报 Unable to find snippet——这不是 snippet 文件坏了，而是作用域没被识别。

• 检查 snippet 文件路径是否含空格或中文，例如 ~/Library/Application Support/Sublime Text 4/Packages/User/循环.snippet 在 ST4 中会被跳过
• 确保 snippet 文件里定义了正确的 scope，比如 Python 的 for 循环 snippet 必须含 source.python，不能只写 python
• 临时修复：在设置中加 "auto_complete_commit_on_tab": true，并确认 "auto_complete_selector" 没被其他插件覆盖为 text.plain

启动仍慢？index_files 是 macOS 上最隐蔽的性能杀手

macOS 的 FSEvents 对 index_files 的监听极其敏感，哪怕项目根目录下只有 1 个 node_modules 子目录，ST4 就会持续 stat() 数万文件——这在 ARM64 上不耗 CPU，但会阻塞主线程导致 UI 响应延迟。

• 直接禁用："index_files": false —— 这是 M 系列用户最该加的第一行配置
• 若需保留部分索引能力，改用排除法："folder_exclude_patterns": ["node_modules", ".git", "__pycache__"]
• 别信“等它建完索引就快了”——FSEvents 会在后台无限期监听，只要目录存在，它就永远在工作

真正影响体验的，从来不是芯片跑得多快，而是 Sublime Text 有没有把 ARM64 的 Metal 调度、FSEvents 事件流、Python 3.8 插件生命周期这三件事对齐。错一个，顺滑感就断档。