goos和goarch必须同时显式指定且严格匹配目标系统与cpu架构，漏设或错配会导致exec format error；arm需区分arm（32位）与arm64（aarch64），前者须配goarm=7；cgo_enabled=0是避免动态链接失败的默认安全选项。
GOOS/GOARCH 选错会导致二进制无法运行
交叉编译时，GOOS 和 GOARCH 必须严格匹配目标机器的系统与 CPU 架构。常见错误是把 GOARCH=arm64 用在 ARMv7 设备上（实际应为 arm + GOARM=7），或把 GOARCH=amd64 误用于 LoongArch64 机器——后者会直接报 exec format error。
实操建议：
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
GOARCH=arm需配合GOARM=6或GOARM=7（对应 ARMv6/v7 指令集），不设GOARM时默认为GOARM=7 -
GOARCH=loong64仅在 Go 1.20+ 支持，低于此版本会提示unknown architecture -
GOARCH=arm64不等价于GOARCH=arm；前者对应 AArch64，后者是 32 位 ARM 指令集，二者 ABI 不兼容 - 验证目标平台：在设备上执行
uname -m（如输出aarch64或loongarch64）比查文档更可靠
CGO_ENABLED=1 时必须配对正确的 CC 工具链
一旦启用 CGO_ENABLED=1，Go 编译器会调用 C 工具链链接标准库依赖（如 net、os/user）。若 CC 指向 x86_64 工具链却编译 GOARCH=arm64，会报 cannot execute binary file: Exec format error 或链接阶段失败。
实操建议：
- ARM64 目标：设
CC=aarch64-linux-gnu-gcc，并确保该命令可执行（which aarch64-linux-gnu-gcc） - LoongArch64 目标：用
CC=loongarch64-linux-gnu-gcc，且工具链版本需支持-static（部分旧版不支持静态链接） - Windows 上交叉编译 Linux：
CGO_ENABLED=1时不能省略CC，否则默认调用 Windows 的 cl.exe，必然失败 - 若无需 C 依赖（如纯 HTTP server），优先设
CGO_ENABLED=0，避免工具链问题，生成真正静态二进制
AVX2/SSE4.2 运行时检测不能靠编译期常量
Go 标准库中 runtime/internal/sys.HasAVX2 是编译期硬编码值，不是运行时检测结果。你在 i9-13900K 上跑程序，只要 Go 工具链本身是在无 AVX2 的 CI 机上构建的，这个值就仍是 false。
实操建议：
- 真正需要 AVX2 加速时（如 simdjson-go 或自定义汇编），必须手写 CPUID 检测函数，读取
ECX第 5 位 - Linux 下可用
cat /proc/cpuinfo | grep avx2辅助验证，但不能替代代码中的判断逻辑 - 调用 AVX2 指令前未检测，会触发
illegal instruction信号，进程直接崩溃，recover()无效 - simdjson-go 的
Parse方法内部已做运行时分发，但若你绕过它直接调用底层simdjson_amd64.go函数，就得自己兜底
GOAMD64=v3 不等于“自动启用 AVX2”
GOAMD64=v3 只影响 Go 编译器对循环、浮点运算等基础操作的自动向量化行为，它不会让你调用 VPMULLD、VADDPS 等指令，也不控制内存对齐或寄存器分配。
实操建议：
- 想用 AVX2 做向量化计算，必须写
.s汇编文件，用TEXT ·myAvxFunc(SB), NOSPLIT, $0-32定义，参数通过AX/CX传入 - AVX2 汇编函数必须以
VZEROUPPER结尾，否则后续 SSE 调用可能出错（最常被漏掉） - 数据地址需 32 字节对齐，否则
vpaddd会 panic；用ANDQ $-32, AX截断后，头尾 0–7 元素得用 Go 循环单独处理 -
GOAMD64=v3在 Go 1.17+ 生效，但若目标机器只支持 SSE4.2，设成 v3 也无害——编译器会降级生成 SSE 指令
VZEROUPPER。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
