sublime text 4 在 apple silicon 上需同时满足 arm64 架构、metal 渲染后端及禁用 index_files 才能发挥性能优势；若显示 x86_64 则运行于 rosetta 2，应取消“使用 rosetta”选项并重启，配合 "gpu_rendering": true 和 "gpu_window_buffer": false 可稳定 60fps 滚动，避免闪烁。
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 合成器存在帧同步竞争。
PyCharm 2026.2.0.1 Mac版
下载
PyCharm 2026.2.0.1 Mac版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合在macOS系统上进行 Python 项目开发、运行、调试和测试。
- 在用户设置中显式关闭：
"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 插件生命周期这三件事对齐。错一个，顺滑感就断档。
