go build -buildmode 用于指定编译输出产物类型，不改变源码逻辑但决定是否生成可执行文件；archive、c-archive、c-shared、plugin 模式生成的文件无入口点，无法直接运行；确保可执行需省略该参数或显式使用 -buildmode=exe。
go build -buildmode 是干什么的？
go build -buildmode 用来控制 Go 编译器输出产物的类型，它不改变源码逻辑，但直接决定生成文件能否被操作系统直接执行。默认行为（即不加 -buildmode）只在单个 main 包下生成可执行文件；而显式指定 -buildmode 会覆盖这个默认逻辑，强制按指定模式构建，哪怕有 func main() 也可能不生成可执行程序。
哪些 buildmode 值会导致无法直接运行？
以下模式生成的文件不能双击或 ./xxx 直接运行：
-
-buildmode=archive：输出.a静态库，仅用于链接，无入口点 -
-buildmode=c-archive：生成.a+ 头文件，供 C 项目调用，不是独立可执行体 -
-buildmode=c-shared：生成.so（Linux）或.dll（Windows），需被宿主程序加载 -
-buildmode=plugin：生成插件文件（如.so），依赖 Go 运行时动态加载机制
这些模式下，即使当前目录有 main.go，go build -buildmode=archive main.go 也**不会**生成可执行文件，而是静默输出 main.a —— 它根本没入口函数，操作系统拒绝执行。
想确保生成可执行文件，该用什么参数？
唯一可靠的方式是：不加 -buildmode，或显式使用 -buildmode=exe（仅限 Windows/macOS/Linux 主流平台）：
-
go build main.go→ 输出main（Linux/macOS）或main.exe（Windows） -
go build -o myapp -buildmode=exe main.go→ 输出myapp（macOS/Linux）或myapp.exe（Windows） -
go build -o ./bin/app .→ 当前目录含且仅含一个main包时生效
注意：-buildmode=exe 在交叉编译时可能受限（比如从 Linux 构建 Windows 程序需配 GOOS=windows），而省略 -buildmode 通常更稳妥。
VSCode 调试时 launch.json 的 program 字段容易踩什么坑？
VSCode 的 launch.json 中 "program" 必须指向一个真实存在的、可执行的二进制文件。常见错误包括：
- 误把
-buildmode=c-shared生成的libxxx.so路径填进program→ 启动时报错exec format error或cannot execute binary file - 没等
go build完成就点击调试，program指向的文件还不存在 → 报错Could not find the specified file -
program路径用了相对路径但cwd设置不对，导致找不到文件 → 启动失败且无明确提示 - 在非
main包目录下执行构建，又没指定-o，结果没生成任何文件，program指向落空
最保险的做法：先手动跑一遍 go build -o ./debug/app .，确认 ./debug/app 存在且 chmod +x 可执行，再把 "program": "${workspaceFolder}/debug/app" 写进 launch.json。
