Go build 默认只编译本机平台，因为未显式设置GOOS和GOARCH时，它们自动取当前系统值（如windows/amd64），避免意外生成不可执行文件；二者必须同时指定才能交叉编译。
Windows 上用 VSCode + Go 1.14.6 能直接编译出 Linux 二进制，但默认不启用跨平台支持——必须显式设置 GOOS/GOARCH，否则 go build 总是生成当前系统目标。
为什么 go build 默认只编译本机平台？
Go 的构建行为由运行时环境变量 GOOS 和 GOARCH 控制。未设置时，它们自动取值为当前操作系统和架构（如 Windows/amd64），go build 不会猜测你要交叉编译。这不是限制，而是避免意外生成不可执行的产物。
-
GOOS决定目标操作系统（linux、windows、darwin） -
GOARCH决定目标 CPU 架构（amd64、arm64、386） - 两者必须同时指定，缺一不可；单独设
GOOS=linux仍会用本机GOARCH - Go 1.14.6 已内置全部主流平台支持，无需额外安装工具链
VSCode 中如何稳定触发跨平台编译？
VSCode 本身不干预 go build 行为，关键在任务配置或终端环境。常见误操作是只改 tasks.json 里的命令，却忘了环境变量作用域。
- 在
.vscode/tasks.json中，用"env"字段显式注入："env": { "GOOS": "linux", "GOARCH": "amd64" } - 不要依赖终端里临时
set GOOS=linux—— VSCode 启动的集成终端可能不继承父 shell 环境 - 若用
go run测试，它不支持跨平台，仅go build和go install有效 - 检查是否启用了
gopls：旧版gocode不感知GOOS，但编译本身不受影响
panic: proto: file already registered 在交叉编译时为何更易触发？
这个错误和平台无关，但交叉编译常伴随多模块混用（比如本地开发用 GOOS=windows，CI 用 GOOS=linux），导致不同构建路径下重复加载同一 .proto 生成的 .pb.go 文件。
立即学习“go语言免费学习笔记（深入）”；
- Protobuf 注册逻辑发生在包初始化阶段（
init()），而不同GOOS下构建的二进制仍共享同一全局注册表 - 若项目中多个子模块都
import了同一份生成代码（尤其通过replace或 vendor 引入），就极易冲突 - 解决方案不是禁用交叉编译，而是统一
protoc-gen-go版本，并确保每个.proto只被一个模块生成并导出 - 验证方式：在
main包中加一行fmt.Printf("GOOS=%s GOARCH=%s\n", runtime.GOOS, runtime.GOARCH)，确认构建环境确实按预期切换
真正容易被忽略的是：交叉编译产物无法反向调试——你不能在 Windows 上用 Delve 直接调试 GOOS=linux 编译出的二进制。调试必须在目标平台或容器内进行。
