Sublime Text 本身不支持 WebAssembly 编译和调试，仅能通过插件实现语法高亮；真正编译需配置构建系统调用外部工具（如 wat2wasm、clang、wasm-pack），调试则必须依赖浏览器或 VS Code。
Sublime Text 本身不支持 WebAssembly 编译
Sublime Text 是一个文本编辑器，不是 IDE，它没有内置的 wabt、clang 或 wasm-pack 等工具链，也不能直接运行或调试 .wasm 文件。你看到的“WebAssembly 支持”，通常只是语法高亮（比如通过 WASM 或 WebAssembly Syntax Highlighting 插件），和真正的编译/调试无关。
要完成从源码到可执行 wasm 的流程，必须依赖外部工具，并在 Sublime 中通过构建系统（Build System）调用它们。关键不是“Sublime 能不能做”，而是“你有没有配好命令行工具 + 正确的构建配置”。
如何配置 Sublime 的构建系统来编译 .wat 或 C/Rust 源码
Sublime 的构建系统本质是 shell 命令封装。你需要先确保对应工具已安装并可被 PATH 找到：
-
wabt：用于把.wat（文本格式）转成.wasm，装完后验证：wat2wasm --version -
clang（+lld）：编译 C/C++ 到 wasm，需启用-target wasm32-unknown-unknown-wasi -
wasm-pack：Rust 项目首选，但它是独立 CLI，不依赖 Sublime 插件
以编译 main.wat 为例，在 Sublime 中：Tools → Build System → New Build System…，填入：
{
"shell_cmd": "wat2wasm \"$file\" -o \"${file_path}/${file_base_name}.wasm\"",
"file_regex": "^(.*?):([0-9]+):([0-9]+): (.*)$",
"selector": "source.wat"
}
保存为 Wat2Wasm.sublime-build，再打开 .wat 文件按 Ctrl+B 即可生成同名 .wasm。注意路径变量必须用双引号包裹，否则含空格路径会失败。
为什么不能在 Sublime 里直接调试 .wasm
WebAssembly 调试依赖运行时环境提供 DWARF 支持和断点注入能力，目前只有浏览器 DevTools（Chrome/Firefox）和 VS Code（配合 CodeLLDB 或 WebAssembly 扩展）能真正单步调试 wasm 函数。Sublime 没有调试适配器协议（DAP）支持，也没有内存/调用栈可视化界面。
你唯一能做的，是把编译好的 .wasm 加载进 HTML 页面，然后用浏览器调试：
- 确保 wasm 编译时加了
--debug（wat2wasm）或-g（clang）生成调试信息 - 用
WebAssembly.instantiateStreaming()加载，别用fetch().then(arrayBuffer => ...)，否则 Chrome 不显示源码映射 - 在 DevTools 的
Sources面板中，展开webpack://或file://下的.wat/.c原始文件才能设断点
容易被忽略的兼容性陷阱
很多初学者卡在“编译成功但运行报错”，问题往往不在 Sublime，而在工具链版本或目标平台选择：
-
wabt旧版（如 1.0.15 之前）默认输出 wasm v1，但某些 WASI 运行时要求WASI snapshot 0，需显式加--enable-saturating-float-to-int --enable-sign-ext - 用
clang编译 C 时，若漏掉--sysroot=$(wasi-sdk-path)/share/wasi-sysroot，链接阶段会找不到__libc_start_main - Sublime 构建系统默认使用 login shell，但 macOS 上 zsh 和 bash 的
PATH可能不同——如果wabt是用brew install wabt装的，而 Sublime 启动自 Finder，则可能找不到命令；解决方法是用绝对路径：/opt/homebrew/bin/wat2wasm
真正耗时间的从来不是写代码，而是确认 wabt 版本、检查 WASI 兼容性、以及搞清 Sublime 的 shell 环境到底加载了哪套 PATH。
