Sublime Text构建系统必须置于Packages/User/目录下才生效，且需用shell_cmd跨平台兼容、file_regex精准匹配错误格式、selector限定为source.nasm|source.asm。
构建系统文件必须放在 Packages/User/ 目录下才生效
Sublime Text 不会加载项目目录、桌面或 Packages/MyASM/ 下的 .sublime-build 文件——这是硬性路径限制，不是“可能不生效”。放错位置，Tools > Build System 菜单里根本不会出现你的构建项，按 Ctrl+B 也毫无反应。Windows/macOS/Linux 全平台一致，没有例外。
shell_cmd 是跨平台兼容的关键，别用 cmd 或 sh 硬编码
Windows 上用 cmd /c、macOS/Linux 用 sh -c 会导致构建系统在其他平台直接失败。正确做法是统一用 shell_cmd 字段，并依赖 Shell 自身的跨平台语义：
-
"shell_cmd": "nasm -f win64 ${file} -o ${file_path}/${file_base_name}.obj && gcc ${file_path}/${file_base_name}.obj -o ${file_path}/${file_base_name}.exe"（Windows） -
"shell_cmd": "nasm -f macho64 ${file} -o ${file_path}/${file_base_name}.o && clang ${file_path}/${file_base_name}.o -o ${file_path}/${file_base_name}"（macOS） -
"shell_cmd": "nasm -f elf64 ${file} -o ${file_path}/${file_base_name}.o && gcc ${file_path}/${file_base_name}.o -o ${file_path}/${file_base_name}"（Linux）
注意：nasm 和 gcc/clang 必须已加入各平台的 PATH；shell_cmd 会自动调用对应系统的默认 shell，无需手动指定 cmd 或 sh。
file_regex 必须匹配你实际使用的汇编器+链接器错误格式
不同汇编工具链报错格式差异极大。比如 nasm 默认输出形如 hello.asm:5: error: invalid operand type，而 gcc 链接失败时可能是 /usr/bin/ld: cannot find -lc。若 file_regex 写成 C/C++ 的通用正则 ^(..[^:]*):([0-9]+):?([0-9]+)?:? (.*)$，汇编错误就无法跳转到行号。
建议分情况处理：
- 纯
nasm编译阶段：用"file_regex": "^(.*\.asm):([0-9]+):.*$" - 后续
gcc链接阶段错误：保留原 C/C++ 正则，但仅当shell_cmd中包含链接步骤时才启用该匹配逻辑（实际中常需拆成两个构建变体） - 调试时可临时加
"quiet": true关闭 regex 匹配，避免误跳
selector 设为 "source.asm | source.nasm" 比 "source" 更安全
把 selector 写成 "source | text" 确实能“万能匹配”，但副作用明显：任意文本文件（比如 README.md）按 Ctrl+B 都会触发汇编构建，容易误操作。更稳妥的做法是明确限定语法类型：
- NASM 语法：用
"selector": "source.nasm"（需先安装 NASM 插件并启用语法高亮） - GNU Assembler（
.s文件）：用"selector": "source.asm" - 若同时支持多种后缀，写成
"selector": "source.nasm | source.asm"
这样只有打开 .asm 或 .nasm 文件时，构建系统才会自动激活，且菜单里只显示相关项。
跨平台汇编最难的不是语法或命令拼写，而是每个环节（汇编器、链接器、运行时库）在不同系统上的行为差异。比如 Windows 的 win64 目标和 macOS 的 macho64 不仅格式不同，调用约定、符号命名（_main vs main）、甚至栈对齐要求都得单独处理。配置时别指望一个 JSON 文件打天下，按平台分文件、用好 variants 是务实做法。
