go tool compile -S 输出函数级Plan 9风格汇编，含源码行号和变量信息，用于调试与性能分析；需配合-l -m观察内联、逃逸等优化，且不生成可链接的汇编文件。
用 go tool compile -S 看函数级汇编
Go 编译器（gc）本身不生成独立的汇编文件供链接器直接使用，但能输出人类可读的、带源码注释的汇编清单——这是调试和性能分析最常用的方式。
关键命令是：go tool compile -S main.go。它默认输出到终端，显示每个函数的 SSA 中间表示之后生成的最终目标平台汇编（如 AMD64 指令），并穿插 Go 源码行号和变量信息。
-
-S必须小写；大写-s是关闭符号表，完全无关 - 若源文件有 import，需确保
GOOS/GOARCH环境变量与目标一致（比如交叉编译时加GOARCH=arm64 go tool compile -S main.go） - 输出里看到的
CALL runtime.printint这类调用不是“系统调用”，而是 Go 运行时内部函数，别误以为是 libc
用 go build -gcflags="-S" 编译整个包并保留临时文件
单文件 go tool compile 不处理依赖解析，遇到 import 容易报错。更稳妥的做法是走完整构建流程，让 go build 自动管理依赖，再通过 -gcflags 注入汇编输出开关。
执行：go build -gcflags="-S -S" main.go（重复两次 -S 会显示更详细的 SSA 阶段信息，第一次只显示最终汇编）。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 加
-o /dev/null可避免生成二进制，纯看汇编：go build -gcflags="-S" -o /dev/null main.go - 想限制只看某个函数？用
-gcflags="-S -l" -gcflags="-m=2"组合可定位内联行为，但-S本身不支持函数过滤，得靠 grep：go build -gcflags="-S" main.go 2>&1 | grep -A20 "funcName$" - 注意：
-S输出的是“伪汇编”（plan9 syntax），不是 GNU as 能直接吃的 AT&T 或 Intel 语法，别试图拿去用as汇编
生成真正可汇编的 .s 文件？得用 go tool asm 配合手写
Go 官方不提供从 Go 源码自动生成标准 NASM/GAS 格式汇编文件的功能。所谓“编译成汇编”，绝大多数场景下指的就是上面两种查看方式。
如果你真需要一个 .s 文件参与链接（比如混写汇编优化热点），必须手动写，然后用 go tool asm 编译：
- 文件名必须是
xxx_amd64.s（后缀含平台标识），且首行加//go:build amd64 - 语法是 Plan 9 汇编（寄存器名前无 %，立即数前有 $，跳转目标无冒号），例如：
MOVQ $1, AX - 调用 Go 函数要加前导点：
CALL ·add(SB)；导出给 Go 调用的函数需用TEXT ·add(SB), NOSPLIT, $0-24 -
go tool asm -o add.o add_amd64.s生成目标文件，再由go tool link链入，不能直接用gcc或ld
为什么看不到熟悉的 main 入口或 libc 调用？
Go 程序启动链和 C 完全不同：runtime.rt0_go → runtime._rt0_amd64 → runtime.main，没有 _start 或 main 符号暴露给系统 loader。所有系统调用都经由 runtime.syscall 或 runtime.entersyscall 封装，底层用 SYSCALL 指令而非 call libc。
- 在
-S输出里搜SYSCALL才能看到真正的系统调用点，比如write系统调用对应MOVQ $1, AX; SYSCALL -
println、fmt.Println这类不会直接变成printf调用，而是走 Go 自己的 I/O 缓冲和 write 系统调用 - 想确认某段代码是否被内联？加
-gcflags="-m=2"，比盯着汇编更快
真正要动手改汇编，基本只发生在 runtime 包或极端性能敏感的数学库中；日常看 -S 输出，重点不是记指令，而是验证编译器有没有按预期优化分支、消除冗余内存访问、保持寄存器局部性——这些信号藏在指令密度和寄存器使用模式里，而不是语法本身。
