vscode写汇编需按工具链选扩展：nasm用nasm ide，arm用arm assembly（需手动关联.s文件），x86 gas无好插件；调试依赖gdb等后端并加-g编译；构建优先tasks.json配自定义problemmatcher；注意语法、abi、系统调用号差异。
装对扩展，别只搜“Assembly”
VSCode 本身不带汇编支持，得靠扩展补能力。但搜“Assembly”会出来一堆半成品或只支持某一种架构的插件，容易配半天没语法高亮。ASM Highlighter 看起来名字直白，实际只做基础着色，没智能提示；Intel x86/x64 Assembly 插件对 NASM/YASM 语法支持较稳，但对 GAS（.s 文件）基本不管；如果你写的是 ARM 汇编（比如树莓派或裸机开发），ARM Assembly 扩展更靠谱，但注意它默认不识别 .S（大写 S，GCC 预处理后缀），得手动在设置里加进 "files.associations"。
- 在设置 JSON 中加这行：
"files.associations": {"*.S": "armasm"}
- 如果用 NASM 写 x86_64，推荐装
NASM IDE，它带简单构建任务和寄存器补全
- 别信“Universal Assembly”类插件——没有真正通用的，架构、语法、工具链差一点，高亮就错一片
调试前先确认你有能跑的后端
VSCode 的调试功能只是个界面，背后得靠真实调试器。直接按 F5 跑汇编文件？大概率报错 Cannot launch program; no debug adapter found。这不是 VSCode 的问题，是你没配好调试链路。
- x86/Linux 下常用
gdb + gdbserver，但必须用 -g 编译（nasm -f elf64 -g hello.asm），否则调试器看不到符号
- Windows 上用
WinDbg 或 gdb（通过 WSL），但 NASM 生成的 COFF 目标要配 gdb 的 set architecture i386:x86-64，否则寄存器都读错
-
launch.json 里 program 字段必须指向可执行文件（不是 .o 或 .asm），且该文件得是调试器能加载的格式（ELF / PE / Mach-O）
Makefile 或 tasks.json？优先用后者
写汇编常要串起 nasm → ld → objdump，有人习惯扔个 Makefile，但在 VSCode 里反而绕远了。tasks.json 可以绑定快捷键、捕获错误行号、还能和 Problems 面板联动，比外部 make 更快反馈。
- 在
.vscode/tasks.json 里定义一个 build task，关键字段：
{
"label": "nasm build",
"type": "shell",
"command": "nasm -f elf64 -g ${file} && ld -o ${fileBasenameNoExtension} ${fileBasenameNoExtension}.o"
}
- 错误正则必须配，否则红波浪线不出：用
"problemMatcher": "$gcc" 不行，NASM 错误格式不同，得自定义，例如匹配 ^([^:]+):([0-9]+):([0-9]+): error:
- 如果用 GCC 当 linker（
gcc -no-pie -o ...），记得关掉 PIE，默认开启会导致 ld 报 relocation R_X86_64_32 against `.text' can not be used when making a PIE object
寄存器名大小写、指令后缀这些地方最容易跪
汇编不像高级语言有编译器兜底，拼错一个字母、漏一个 q（如 movq vs mov），NASM 可能静默生成错指令，GAS 甚至直接报错退出，但错误信息极不友好。
- NASM 默认是 Intel 语法，
mov rax, rbx 合法；但如果你开了 [BITS 32] 还写 rax，它不会提醒，只会汇编成错的机器码
- GAS（.s 文件）默认 AT&T 语法：
movq %rbx, %rax，少个百分号或写成 mov rax, rbx 就报 Error: operand size mismatch
- 系统调用号在不同平台不一样：Linux x86_64 用
rax 存号，但 macOS 用 rax + 0x2000000 偏移，写错就直接 syscall 返回 -1
"files.associations": {"*.S": "armasm"}
NASM IDE，它带简单构建任务和寄存器补全Cannot launch program; no debug adapter found。这不是 VSCode 的问题，是你没配好调试链路。
- x86/Linux 下常用
gdb+gdbserver，但必须用-g编译（nasm -f elf64 -g hello.asm），否则调试器看不到符号 - Windows 上用
WinDbg或gdb（通过 WSL），但 NASM 生成的 COFF 目标要配gdb的set architecture i386:x86-64，否则寄存器都读错 -
launch.json里program字段必须指向可执行文件（不是 .o 或 .asm），且该文件得是调试器能加载的格式（ELF / PE / Mach-O）
Makefile 或 tasks.json？优先用后者
写汇编常要串起 nasm → ld → objdump，有人习惯扔个 Makefile，但在 VSCode 里反而绕远了。tasks.json 可以绑定快捷键、捕获错误行号、还能和 Problems 面板联动，比外部 make 更快反馈。
- 在
.vscode/tasks.json 里定义一个 build task，关键字段：
{
"label": "nasm build",
"type": "shell",
"command": "nasm -f elf64 -g ${file} && ld -o ${fileBasenameNoExtension} ${fileBasenameNoExtension}.o"
}
- 错误正则必须配，否则红波浪线不出：用
"problemMatcher": "$gcc" 不行，NASM 错误格式不同，得自定义，例如匹配 ^([^:]+):([0-9]+):([0-9]+): error:
- 如果用 GCC 当 linker（
gcc -no-pie -o ...），记得关掉 PIE，默认开启会导致 ld 报 relocation R_X86_64_32 against `.text' can not be used when making a PIE object
寄存器名大小写、指令后缀这些地方最容易跪
汇编不像高级语言有编译器兜底，拼错一个字母、漏一个 q（如 movq vs mov），NASM 可能静默生成错指令，GAS 甚至直接报错退出，但错误信息极不友好。
- NASM 默认是 Intel 语法，
mov rax, rbx 合法；但如果你开了 [BITS 32] 还写 rax，它不会提醒，只会汇编成错的机器码
- GAS（.s 文件）默认 AT&T 语法：
movq %rbx, %rax，少个百分号或写成 mov rax, rbx 就报 Error: operand size mismatch
- 系统调用号在不同平台不一样：Linux x86_64 用
rax 存号，但 macOS 用 rax + 0x2000000 偏移，写错就直接 syscall 返回 -1
.vscode/tasks.json 里定义一个 build task，关键字段：
{
"label": "nasm build",
"type": "shell",
"command": "nasm -f elf64 -g ${file} && ld -o ${fileBasenameNoExtension} ${fileBasenameNoExtension}.o"
}
"problemMatcher": "$gcc" 不行，NASM 错误格式不同，得自定义，例如匹配 ^([^:]+):([0-9]+):([0-9]+): error:
gcc -no-pie -o ...），记得关掉 PIE，默认开启会导致 ld 报 relocation R_X86_64_32 against `.text' can not be used when making a PIE object
q（如 movq vs mov），NASM 可能静默生成错指令，GAS 甚至直接报错退出，但错误信息极不友好。
- NASM 默认是 Intel 语法，
mov rax, rbx合法；但如果你开了[BITS 32]还写rax，它不会提醒，只会汇编成错的机器码 - GAS（.s 文件）默认 AT&T 语法：
movq %rbx, %rax，少个百分号或写成mov rax, rbx就报Error: operand size mismatch - 系统调用号在不同平台不一样：Linux x86_64 用
rax存号，但 macOS 用rax+0x2000000偏移，写错就直接syscall返回 -1
汇编在 VSCode 里能写得顺，关键不在插件多炫，而在于你清楚自己用的是哪套工具链、哪类语法、哪个 ABI。一旦跨错一步，错误信息往往不指路，只甩个地址或寄存器名给你猜。
