sublime text适合轻量编辑配置文件和日志，启动快、内存低，支持快速跳转与空白符显示，但无实时tail、不原生支持lsp、插件生态萎缩且兼容性风险高。
适合快速编辑配置文件和日志
Sublime Text 启动快、内存占用低，打开几百MB的 nginx.conf 或滚动查看 app.log 时几乎不卡。它不解析语法树，只做轻量高亮和行号定位，这点比 VS Code 在纯文本场景下更干脆。
实操建议：
- 用
Ctrl+P（Windows/Linux）或Cmd+P（macOS）快速跳转到任意文件，比文件管理器双击还快 - 开启
"draw_white_space": "all"配置，一眼识别日志里混入的不可见字符（比如\u200b零宽空格） - 别指望它实时 tail 日志——没有内置流式读取，大文件末尾追加内容后需手动
Ctrl+R刷新
适合前端静态页面与小项目迭代
写 HTML/CSS/JS 小 demo、改 WordPress 主题模板、调试 Markdown 渲染效果，Sublime 的多光标、列选择、正则替换非常顺手。它不强制你装 LSP 插件，也不在保存时自动格式化，改完直接丢进浏览器看效果，节奏不被打断。
常见错误现象：
- 误以为
Emmet默认支持 Vue 单文件组件——实际要手动配scope或装Vue Syntax Highlight - 保存为
.html却用了 JSX 语法，高亮错乱但不会报错，容易漏掉括号匹配问题 -
Ctrl+Shift+P调出命令面板后输“build”，结果选中了Build with: Python——其实你只是想运行npm run dev，得先装SublimeBuild插件并自定义npm.sublime-build
不适合需要深度语言服务的场景
一旦项目引入 TypeScript 类型检查、Python 的 pylsp 补全、或 Rust 的 cargo check 实时诊断，Sublime 就明显吃力。它靠插件模拟 LSP，但无法像 VS Code 那样原生托管服务器进程，频繁重连、补全延迟、跳转失败是常态。
性能影响点：
- 装了
SublimeLinter+eslint后，每敲一个字母都触发子进程，1000 行 JS 文件下输入明显卡顿 -
GoSublime已停止维护，新版本 Go（1.21+）的泛型语法无法正确解析，go fmt保存后可能悄悄破坏代码结构 - 没有内建终端，
Ctrl+Shift+B构建失败时只能看黑框输出，没法交互式调试或补全命令
插件生态正在收缩，关键功能依赖手动维护
Package Control 上多数主力插件（如 SideBarEnhancements、BracketHighlighter）已多年未更新，兼容性靠社区 fork 维持。这意味着：新系统（如 macOS Sequoia）、新 Sublime 版本（41xx 系列）、甚至 Python 3.12 运行时，都可能突然失效。
实操建议：
- 不要升级 Sublime 到最新版后立刻重装全部插件——先备份
Packages/User/下的配置，再逐个测试 -
Color Highlighter和ColorPicker功能重叠，但后者不支持 HEXA（#RGBA），真要用透明色就得自己改color_helper.py - 同步设置别用官方 Sync Settings——它不传插件本身，只传配置，换电脑后仍得手动安装、再对齐版本
真正麻烦的不是功能少，而是每个“能用”的功能背后，都藏着一个没文档的配置项、一个三年没修的 GitHub issue、或者一次重启后就消失的右键菜单。
