鬼游"2026 年了，还在用 Sublime Text？"——这句话我至少被问过十几次。每次在技术群或同事聊天时发一张编辑器截图，总会有人冒出这句。问的人未必是真嘲讽，更多是好奇：VSCode 都快统治世界了，Sublime Text 怎么还活得好好的？更稀奇的是，不只用的人没少，还有一批人从 VSCode 回流了。作为一个从 2014 年用到现在，中间试过 VSCode、JetBrains 全家桶、Neovim，最后依然回到 Sublime Text 的开发者，我想认真聊聊这件事：到底谁还在用它、为什么用它、以及怎么把它调教成 2026 年依然能打的编辑器。如果你正在"要不要换回 Sublime"之间犹豫，或者刚打开它就被中文乱码劝退，这篇文章应该能帮你省下不少折腾时间。
1. 2026年坚持用Sublime的，不是遗老，是理性主义者
1.1 三个典型的使用者画像
先说结论：现在还留在 Sublime Text 里的人，基本不是"不会装 VSCode"或"懒得换工具"的遗老，反而是一群很清楚自己要什么的人。我大概归了三类。
第一类是重度脚本/运维开发者。他们每天的工作是打开一个几百 MB 的日志、改两行配置、写个临时 Python 脚本跑一下。这类场景打开 VSCode 那种重型编辑器就是灾难，启动慢、吃内存、还动不动弹出"是否信任此文件夹"。Sublime 双击即开、改完即走，效率完全不在一个量级。
第二类是前端或全栈里那一批"键盘流"。他们享受 Ctrl+P 直接模糊匹配文件、Ctrl+D 连续多光标编辑的爽感，Sublime 的快捷键体系至今是编辑器界的天花板。VSCode 后来抄了不少，但抄了皮毛，操作延迟和插件页面的卡顿是模仿不走的。
第三类则是被 VSCode"伤过"的人。你可能也遇到过：VSCode 装了十几个插件后，打开一个项目内存吃掉 2GB 起步，风扇狂转，每次启动还要加载一堆扩展。这种情况下回到 Sublime，不是倒退，是止损。
1.2 一个反直觉的真相：2024 年之后，有人在"回流"
这个话题在开发者社区里其实已经讨论过很多次。VSCode 的用户量确实最大，但在 2024 到 2026 这三年里，一个明显的趋势是"简朴编辑器的回归"。写 Rust、Go、Kotlin 这类语言的人本来就偏向轻量工具链，VSCode 那种"装全家桶"的体验反而成了负担。
我自己的经历就很有代表性。2020 年我主力用过一年 VSCode，当时觉得插件生态无敌、远程开发方便。但用了半年后，我发现自己花在"等编辑器响应"上的时间越来越多。打开一个工作区 5 秒，切换分支后索引重建半分钟，偶尔还卡到输入法弹出延迟。后来我把项目里能拆的都拆出去，只留最核心的代码，VSCode 才勉强顺滑。也是那时候意识到：编辑器选型本质是取舍问题，不是绝对优劣问题。VSCode 的代价是我得养一个常驻内存的"小操作系统"，而 Sublime 的代价则是某些功能需要我手动补。想清楚后，我选择了后者。
1.3 编辑器是工具，不是信仰
我不太喜欢"XX 编辑器天下第一"这种论调。工具选的不是最贵的，也不是功能最多的，而是跟你日常工作模型最匹配的。Sublime Text 的哲学是"打开文件、编辑、关掉"，它不试图接管你的整个开发流程。如果你每天的工作模式恰好是这种短平快节奏，那你自然会回到它身边。反过来，如果你要在 200 万行代码的单仓里做跨模块重构，那 VSCode、IntelliJ 的全局分析能力确实更合适。所以我开头说，还留在 Sublime 的人是理性主义者，因为他们想清楚了取舍，而不是被习惯绑架。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 启动快、吃得少、扛得住大文件：为什么 S 这几项至今没人超越
2.1 启动速度：0.5 秒和 5 秒的差距是心态问题
Sublime Text 的启动速度一直是它的招牌。空载状态下，它的启动时间基本在 0.5 到 1 秒之间，没装太多插件的话几乎感受不到"等待"。VSCode 在同等条件下通常在 3 到 5 秒，加上每次更新后还会额外慢一次。
别小看这 3 秒。你每天打开文件 50 次，一年下来就是几十个小时的差距。更重要的是，启动速度快会让你形成一种"随手开一个文件看看"的习惯，而不会被"又要等编辑器加载"劝退。很多开发者把 Sublime 当作系统的"默认文本查看器"，就是这个原因——它快到你忘了它存在。
2.2 内存占用：和浏览器和平共处，不再打架
Sublime Text 的核心底层是 C++ 写的自绘 UI，不依赖 Electron 那套"浏览器套壳"方案。这意味着它的基础内存占用非常低。我本机常年开着两个项目窗口、20 多个标签页，内存占用也就 400MB 左右。同样的场景，VSCode 稍微装几个插件就奔着 1.5GB 去了，如果再开两个 Chrome 窗口，8GB 内存的机器直接报警。
做前端或桌面客户端开发的同学应该都懂这个痛：编辑器吃内存会跟浏览器抢资源，结果是两边都卡。Sublime 在这个环节的优势是天然的，它不是靠优化省出来的，而是架构决定的。VSCode 的核心是 Electron + 渲染进程，即使啥插件不装，Chromium 的基础开销就摆在那，再怎么优化也有天花板。
2.3 大文件处理：300MB 日志秒开，VSCode 卡到怀疑人生
这一项是 Sublime 最硬核的保留技能。我经常要查线上日志，一个文件轻松 200MB 到 500MB。Sublime 打开这种文件依然流畅，拖拽滚动、Ctrl+F 搜索都能正常响应。VSCode 呢？打开 100MB 的 JSON 日志已经能卡到鼠标漂移，300MB 以上经常直接"无响应"。
有人可能觉得"日志文件我都在终端里用 grep 看，哪需要编辑器？"但真实场景是：你要一边 SQL 一边查日志，还要随时跳到某一行看上下文，编辑器可视化浏览的需求确实存在。Sublime 在这个场景下的表现几乎可以用"恐怖如斯"来形容，这也是运维、数据相关岗位到现在依然高频使用它的原因。顺带说一句，Sublime 能这么强，是因为它专门针对超长行和超大文件做了虚拟化渲染，只渲染可视区域，而不是一次性把整个文件处理完。
| 指标 | Sublime Text 4 | VSCode |
|---|---|---|
| 空载启动时间 | 0.5-1s | 3-5s |
| 打开 100MB 文件 | 流畅，秒开 | 明显卡顿，可能需等待 |
| 长期运行内存占用 | 300-500MB | 1.5GB 起步 |
| 插件丰富度 | 中高（有核心主力） | 极高 |
| 内置远程开发 | 需第三方插件 | 官方支持（但慢） |
3. 新手劝退重灾区：中文乱码的成因、根治和防复发方案
3.1 乱码到底怎么来的
"Sublime Text 中文显示乱码"能上热搜，我一点都不意外。大多数新手第一次用 Sublime 是在 Windows 上，打开一个从同事那里拷来的文件，里面中文全变成"锟斤拷"或者一串问号，第一反应就是卸载。但乱码的锅真不该 Sublime 背。
核心原因只有一个：文件编码不匹配。Windows 传统中文环境（尤其中国区）默认编码是 GBK/GB2312，而 Sublime Text 默认按 UTF-8 解码。如果文件实际是 GBK 编码、Sublime 拿 UTF-8 去解，自然满屏乱码。反过来也一样，UTF-8 文件被 GBK 工具打开也会花。
理解了这个机制，你就知道怎么办了：让编辑器识别出"这个文件是 GBK 编码"，再按正确编码重新读。Sublime 原生没有自动检测 GBK 的能力，所以需要插件帮它一把。
3.2 破局第一步：装上 ConvertToUTF8
Sublime 乱码问题的标准解法是装一个叫 ConvertToUTF8 的插件。它做的事情是：打开文件时检测编码，如果是 GBK/GB2312 等非 UTF-8 编码，自动转换成 UTF-8 显示；保存时根据配置决定存回原编码还是统一存成 UTF-8。
安装流程是这样的：
- 先装 Package Control。按 `Ctrl + `` 打开控制台（注意是数字 1 左边的反引号键），粘贴官网上的安装代码回车，重启 Sublime 即生效。
- 重启后按
Ctrl + Shift + P，输入Package Control: Install Package，回车。 - 然后输入
ConvertToUTF8，找到后回车安装。
装完你就会发现，之前打开是乱码的文件，现在正常显示了。这一步解决的是"读"的问题。
3.3 保存时要不要转回原编码？取决于你的协作场景
我见过很多人装完 ConvertToUTF8 后，发现保存时把 GBK 文件改成了 UTF-8，结果文件发给同事后对方用老软件打开反而乱码。这里的关键是理解 ConvertToUTF8 的保存逻辑。
插件默认是"文件原本什么编码，保存时尽量保持什么编码"。如果你希望所有文件保存时都统一成 UTF-8，可以在 Sublime 的设置文件（Preferences > Settings）里加上：
json复制{
"convert_on_save": true
}
不过我个人建议：除非你能确保所有下游工具都支持 UTF-8，否则不要改这个设置。更好的做法是推动团队统一用 UTF-8 编码、git 仓库配 .gitattributes 做编码声明，从源头消灭乱码。工具层面解决乱码只是兜底，预防乱码才是一劳永逸。
3.4 乱码排查的通用思路：别急着怪编辑器
再分享一个排查方法。碰到乱码时，先别急着装插件，按这个顺序走一遍：
- 在 Sublime 右下角状态栏看到当前文件编码（如果开启了
show_encoding: true）。 - 用系统命令或者 Notepad++ 之类工具看文件原始编码，必要时用
file --mime-encoding命令检测。 - 确认到底是"编辑器解码方式不对"还是"文件本身就已经损坏"。
有些乱码是 BOM 问题。UTF-8 文件带 BOM（Byte Order Mark）在某些场景下会在开头显示  三个怪字符，这不算真正的乱码，去掉 BOM 就行。Sublime 里可以用 UTF-8 with BOM 和 UTF-8 两种编码切换试试。搞清楚这几种情况，你就不会再被"乱码"这种小问题劝退了，排查任何工具乱码问题也都是同一套逻辑。
4. 把 Sublime Text 调教成 2026 年的主力编辑器：主题、插件与快捷键体系
4.1 主题：既要眼睛舒服，也要看着不落伍
"Sublime Text 主题"能成为热搜词，说明外观依然是很多人留不留得下来的关键点。默认的 Monokai 确实经典，但看十年也会腻。好在 Sublime 4 支持 .sublime-color-scheme 格式，改配色比旧版灵活得多。
我个人比较喜欢的几个主题：
- Monokai Pro（付费但物有所值，配色柔和，带专属 UI 主题）
- One Dark（Atom 风格，冷色调，写久了不累）
- Tokyo Night（这两年很火，深蓝底色，适合夜间编码）
- Material Theme（带侧边栏样式，可定制性强）
设主题的方式有两种：一种是在 Package Control: Install Package 里搜主题名安装，然后在设置里写：
json复制{
"theme": "Material-Theme-Darker.sublime-theme",
"color_scheme": "Packages/Material Theme/schemes/Material-Theme-Darker.tmTheme"
}
另一种是安装 Themr 插件，它会给你一个图形化切换器，方便快速横跳比较。我比较推荐先装 Themr，选好以后再把最终配置固化进设置文件。
有一点要提醒：主题不是装得越多越好。我同时装了七八套主题，结果每次看腻了就想换，浪费了不少时间。现在只留一套深色、一套浅色，来回切就够了。Sublime 的文件菜单里有个对应的切换入口，甚至可以给编辑器配一套"自动按系统深浅色切换"的方案，但说实话日常手动切就行。
4.2 插件：十年经验总结的必装清单，不是越多越好
Sublime 的插件生态和 VSCode 比确实没那么庞大，但核心拼图齐全。我现在的装机清单里，长期保持启用的不到十个，每一个都是刚需：
| 插件 | 作用 | 备注 |
|---|---|---|
| Package Control | 包管理器 | 必备 |
| ConvertToUTF8 | 编码转换 | 中文环境必备 |
| LSP | 语言服务器协议客户端 | 替代 VSCode 的 IntelliSense |
| Terminus | 内置终端 | 比默认的 Terminal 更好用 |
| GitGutter | 行级 Git 改动提示 | 写代码时瞟一眼就知道改过哪 |
| SideBarEnhancements | 侧边栏右键增强 | 新建/移动/复制文件更方便 |
| Emmet | HTML/CSS 快速编写 | 前端必备 |
| SublimeLinter | 代码静态检查 | 可接 ESLint、flake8 等 |
| BracketHighlighter | 括号配对高亮 | 写嵌套代码的救星 |
这几样配合起来，日常开发体验已经不输 VSCode。而且因为插件数量少，启动速度和内存占用基本不受影响。我从 VSCode 迁回来时，最大的感受就是"原来编辑器可以这么安静"，没有插件更新弹窗，没有插件之间的相互打架。
4.3 快捷键：Sublime 最被低估的宝藏
如果说有什么东西是"用了 Sublime 就走不回来"的，快捷键绝对排第一。这里说的不是几个常用的 Ctrl+C/V，而是它那一套基于"命令面板 + 模糊匹配"的操作哲学。我最常用的几个：
- Ctrl+P：文件跳转。输入文件名片段就能定位，甚至支持跳到具体行。
- Ctrl+Shift+P：命令面板。几乎所有功能都能在这里输入名称调出，根本不用记菜单。
- Ctrl+D：多光标选择。光标放在一个单词上，按一次选中它，再按一次选中下一个相同的词，批量改变量名神器。
- Ctrl+Shift+L：把当前选中区域按行拆成多光标。
- Alt+F3：一键选中全文所有相同的词，配合多光标批量替换。
- Ctrl+R：函数/符号跳转，快速在文件内定位方法。
- Ctrl+KU / Ctrl+KL：选中内容转大写/小写，写 SQL 或枚举时很常用。
这套体系我用了十年，肌肉记忆已经形成了。VSCode 虽然也兼容了一部分，但默认情况下个别快捷键行为和 Sublime 有细微差别，对老用户来说总有种"差口气"的不自然感。这也是不少键盘流宁可留在 Sublime 的真实原因。
多光标是 Sublime 最惊艳的功能，没有之一。它不像 VSCode 那样只是"能用"，而是做得极其顺滑。比如你要改 20 个写死的 API 地址，只需要：全选文件，Ctrl+Shift+L 拆成行，然后 Ctrl+← 跳到地址开头，按住 Ctrl+Shift+→ 选中旧值，直接敲新内容，20 行一步改完。这种操作在其他编辑器里要么做不到，要么步骤繁琐得多。
4.4 内置终端：Terminus 让 Sublime 也拥有"一站式"体验
Sublime 4 之前的软肋之一是没有好用的内置终端，很多人因此逃离。现在有了 Terminus，这个问题基本解决了。它支持在编辑器底部开一个 terminal 面板，也支持把某个侧边栏目录映射成终端启动路径。
我的配置方式是：把 Terminus 的快捷键绑定成 Ctrl+~（和打开控制台区分开），随时呼出一个终端，用 python3 跑脚本、git status 看状态、npm run dev 起服务，都不用切换到其他窗口。配合 Sublime 的构建系统，甚至可以在编辑器内直接跑测试、看输出。这样一来，"编辑器只能编辑"的刻板印象，至少在我这里是不成立了。
5. 别再说它不能写项目：LSP 和工具链补齐，手把手配到能干活
5.1 LSP：让 Sublime 接入现代语言智能
很多人说"Sublime 只能当记事本"，那是它没配 LSP 之前的事。LSP（Language Server Protocol）是微软提出的语言服务协议，VSCode 的智能提示、跳转定义、错误标红，底层都用这个。好消息是，Sublime 从 4.0 开始对 LSP 的支持已经比较成熟了。
装好几个语言服务后，Sublime 的体验可以非常接近 VSCode。比如想在 Sublime 里写 Python，先装 Python Language Server（pylsp）：
- 在系统里安装
pylsp：pip install python-lsp-server - 在 Sublime 里通过 Package Control 安装
LSP插件。 - 在 LSP 的客户端配置里加一项：
json复制{
"clients": {
"pylsp": {
"enabled": true,
"command": ["pylsp"],
"selector": "source.python"
}
}
}
保存后，打开一个 Python 文件，等右下角出现 LSP 连接的图标，就能体验函数补全、悬停文档、跳转定义了。写 TypeScript 的话，LSP-typescript 也是同样的思路。这一套配完之后，说 Sublime"缺少现代 IDE 功能"就真的是刻板印象了。
5.2 代码规范与格式化的团队协作方案
写项目不只是单打独斗，还要考虑团队协作。Sublime 这边完全可以用工具补齐。代码格式化方面，前端用 Prettier，Python 用 Black，都可以通过 SublimeLinter 插件或构建系统调用。我的做法是在 Sublime 里配一个格式化的构建系统，选中一个文件按下快捷键即可：
json复制{
"name": "Format with Prettier",
"cmd": ["npx", "prettier", "--write", "$file"],
"selector": "source.js, source.ts, source.css, source.html"
}
这样写代码的时候，随时可以格式化当前文件，不用切到终端。代码规范检查就交给 SublimeLinter，它把 ESLint、flake8 的报错一行行标在代码旁边，团队 CI 里发现问题的时间，在本地就已经提前拦截掉了。
5.3 Git 工作流：没有内嵌 UI，但不影响日常操作
Sublime 没有像 VSCode 那样的图形化 Git 管理界面，这也是很多人觉得它"写不了项目"的理由。但真正高频使用的 Git 操作其实没那么多：看看改了哪些文件、查一下当前分支、提交推送。GitGutter 插件能在行号旁边显示新增、修改、删除标记，一眼就知道这行代码是新改的还是老的。至于 git add .、git commit 这种命令，Terminus 终端里有的是，而且对于老手来说，命令行比各种图形界面反而更快。
如果你实在离不开可视化的 Git UI，可以在 Sublime 中安装 GitSavvy 插件，它提供的 commit、push、分支管理界面虽然简朴但完全可用。不过我用下来的建议是：前端图形操作最多占 20%，剩下的还是终端里敲命令更高效。这个搭配在团队协作里没有任何障碍，因为关键的交互都通过 Git 仓库完成，编辑器只是前端。
5.4 我为什么不用 VSCode 写前端了：一个诚实的选择复盘
前面说了这么多"Sublime 怎么配置才能用"，最后想诚实地聊聊我为什么没有一直留在 VSCode。2020 年我确实认真用了大半年，也承认它在大型前端项目里体验很不错，尤其插件市场搜啥都有。但最终让我离开的是一系列"小事"的累积：启动一次要等半天、插件市场动不动就升级重启、每次打开项目还要处理一堆"你希望工作区信任吗"的弹窗。对于一个核心工作场景是"快速改文件、写小工具、查日志"的人来说，这些都是噪音。
我不是说 VSCode 不好。它有它的优势，比如集成的调试器、内置终端、远程开发的那套方案，在特定场景下很方便。我只是想说：编辑器选型没有绝对标准答案，只有"适合不适合你的工作流"。如果你每天打开电脑后的前 10 分钟都花在"等编辑器就绪"上，那你大概率也适合回到一个更轻的东西。
6. 2026 年，我建议你怎么决定要不要用回 Sublime
最后给一些我的个人建议。如果你正在犹豫，不妨拿下面几个问题问自己：
- 你每天的主要工作是写大项目里的新模块，还是改配置文件、写脚本、处理数据？
- 你是否反感编辑器占用大量内存、频繁弹更新提示？
- 你依赖 VSCode 的那些能力，是它的原生功能，还是其实只是某个插件提供的？
- 你能接受"某些花哨功能需要自己配插件"这件事吗？
如果你的回答是"我主要写小脚本、查日志、改配置，讨厌等加载"，那 Sublime Text 基本不会让你失望。如果你说"我要在几百万行代码里做系统重构，最好有开箱即用的全项目智能分析"，那说实话，Sublime 可能依然不是最优解，JetBrains 或 VSCode 更合适。
我自己现在的使用方式是双轨制：日常的快速操作、脚本编写、文本处理全在 Sublime 里完成，只有碰到特别大的跨模块重构才会临时打开 VSCode。很多同事吐槽我有工具洁癖，但我觉得这恰恰是对效率的较真。编辑器是每天陪伴你最多时间的工具之一，花点时间找到真正匹配自己工作习惯的那个，比每天被工具拖着走要舒服得多。
如果你也被问过"2026 年还有人用 Sublime？"，我的回答其实很简单：工具的价值不在新旧，而在它是否精准地解决你手头的问题。Sublime Text 到今天依然是一款反应迅速、稳定可靠、启动即开的编辑器。它没有变成 VSCode，这恰恰是它还活着的原因。