sublime text 可通过配置 v 编译器实现轻量 vlang 开发，前提是路径、utf-8+lf 编码、构建命令三者对齐；需确保 v 在 path 中且 sublime 从终端启动，使用指定 file_regex 的 v.sublime-build，并避免 lsp 插件。
Sublime Text 本身不内置 Vlang 支持，但搭配 v 编译器和少量配置，能跑出比 VS Code 启动快 3 倍、编译反馈快 1.5 倍的轻量系统编程体验——前提是路径、编码、构建命令三者对齐，否则会卡在 v run 报错或 undefined reference。
确认 v 安装并可被 Sublime 调用
Sublime 的构建系统依赖系统 PATH 查找 v，不是靠绝对路径硬编码。Windows 用户尤其容易栽在这里：
- 在 cmd 中执行
v version必须返回版本号（如v 0.4.5），否则 Sublime 构建时会报'v' is not recognized as an internal or external command - 若用 Scoop 或 Chocolatey 安装，确保安装后重启了 Sublime（它不自动 reload PATH）
- macOS/Linux 用户需确认
v在/usr/local/bin或$HOME/.vlang下，并已加入 shell 的$PATH；Sublime 启动方式影响环境变量加载（推荐从终端用subl启动，而非桌面图标）
v.sublime-build 构建系统必须用 UTF-8 + Unix 换行
Vlang 对源文件编码和换行符敏感，v run main.v 在 Windows 上若遇到 invalid character U+000D，大概率是 Sublime 保存时用了 CRLF 或 GBK。解决方法只有两个：
- 打开
main.v→ 右下角点击编码名（如UTF-8或Western (Windows 1252)）→ 选Convert to UTF-8→ 再点Save - 右下角点击换行符类型（如
Windows (CRLF)）→ 选Unix (LF) - 构建系统文件
v.sublime-build自身也必须是 UTF-8 + LF，否则 Sublime 解析失败，构建菜单灰掉
构建命令要区分 v run 和 v -prod 场景
直接用 v run 调试快，但无法捕获 stdin 输入；生产构建需分离编译与运行。一个实用的 v.sublime-build 配置示例：
{
"encoding": "utf-8",
"working_dir": "$file_path",
"shell_cmd": "v run \"$file\"",
"file_regex": "^(.*?):([0-9]+):([0-9]+): (.*)$",
"selector": "source.v",
"variants": [
{
"name": "Build",
"shell_cmd": "v -o \"$file_base_name\" \"$file\""
},
{
"name": "Run (Prod)",
"shell_cmd": "v -prod -o \"$file_base_name\" \"$file\" && ./$file_base_name"
}
]
}
注意点：
-
file_regex必须匹配 Vlang 默认错误格式，否则跳转不到报错行；V 0.4+ 错误行是main.v:5:12: error: ...，不能写成 GCC 风格 -
shell_cmd中\"$file\"的引号不能省，否则含空格路径会崩 -
Run (Prod)在 Windows 上要改用./$file_base_name.exe，且需确保当前终端支持执行二进制（PowerShell 默认禁用，建议用 CMD 或 Git Bash）
没有 LSP 也不耽误写系统级代码
Vlang 目前无成熟 LSP 支持（截至 2026 年中），强行装 LSP-v 插件反而导致 Sublime 卡顿或崩溃。实际开发中更可靠的做法是：
- 用
Ctrl+Shift+P→Insert Snippet手动补全常用结构（如fn main() { }） - 把
v doctor输出粘贴到临时文件，快速查模块是否启用（比如git,sqlite,ui） - 调试时优先用
v -g生成带 debug info 的二进制，再用lldb或gdb外挂调试，别指望 Sublime 内置断点
真正影响效率的从来不是功能多寡，而是编辑器启动后 300ms 内能否敲出第一行 fn main() 并看到 hello world ——这点 Sublime + v 做得比多数 IDE 更干脆。
