右下角显示Plain Text即语法未绑定，是汇编编译失效的首要原因；需点击切换为Assembly (NASM)或x86 (GAS)，启用对应插件，分别绑定.s/.S后缀，并确保构建系统selector与语法scope严格一致。
Ctrl+B 没反应，不是构建系统写错了，而是右下角语法名根本没对上——这是 90% 汇编编译失效的起点。
右下角显示 Plain Text 就别往下试了
Sublime 不会自动把 .asm、.s 或 .S 当成汇编文件。它只看右下角状态栏显示的语法名，显示 Plain Text 就说明高亮和构建两套机制全被拦在门外。
- 点击右下角文字 → 搜索
Assembly (NASM)或x86 (GAS)→ 选中后立刻观察寄存器是否变色 - 若菜单里没有这些选项：按
Ctrl+Shift+P→ 输入Package Control: Enable Package→ 启用对应插件（注意名称带括号，比如Assembly (NASM)，不是Assembly Language Support） -
.s和.S是两个独立后缀，必须分别右键标签页 →Open all with current extension as…→ 各自绑定一次；.s文件开头若有#注释，常被误判为 ShellScript，删掉首行再试Set Syntax: x86 (GAS)
构建系统 selector 和语法 scope 必须严格一致
你手动设的是 Assembly (NASM)，但 .sublime-build 文件里 selector 写成 source.asm？那它永远不触发。scope 名必须和语法包实际声明的一致。
- 查当前语法 scope：光标停在代码任意位置 →
Ctrl+Shift+P→ 输入Developer: Show Scope Name→ 看输出里是否含source.asm.nasm（NASM）或source.gas（GAS） - NASM 插件常用 scope 是
source.asm.nasm，GAS 插件常用source.gas或source.gnu-assembler；写错一个字符，Build 菜单里就不会出现该构建系统 - 别用泛用的
source.asm—— Sublime 默认不定义这个 scope，它只匹配插件显式注册的完整路径
命令找不到 nasm/as？GUI 启动时 PATH 丢了
终端里 nasm --version 成功，但 Sublime 里报 sh: nasm: command not found，这是 macOS 和 Windows 用户更新 Sublime 后最常踩的坑：GUI 启动不继承 shell 的 PATH。
- macOS：Homebrew 安装的
nasm默认在/opt/homebrew/bin/nasm，必须从终端运行subl .启动 Sublime，双击图标启动必然失败 - Windows：确认
nasm.exe所在目录（如C:\nasm\）已加入「系统环境变量」PATH，不只是用户变量；改完后重启所有 CMD 和 Sublime - 不建议在
.sublime-build里硬写绝对路径（如"cmd": ["/opt/homebrew/bin/nasm", "-f", "elf64", "$file"]），跨机器就失效；优先修复 PATH，让shell_cmd直接调nasm
Build 结果面板空白或一闪而过
按下 Ctrl+B 后只看到 [Finished in 0.1s]，没有错误或输出，常见于构建系统被设成语法检查、或输出被其他面板覆盖。
- 检查 Tools → Build System 是否选中了你写的汇编构建系统，而不是
Automatic或空项；更新 Sublime 后它常被重置 - 如果刚执行过
Find in Files（Ctrl+Shift+F），结果会卡在底部面板不动；必须手动点菜单Tools → Build Results → Show Build Results强制唤出 - 汇编构建系统若用了
shell_cmd且未加-o输出目标，可能只做语法检查不生成目标文件；确认命令含类似nasm -f elf64 "$file" -o "${file_path}/${file_base_name}.o"
真正容易被忽略的是：高亮和构建是两套独立机制，但它们都依赖同一个开关——右下角那个语法名。改对了，才可能响；改错了，哪怕 .sublime-build 写得再漂亮，也永远静音。
